>The point is that UTF-8 works pretty darn good with existing
>8-bit clean software and file systems, even if they are completely
>unaware of UTF-8 itself.
It works good, if you look at the fact that UTF-8 encoded text is
not destroyed by having the bytes in a normally 8-bit clean 8-bit
byte oriented world. It works badly in a 8-bit byte oriented world,
if you look at the fact that non UTF-8 tools displays the text in
an unreadable format (even though all letters represented by UTF-8 can
be displayed by the local character set) and that many UTF-8 tools cannot
read the local 8-bit byte encoded text.
And you expect these things to work? Why? Do they for
any other pairs of encodings?
You say it's bad that non-UTF-8 tools can't display UTF-8-encoded
characters, even if such characters exist in the local encoding.
Do you think it's also bad that non-EBCDIC tools (say, ASCII tools)
can't display EBCDIC-encoded characters, even if those characters
exist in ASCII?
What about Japanese EUC and Latin-1? Some Japanese EUC
implementations include all the Latin-1 characters in their
repertoire, but they encode those characters differently
than does Latin-1. Can your Latin-1 tools display "Latin-1"
characters if they are encoded according to Japanese EUC
rules? If not, do you think your tools are bad?
Different encodings exist. There's nothing unique about the
differences between Latin-1 and UTF-8.
Like Ken and some others, I think it's pretty cool that the
UTF-8 text could be shipped through different types of systems
using different editors without destroying its contents.
-----------------------
Sandra Martin O'Donnell
odonnell@zk3.dec.com
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:41 EDT