Hi,
At Wed, 8 May 2002 21:41:08 +0200 (CEST),
Bruno Haible wrote:
> Tomohiro Kubota, in
> http://www.debian.or.jp/~kubota/unicode-symbols-yen.html, explains
> the YEN SIGN versus REVERSE SOLIDUS problem. He writes:
I think there is no solution for this problem. At least, this
problem should not be solved until massive Japanese people will
start using Unicode. When massive Japanese people will start
using Unicode and they will establish a custom how to handle this
character code, we will be able to think about the solution.
Though Yen Sign Problem did exist in the past (because Shift_JIS's
0x5c is YEN SIGN and EUC-JP's 0x5c is REVERSE SOLIDUS), this problem
was not regarded as a large severe problem because Shift_JIS is the
only popular encoding for general users in Japan because it is
adopted by Windows and Macintosh. EUC-JP is only used for UNIX-like
systems which is not yet common even now.
I think the "unicode" which is used in Japanese version of Windows
is *not* unicode. It is a Unicode-like encoding with 0x005c YEN
SIGN. However, I don't think this cannot solve our problem because
Microsoft will call the "Unicode-like encoding" as Unicode and there
are no reason why Japanese people don't believe it.
> 1) Admit that YEN SIGN and REVERSE SOLIDUS are different things.
Yes, of course. "regard YEN SIGN and REVERSE SOLIDUS are same"
was possible because Shift_JIS has YEN SIGN but no REVERSE SOLIDUS
while EUC-JP has REVERSE SOLIDUS but no YEN SIGN.
> 2) Never use backslash as a directory separator.
Since Shift_JIS doesn't have backslash, this is not a problem.
> 3) For programs that interpret backslash as some kind of escape character
>and use Unicode internally but should work with text in Shift_JIS
>encoding, consider the multibyte character 0x5C as being the escape
>trigger, not [only] the Unicode character U+005C. This is already done
>in bash and gettext. For example, in GNU gettext, we have the code
Though I could not understand the code, I think interpretation of
U+00A5 as an additional escape character doesn't always work, because
Unicode texts don't have information on their origin (converted from
Shift_JIS or not). If U+00A5 would always be an escape character,
it would be harmful for many softwares.
> 4) When people convert files from Shift_JIS to Unicode, they need to
>disambiguate the two uses of the character that Tomohiro mentions:
>"When a Japanese person is a writer, it means YEN SIGN in most cases.
> When a non-Japanese person is a writer, it always means REVERSE SOLIDUS."
>These "most cases" need to be distinguished - in a financial text the
>use is likely different than in a shell script. It can not be done
>by the iconv program.
The problem is, the distinction cannot be automated and costs a lot.
Most of Japanese people don't have any reason to pay such costs.
I am interested in how European people succeeded to migrate from ISO 646
variants into ISO 8859. Yen Sign Problem is exactly a problem of ISO 646,
because "0x5c = YEN SIGN" comes from JIS X 0201 Roman, which is Japanese
variant of ISO 646.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.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/linux-utf8/
