> > No, I mean which encoding. You can't give a UTF-16 string to an API > > that only knows how to handle UCS-2 encoded data > > Well, most of the time, you can. Only in rare cases do you need to treat > surrogate pairs in special way. One such case, relevant to this discussion, > is converting UTF-16 to UTF-8
Two other examples would be collation and rendering, both of which may be likely results of using the strings with various APIs. In fact, internationalization would be easy if not for these cases where the string is actually USED for something. This is where you run into the gotchas. > So, from where I sit, Win32 API cheerfully accepts UTF-16. Can you show an example to the contrary? Another user dug up an article on Michael Kaplan's blog explaining the nature of Unicode in Windows. Apparently Win2k supported only UCS-2, while XP and above can handle UTF-16. So your experiments will probably show UTF-16 working, but *if* anyone needs to support Win2k, this becomes a consideration again. On Win2k systems, however, MultiByteToWideChar() should return UCS-2 data, so if you use that for the conversion to wide char, you should always be fine on whatever system. > > When I tackle this > > nightmare the last time I was left with the understanding that the > > wide Win32 APIs expected data to be UCS-2 encoded. Now I'm no longer > > sure, and I can't find any reliable documentation on this either way. > > It would be good if the APIs accept UTF-16 > > Which API calls specifically are you concerned about? There are very few cases > where the presence of surrogate pairs makes a difference. I believe you are > blowing the issue way out of proportion. SetWindowTextW() would be a wonderful example. Any API that attempts to understand the string in terms of characters would have a problem. That would include any API that may measure, draw, sort, or re-encode the string, weather directly, or indirectly. That's a lot of APIs. That's why I was concerned about getting the encoding right. I use the wide APIs myself, and if I was making a horrible mistake I wanted to know. Besides, I figured the OP would prefer accurate information. Many thanks for making sure I had my facts straight. John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
