In Characters vs. Bytes, Tim Bray mentions a Gothic letter faihu. Whether such a character will display properly in your browser depends on what operating system you use and what fonts you have installed. Whether or not you can handle such characters programmaticly, however, depends on what programming language you use.
I’ve taken a closer look at three such languages.
Python can be compiled with --enable-unicode=ucs4, and I’m pleased to say that the version of Python that comes with Ubuntu appears to have done so. With this support in place, Python programs can operate directly on Unicode strings that contain astral characters; and with simplejson such programs can produce correct JSON. Unfortunately, when parsing JSON, characters such as faihu are represented as two surrogate characters. This can easily be corrected by simply converting to either utf-8 or utf-16 and back.
As of Ruby 1.8.6, Ruby has no intrinsic support for Unicode, but by setting $KCODE to UTF8 most libraries will behave reasonably for BMP characters. Unfortunately, the json gem (in its “pure” form as neither libjson-ruby or gem install json will install the C extension variant on Ubuntu) does not handle astral characters correctly. By “not handling astral characters correctly” I mean that unparse produces syntacticly correct but nonsensical output, and produces a runtime exception when asked to parse the very same JSON it produced. The code below demonstrates both the problem and a monkey-patch that compensates for this behavior.
I would have thought that unicodedata.normalize('NFC', string) would handle the surrogate issue. But it doesn’t on my system. I’m not quite sure why. Maybe unicodedata doesn’t know about this particular character...?
I’m being a bit picky, but I think you must mean UTF-16 with respect to Spidermonkey, not UCS-2. The latter only covers the Basic Multilingual Plane, and excludes what Unicode calls the surrogate code points.
LShift on Erlang: Astral Plane characters in Erlang JSON/RFC4627 implementation
Sam Ruby examines support for astral-plane characters in various JSON implementations . His post prompted me to check my Erlang implementation of rfc4627 . I found that for astral plane characters in utf-8, utf-16, or utf-32, everything worked...
Boboroshi | The Issue With Social Networks A good overview of the frustrations in working with multiple social networks, and a little musing on some tools that can be used to glue them together. (tags: aggregation socialnetworking) Facebook |...
I’d have thought that Python in UCS2 mode (which is actually UTF16, handling surrogates) would have supported such a character to the same degree as Spidermonkey (represent it as a pair of surrogates, but return a length of two). Was that not the case?
Ruby and Rails RubyGems 0.9.5 Install rmagick on Leopard ActionMailer quicktips: receiving and parsing mail New TextMate Theme for Ruby, HAML, Rails, and more! Zed Shaw on Mongrel, Ruby stacks, and languages besides Ruby Instantly add wiki...
SpiderMonkey follows ECMA-262 Edition 3, which clearly specifies storing, indexing, and counting characters in strings using 16-bit storage units. The first note in Chapter 6 “Source Text” is:
NOTE Although this document sometimes refers to a “transformation” between a “character” within a “string” and the 16-bit
unsigned integer that is the UTF-16 encoding of that character, there is actually no transformation because a “character” within a
“string” is actually represented using that 16-bit unsigned value.
For JS2/ES4, we hoped to do better, without requiring all implementations to change how they index and reckon lengths. See the update unicode proposal and its discussion page.
And it’s a bold move that might bite back with interop bugs, if (say) China favors an ES4 implementation that embraces UTF16 fully, web content is developed accordingly, and then the world-wide-ness of the web puts that content through ES3-style implementations. But we don’t want to impose non-constant-time indexing and length computing (obvious optimizations notwithstanding) on all ES4 implementations, and we do not want to close the door on full UTF16. So, a “allow both” compromise, or invitation to experiment.
I think the result for python has to be considered a bug in simplejson. In a UCS4 build of python loads should recompress surrogate pairs into characters.
Current behavior is right for a UCS2 build, as Astral planes characters can only be represented via surrogate pairs in those systems, but in UCS4 builds simplejson.loads should return proper characters, instead of improper surrogate pairs, I guess. Opinion of expert unicoders welcome.
I have testcases and a patch that does this for UCS4 builds only (distinguished by sys.maxunicode > 66000), and I’m looking for a simplejson bug tracker where I can drop it for further improvement. Any clue?
Not a biggie until the moment philologists start using simplejson based stuff.
James Henstridge on UCS2 builds of python
Was that not the case?
It is, at least for jython (the only UCS2-alike build I have at hand). For those builds my patch keeps simplejson current behavior.