Unicode On OSX
I admit that the last time I did any active *nix development was over ten years ago, when Unicode was just a dream, but can anyone explain to me why Unicode development on OSX is such a cluster?
Joe and I were discussing strings today and the fact that as engineers we go to extreme lengths to avoid having anything to do with them.
Windows Unicode support just works and the APIs are very orthogonol, but in OSX it just seems to be all over the map Char256, UnicodeChar, blah di blah.
Oh and
wchar_t
is 4 bytes. What’s up with that?
Basically we’re looking for XML parsing support that is API compatible across all platforms and Unicode aware. Expat is our current foundation of choice, but it just doesn’t work compiled for Unicode on OSX, buts runs perfectly on Windows.
Note that I’m not ragging on expat - it’s a fine library and Joe has been talking to it’s author, but apparently no one has tried to use it that way before.
Looks like we’ll be making our first contribution to an Open Source project.
Anyhow, anyone got any rationale or pointers?
0 TrackBacks
Listed below are links to blogs that reference this entry: Unicode On OSX.
TrackBack URL for this entry: http://www.steve-lacey.com/cgi-bin/mt/mt-bar.cgi/811
It seems to me from scanning the API's quickly that OS X uses the more correct but highly complicated unicode implementations, in which you are not tied to a specific encoding, so you can choose between UTF-8 or UTF-16 (UCS-2), where as the MS implementation of unicode chooses one encoding (UCS-2 I think) and wrongly labels that as unicode. A portable string library needs to handle any encoding really.