Re: URL internationalization!
"Martin J. Duerst" <[email protected]> Sat, 15 Mar 1997 17:22:32 +0100 (MET)
| Newsgroups | gmane.ietf.url |
|---|---|
| Message-ID | <Pine.SUN.3.96.970315162401.245r-100000@enoshima> |
On Tue, 11 Mar 1997, Masataka Ohta wrote: > If it's individual characters, character sets containing Latin, > Greek and Cyrillic 'A's are ambiguous and is unusalble. There is a big difference between ambiguous and unusable. ISO 10646 contains several areas with possibilities for ambiguity. It is clear that such ambiguities have to be avoided for URLs to work. It is important to note that ISO 10646, encoded as UTF-8, contains considerably less possibilities for ambiguity than ISO 2022, the alternative that Masataka is suggesting repeatedly but half-heartedly. Here is a list of the main possibilities for ambiguities in ISO 10646 and the way to solve them: Different encodings of the same diacritic combination (precomposed and decomposed): Define a normalization standard based on the already existing equivalence relations. I am already working on a document proposing normalization rules; in my proposal, the most important one will be: Precomposed characters in Unicode 2.0 stay composed, anything else stays decomposed. Compatibility and pseodo-compatibility characters: With "pseodo-compatibility" I mean characters that are not in the compatibility section, but which most probably should have ended up there, such as the Angstrom/A-ring at U+212B. In this case, the non-compatibility characters should be used. Otherwise easy-to-confuse characters: An example of this is the Latin/Greek/Cyrillic "A"s mentionned above. These are ambiguous, but not unusable. They have to be used with care. We already have examples in ASCII URLs where such care is necessary: O/0 (add D here for Japanese) and l/I/1. Written on paper, they are often ambigous. Nobody would want something like 0O00Oo0O0O.com. Similarly, nobody would invent AAAAAAA.com, where each a is from a different alphabet. There is a lot that can be done with technology, but there are limits; on the other hand, there is no need to assume that users are more stupid than they actually are. Regards, Martin.