Austin:

Are you saying that 8859-1 encoding does not work with these international versions of MS Windows, so we would need to ensure that we are putting UTF-8 chars in the data? This would make sense if the OS uses UTF-8 chars. in the WHERE clause so that it is searching against 8859-1 chars. If the above understanding is correct, then I must make the inference that MS Windows for English uses 8859-1 chars in the WHERE clause of SQLlite; otherwise, the English version of MS Windows would not work either. But, it does.

Can anyone else please chime in here and either agree or dispute what Austin is saying? I would like some more feedback
before I start doing more investigation.

Thanks,

Dan
Austin Ziegler wrote:

On 8/4/05, Dan Wellisch <[EMAIL PROTECTED]> wrote:
We just put a SQLlite application in production. It handles the
display of ISO 8859-1characters just fine if they appear in the
search results.

However, users that are running German, French, etc. versions of
Microsoft Windows are complaining that search results are coming
back with 0 results whereas we know that these querys work when
the app. is running on the English version of MS Windows.

What do we do to fix this so this app works correctly on any
language version of OS? Furthermore, we also have a version of
this app. that runs under Mac OSX so I pose the same question
concerning that OS.

You may need to do some data massaging to make sure that it's *not*
ISO-8859-1 but rather convert UTF-8. This may require a couple of
round trips with WideCharToMultibyte and MultibyteToWideChar so that
you go from the OEM encoding (presuming that you're using char* as
your characters) to UTF-8 via Windows wide characters (which are
UCS-2, IIRC).

Alternatively, use something like Iconv to do this. The main problem
is (likely) that you're inserting data as if it were always ISO
8859-1, when it's not.

-austin

Reply via email to