[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ISO 2022 (Was: Re: The Swedish Initiative)
Let me say someting about ISO 2022.
[ISO-2022-JP] --- RFC 1468
[ISO-2022-JP-2] --- RFC 1554
(Multilingual Extension of ISO-2022-JP)
[Mule] --- Nishikimi, M., Handa, K., and S. Tomura,
"Mule: MULtilingual Enhancement to GNU Emacs",
Proc. of INET'93, August, 1993.
- I like ISO 2022.
- I dislike Unicode.
- I don't think 'charset' subtype is necessary if we use ISO 2022.
Unicode assigns same codes to both most of Chinese characters and most
of Japanese characters just because it seems same for western people.
It does not make sence to assign same code to different character set.
Please image if someone says, "English character 'l' and number '1'
look like same, so let's assign a same code.".
I know several Unicode platform exist, but I don't want make Unicode
as an Internet starndart for this reason.
ISO-2022 is a encoding mechanism based on escape sequence. ISO-2022-JP
is for Japanese character set and ISO-2022-JP-2 is for multiple
We should discuss encoding mechanism, character set, and internal
character representation separately. Mule has a powerful internal
representation mechanism and achieve a success to support
multi-lingual character set.
It is important to prepare a mechanism to contain multiple code set in
one text file because I want to quote my favorite french words into my
Thus, encoding and internal expression should be able to treat
multiple character set at once. ISO-2022-JP-2 is the one.
Mule currently supports ISO-2022-JP and I implement a MIME interface
'Mew' on Mule. (Note that Mew can also work with Emacs19.) Mew
converts ISO-2022-JP encoded byte stream to Mule internal expression.
See Mule and Mew and you find how powerful Mule internal expression
and ISO-2022 ending mechanism work.
I don't think MIME text/plain charset subtype is necessary if we all
ISO-2022-JP-2 because ISO-2022-JP-2 itself tells us what character set