Hello all, I'm new to SQLite (1 week) and am a Win32 developer (10 years). I'm quite impressed with SQLite.
>From my standpoint, a Unicode Layer for SQLite would suffice even though it would not be the most efficient solution. This layer would perform the conversion from Unicode to ANSI and then call the SQLite API. I don't really need a Unicode build of the library - I only want to present Unicode strings to the library, 99.9% of which are widened ANSI character strings. I don't see a reason for SQL strings to be anything other than ANSI themselves, but data into and out of the fields may require the larger character set. (I guess that implies that the library is compiled for UTF-8.) There are some minimal changes to library code that could be made to better support Unicode. Specifically, vxprintf in printf.c could be changed to actually use the 'l' modifier for characters and strings (i.e., "A format: %lc %ls"). When the 'l' modifier is present, the corresponding parameter is Unicode and SQLite should make the conversion to UTF-8. That way, Unicode string pointers could then be presented to the sqlite_exec_printf functions without conversion in the Unicode Layer for SQLite. The conversion between Unicode and UTF-8 would be implemented in functions that live in os.c. These functions would also be used in the Unicode conversion layer. The philosophy, of course, is to minimize changes to the library thereby minimizing maintenance and regression testing. I'd be happy to hear how these concepts affect the embedded developers that need Unicode support. Cheers! Jon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
