> Certainly not! > > Win32 supports full Unicode 5.1 in UTF-16 for a long time.
I double checked this just to be sure, and now I'm not. Here are the facts: 1. When Microsoft describes "Unicode" and "wide characters" the description always matches UCS-2 (they continually mention that "Unicode" strings are 2 bytes per character, so the character length is always half the number of bytes.) 2. MultiByteToWideChar supports a "MB_COMPOSITE" flag, which appears to give UTF-16 output. 3. MultiByteToWideChar also supports a "MB_PRECOMPOSED" flag, which appears to force UCS-2 output. 4. By default, MultiByteToWideChar precomposes when possible, and returns a composite character otherwise. Microsoft never seems to clearly identify whether the wide APIs should be given UTF-16 or UCS-2. Their guide on internationalization would seem to suggest that UCS-2 must be used, however, there is some reason to believe that perhaps UTF-16 is handled correctly as well. Couldn't find anything reliable one way or the other though. (Though there are plenty of folks taking whichever position, so at least I'm not the only one who's confused now.) John -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jean-Christophe Deschamps Sent: Thursday, October 29, 2009 9:18 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Some clarification needed about Unicode >My main point is that you can't take the UTF-16 string and safely supply >it to APIs which want UCS-2 encoded text, such as Win32 APIs (including >things like SetWindowText()). Odds are that the only library you are >using which supports UTF-16 is SQLite. You should always be converting >the text to UCS-2 before you use it. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
