NARUSE, Yui
narus****@airem*****
2006年 4月 6日 (木) 11:22:58 JST
成瀬です。 Tadamasa Teranishi wrote: > "NARUSE, Yui" wrote: >> そこで、日本語テキストを扱う場合に、 >> 過去の資産及びシステムが使っている文字コードは、 >> * ISO-2022-JP >> * Shift_JIS >> * CP932 >> * EUC-JP >> * eucJP-ms >> * CP51932 >> >> だと考えました。 > > んー。どうでしょうね。意見は割れるところではないかと思います。 三つでいいとか、逆にもっと必要だと考える方もいるでしょうね。 >> * そのような CP51932 を用いた資産が相当数存在する >> (IEから投げられた「日本語 (EUC)」をそのまま保存しているシステム） >> という理由からこれも追加しました。 > > それが CP51932 でなければならないとか、そのまま CP51932 として > 生かさないといけないのかというところには疑問が残ります。 NEC選定IBM拡張文字が 0xF9A1 から 0xFCFE になる文字コードは、 わたしは CP51932 しか知りませんが、 他にそのような文字コードがあるならばそれでもよいでしょうね。 他に無いならば eucJP-ms でなく、CP51932 でなければならないでしょう。 そのまま CP51932 として生かさないといけない、とは思っていません。 多少平行運用を行わなければならない場合もあるでしょうが、 多くの場合は、 nkf --overwrite --ic=CP51932 --oc=UTF-8 一回の利用だろうとは思っています。 >> ユーザは使い分けることが難しいと考えていらっしゃるようですが、 > > そう思いますよ。 うーん、MySQL 4.0 の時に CP932 相当が提供されず騒ぎになった記憶や、 Ruby に nkf-2 を取り込んだときに何人かから CP932 まわりで ツッコミを受けたりしたので、 少なくとも CP932 についてはわたしはニーズもあるし、 使い分けたい人がいると考えているのですけれど。 eucJP-ms についても、Perl Encode は対応しないのかという質問を、 ML も投稿者も異なるもので 4,5 件見てはいます。 けれど、説得力のあるニーズを示すデータは難しいですね。 > ヒット数だけでは何とも判断がつかないのではないでしょうか? > 相当の人が必要性を感じ、使い分けているとはどうも思えませんし、 > その根拠にgoogleのヒット数を出すのでは、説得力にかけます。 ごもっともな指摘だと思います。 しかし、他に「数字」が出る指標があるかというと、うーん。。。 はてなあたりで質問すれば数字は出せるでしょうが、 それも説得力に欠けそうですし。 > まぁ、それはあるでしょうけど、それを救うことにどれほどの意味が > あるのか疑問が残ります。 これは反論不可能ですね。 >> ユーザ定義文字をメールで送信するために、 >> 当事者同士で合意の上 ISO-2022-JP-MS で送る余裕があるのならば、 >> CP932 で添付ファイルにするなり、UTF-8 で送るべき、 >> というのは当然の批判でしょう。 > > メールに限らず UTF-8 化に力を注ぐほうが、より健全だろうと思います。 UTF-8 化の前提として、既存データの UTF-8 化が存在し、 それを行うのにレガシーエンコーディングと Unicode の対応表が、 ‘いくつか’必要である、というのがわたしの考えです。 過去のデータは全て捨ててしまえ・・・とは言いませんよね？ ＃システムは捨ててしまえ、というのもありでしょうが。 そのうえで、Shift_JIS だけでいいじゃんとか、 Shift_JIS と CP932 の違いは大きいよ、という話になるでしょう。 Java 方面で Shift_JIS がCP932 の alias になった騒ぎがありましたが、 騒ぎになる程度の違いは両者にある、と。 （これもまたえらく主観的ですが） -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
