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.
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.
2) ISO-2022-JP is not filesystem safe. Therefore filenames will never
be able to carry Japanese characters in this encodings.
Robert Brady writes:
> Does ISO-2022 see much/any use as the locale encoding, or it it just used
> for interchange?
Just for interchange.
Paul Eggert searched for uses of ISO-2022-JP as locale encodings (in
order to convince me), and only came up with a handful of questionable
URLs. He didn't convince me. And there are no plans to support
ISO-2022-JP as a locale encoding in glibc - because of 1) and 2) above.
Bruno
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
