[EMAIL PROTECTED] wrote: > Brodie Thiesfield <[EMAIL PROTECTED]> wrote: [...] > SQLite should never expect strings in any encoding other > than UTF-8 or UTF-16. (Note that ASCII is a proper subset > of UTF-8 so SQLite will also accept ASCII.) I do not know > what CP_ACP is, but if it is not a subset of UTF-8 then > SQLite should (if implemented as designed) malfunction if > you give it a CP_ACP string that has a different representation > than the equivalent UTF-8. > > If you find a case where SQLite is expecting some character > encoding other than UTF-8 or UTF-16, then you have found a bug. > Please create a ticket and suggest an appropriate patch.
CP_ACP is ANSI code page. The character encoding usually used by the file API on Windows. It will be different depending on the Windows legacy locale. e.g. Shift-JIS for Japanese. EUC-KR for Korean. I have filed the following ticket for this bug: http://www.sqlite.org/cvstrac/tktview?tn=2121 > My intent is to let yall continue to debate a proper fix > for porting the extension loading mechanism to wince and > then once you reach consensus I will check in whatever that > consensus happens to be. The problem is not just Windows CE. The current problem of the Unicode build (and therefore *also* a Windows CE build) failing can be temporarily fixed with the patch that I supplied in the first reply to your email. The larger problem of Win9x clients not seeing a ANSI char* API instead of the specified UTF-8 char* API is a problem that needs to be fixed with larger changes to the win_os.c layer. The LoadLibrary call should also be implemented there. What is the problem with implementing the LoadLibrary call in the os_win.c layer? Regards, Brodie ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
