Tadamasa Teranishi
yw3t-****@asahi*****
2006年 1月 28日 (土) 23:22:01 JST
寺西です。 # 支離滅裂で申し訳ない。どうするのが一番良いと決めかねるので...。 "NARUSE, Yui" wrote: > > ICUがglibcのeucJP-msマッピングをucm形式で公開しているのを見つけました。 > http://dev.icu-project.org/cgi-bin/viewcvs.cgi/charset/data/ucm/ http://www.opengroup.or.jp/jvc/cde/ucs-conv.html#ch3_1 の 3.1.2 コード変換規則 をみると、 「Unicode とユーザ定義文字・ベンダ定義文字に関する問題点と解決策」 に従っていないような気がして、glibc のものに問題があるような気は します。 > 調べてみたところ、以下の点で現在のnkfとマッピングが異なるようです。 > > nkf.c rev 1.90, utftbl.c rev 1.16 > <U00A5> \xA1\xEF |1 > <U203E> \xA1\xB1 |1 > > glibc-EUC_JP_MS-2.3.3.ucm > <U00A5> \x5C |1 > <U203E> \x7E |1 > > これについて、nkfのマッピングをglibcにあわせようと思っているのですが、 > ご意見ありますでしょうか。 個人的には前者が望ましいと思いますが、glibc のものが良いか悪いかはとも かく、glibcに合わせておくというのも、ひとつの方法でしょう。 どちらが正しいというものでもないだけに難しいですね。 > ASCII外の文字が文字コードの変換によってASCIIに飛び込んでくる件は、 それに加えて、ISO-646 の IRV である12文字については更に厄介な 問題です。 さらに \5C は Windows でのパス区切り、\7E は UNIX のホーム を指す記号といった特別な意味が付加されているので、問題はより 複雑です。 > CP932がどうしようもないことを考えると、 これはどうしようもないことですし、実際いろいろ問題が起こります。 http://jvn.jp/jp/JVN%2318282718/index.html http://qdbm.sourceforge.net/mikio/rbbs.cgi?id=RA11304958080739742137 Microsoft が CP932の変換をしっかり考えていなかったのが敗因でしょう。 > 「仕様」とし、別途注意を喚起した方がいい気がしてきました。 とされても、使う側は相当困るわけです。特にパスの変換には使えない ことになりますから。 「注意」だけで終わられるのは辛いところですね。(eucJP-ascii を使えば 問題にならないか...。) -- ===================================================================== 寺西 忠勝(TADAMASA TERANISHI) yw3t-****@asahi***** http://www.asahi-net.or.jp/~yw3t-trns/index.htm Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E
Fork