NARUSE, Yui
narus****@airem*****
2006年 4月 7日 (金) 10:47:46 JST
成瀬です。 Kazuhiro Kazama wrote: > 基本的には，レガシーエンコーディングしか扱えないシステムと，Unicode > ベースのシステムが混在する際の問題は解決しなければいけないと考えていま > すし，基本的にEUCやShift-JISの変種は主にその相互変換に使われると思って > います． そうですね。 > しかし，それとは関係ない部分で，単に扱える文字レパートリーを増やすこと > が目的で新しい符号化文字集合をデファクト化しようとするとしたら違う話 > で，別のよりよい方法がすでにオーソライズされている場合には，そちらを使 > う方向の努力の方がよいと思います．たぶん，元の記事もそういう意図だと思 > います． 現状で変態的なものしか存在しないならばともかく、 CP50221 のような比較的マシなものがあるならば、 そちらの方がいいでしょうね。 # CP50221 がなければ意見が変わっていた可能性は高いです。 # いや、 CP50220 を支持してたかな。 > 少なくとも，「より多くの文字を扱いたい」は，日本を含めた漢字を扱うアジ > ア圏の人間の願いなわけですが，それなら今はJIS X 0213は無視できないし， > また従来の機種依存文字が，機種依存文字でない形で扱える，しかも従来は > Windowsとは非互換の機種依存文字のマッピングを採用していたMac OS Xなど > でも正しく表示できるということは重要だと思います． これは UTF-8 の話ですよね？ 最初 Shift_JIS-2004 や EUC-JIS-2004 の話かと思ったのですが。 >> Java 方面で Shift_JIS がCP932 の alias になった騒ぎがありましたが、 >> 騒ぎになる程度の違いは両者にある、と。 >> （これもまたえらく主観的ですが） > > それの騒ぎに関係したのは私だったりします（笑）． > > それで，結論ありきで議論を始めるよりも，まず既存の文字符号化を今よりさ > らに詳しく分析して，その違いを明らかにすることが重要ではないかと思いま > す．できれば，Unicodeへのマッピングが違う部分はどこなのかを一覧表にす > るのは有効だと思います．また同じ符号化文字集合であってもOSSプロダクト > によってマッピングが違うということはないかということも一度確認すること > も必要な気がします． CP932 と CP51932、 eucJP-ms、ISO-2022-JP-MS の対応をまとめた表や、 個々の文字コードの詳細は森山さんが公開されてましたね。 あれを Legacy Encoding Project でも公開してくださるとうれしいです。 マッピングは、各プロダクトで「CP932」と称されるものは、 どれも近いマッピングになってきた気がしていますが、 他はだいぶ差がありそうですね。 その辺の検証結果も公開を期待しておりますけれど。 -- NARUSE, Yui <narus****@airem*****> DBDB A476 FDBD 9450 02CD 0EFC BCE3 C388 472E C1EA
