Cart
[Home] [By Thread] [By Date] [Recent Entries]
Rick Jelliffe wrote:
> You are right that a Java Character is a UTF-16 code. But making
> Java Characters into 24-or 32-bit codes would still not make them
> characters in the plain English sense (which is closest to "collatable
> units"). A combining umlaut is not really a character for example;
> radicals are not ndependent characters, though they may have codepoints.
>
> So, paradoxically, an API that handles real characters properly
> probably never has arguments or return results of Character
> (or something that is 8, 16, 24, or 32 bits) but instead uses String
> (and its variants).
The point about doing strings, not characters, is well-taken, and one of
the things in the W3C i18n draft that gave me an "aha" moment. On the
other hand, I think that when I say a "Unicode character", that has a
very well-defined semantic, and COMBINING UMLAUT is one while codepoints
from the surrogate blocks aren't, and any API that doesn't make that
clear is, well, wrong. Put another way, something that is a Unicode
character in UTF-16 should also be a character in UTF-8 and UTF-32,
which the surrogates aren't, so they are just not characters in any
meaningful sense of the word.
--
Cheers, Tim Bray
(ongoing fragmented essay: http://www.tbray.org/ongoing/)
|
