Hi,
At Tue, 30 Jan 2001 20:40:02 +0100 (CET),
Bruno Haible <[EMAIL PROTECTED]> wrote:
> ISO-2022-JP will never be a satisfactory terminal encoding (like
> ISO-8859-*, EUC-*, UTF-8, Shift_JIS) because
>
> 1) It is a stateful encoding. What happens when a program starts some
> terminal output and then is interrupted using Ctrl-C or Ctrl-Z? The
> terminal will remain in the shifted state, while other programs start
> doing output. But these programs expect that when they start, the
> terminal is in the initial state. The net result will be garbage on
> the screen.
Yes, of course I know this problem, because I sometimes use ISO-2022-JP
for real purpose. I can use 'full reset' feature of the terminal.
Well, however, I have not used ISO-2022-JP as _locale_ encoding.
(I don't have ISO-2022-JP locale).
This is just like when curses-based software exitted abnormally and
we have to type 'stty sane'.
> 2) ISO-2022-JP is not filesystem safe. Therefore filenames will never
> be able to carry Japanese characters in this encodings.
Yes, of course I know this problem also. However, I think the encoding
for filenames should not depend on locale, because filenames are never
changed when users change locale environment. My idea is that encoding
for filenames should be always UTF-8 or depend on filesystem (ext2,
vfat, ...). However, I don't know whether application softwares or
kernel should be responsible for encoding conversion... (i.e., I have
no idea whether locale encoding or UTF-8 should be used for parameters
for fopen() and so on.)
I think it is not a good idea to use Japanese filename, even if it
is encoded by EUC-JP. Do you use filenames in ISO-8859-1? I think
it is not a good idea, too. You will have trouble when you use other
locales (for example, UTF-8 locales).
In short, these problems of ISO-2022-JP are users' problems. Users
may have enough reason to use ISO-2022-JP in spite of these problems.
> Tomohiro Kubota writes:
>
> > Then I received a mail to ask whether it will support ISO-2022,
> > from a developer who is involved into an internationalization
> > project of a text-based web browser.
> > Theoretically, ISO-2022 can co-exist with almost other encodings
> > such as ISO-8859-*, EUC-*, UTF-8, Shift_JIS, and so on because
> > these encodings don't include ISO-2022's escape sequences.
Note my original story is not about ISO-2022-JP but ISO-2022.
And more, the advantage of ISO-2022 which I wrote above would be
lost if ISO-2022 is used only under ISO-2022 locale. (The point
of this idea is that ISO-2022 can co-exist with any other encodings.
Thus, terminals can [theoretically] support both locale encoding
and ISO-2022 at the same time. Novice users may fail to set-up
locale and LANG variable properly but ISO-2022 can be used everytime.)
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://surfchem0.riken.go.jp/~kubota/
"Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
