Hi Jens, ----- Original Message ----- From: "Jens Miltner" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> Sent: Monday, April 24, 2006 5:30 AM Subject: Re: [sqlite] Using sqlite3_open or sqlite3_open16?
> > Am 22.04.2006 um 15:48 schrieb COS: > > Thanks for the info. I did have found in the manual that UTF16 is > > converted > > to UTF8 on Windows environments. > > But one little question: How would one know if the filename is in > > UTF8 or > > UTF16? > > You see, my little application is installed in PC's all around the > > world. I > > don't know in advance if the filename is UTF8 or UTF16. I noticed that > > always using UTF16 to open the database can lead to an exception in > > filenames with UTF8. > > Hmmh - I'm not sure I entirely understand your problem: usually > strings passed in UTF-16 are passed in 'wide' strings, i.e. each > character is 16 bit as opposed to UTF-8 strings, which are usually > passed in strings where each character is 8 bit. > I don't know the Windows APIs very well, but from what I remember, > you build your app either as Unicode app or as "ASCII" app and only > unicode apps get their filenames as UTF-16, "ASCII" apps get whatever > code page is installed/activated on the system, usually not UTF-8, > though... My application is not built using Unicode. But I use a lot of MFC and CString is aware of International characters. The problem is a little different. I don't need to use UTF16 strings at all. The problem comes up when the application is started and it needs to open the database from the My documents folder. In Windows NT/2000/XP and probably others too, the userid is a string to compose the personal folder location (i.e. C:\Documents and Settings\userid\My Documents). As you can see this location can change a lot. It may even work for a particular user and don't for another. > Where do you get your filenames from so you don't know the encoding? I get this information directly from Windows, using the Win32 SDK API. The string is correct, even for UTF16 strings. The Windows SDK API allows to open the file directly without problems or any conversion (maybe some conversion is done internally by the Win32 SDK). > As a rule of thumb: anything you get as a plain character pointer > probably isn't UTF-16 (unless there's some badly designed API in the > middle). OTOH, you can't assume anything that's plain character > pointer is UTF-8 - most likely on Windows it's something different. > > </jum> I tried to look for some information in the MSDN, without success. I'm starting to look at SQlite code to find out how the conversion is made and maybe I can simulate the same process before opening the file and choose the proper way. Thanks for your time on this. Best Regards, COS
