Kazuhiro Kazama
kazam****@mac*****
2006年 4月 25日 (火) 12:34:47 JST
返事が遅くなってごめんなさい． On 2006/04/18, at 21:41, MORIYAMA Masayuki wrote: >> 正式な資料が手に入らないようなら，私からMicrosoftにコンタクトしてみま >> しょうか？ > > お願いしてよろしいでしょうか。 はい．もちろん向こうも会社の方針があるので，必ず望む答えが得られるとは 限りませんが，誠意のある対応をしてくれると思います． それで，ここは外したくないという要点があれば列挙して頂けますか？たとえ ば， ・CP5022Xをどれでも処理できるようにしているのか？ ・外字はどうしているか？ ・MSとしては，どのようにして欲しいか？ とか…． ところで，MS用JIS符号化（特定の文字符号化を限定しない，曖昧な表現で す）について考えていて一つ興味深いことがわかりました． というのは，実はUTF-8レベルで文字のマッピング（たとえば，WAVE DASHがU +301CかU+FF5Eか）が混在しちゃうのはどうしようもない（たぶん，本当にど うしようもないと思う…）という仮定に立つとします． また，問題にするのはマッピングの違いであり，文字レパートリはとりあえず 範囲外とも仮定します．これはISO-2022-JPというのが情報交換専用であり文 字レパートリを積集合に限定することが重要だということもありますが，この MLの報告を見ていても，あまりに変種（MS，Mac，メールソフトなど）が多す ぎて，実質的にISO-2022-JPを超えた範囲が使われても，それを完全に同定す るのは難しく，またUnicode変換した時点で意味がなくなる（復旧できない文 字化け）ことです． で，まず現場で一番問題になるのは，クライアントがWindows (CP932)でサー バがUnix系(EUC符号化)という時です．この時は，合わせてCP51932を使えば問 題はないはずです（すでに普及してしまったeucJP-msも，限定された互換性を 持つ？？？）． で，MS用JIS符号化を使うのは，たとえば ・nkf風に文字符号化を相互変換するケース． ・既存のメールをUnicode化してアーカイブ化するケース． ・Webブラウザのように，任意の文字符号化をサポートするケース． だろうなと私は最初考えていました．ところが，これらのケースでは問題は解 決されないようです． というのは，Unicodeをベースとしたピボット変換を前提にすると，必ずUTF-8 がサポートされると考えられます．しかし，UTF-8レベルではマッピングが統 一できないので，たとえばCP5022Xの代わりにISO-2022-JPを使っても状況は同 じ（一部の文字の欠落は許容する）ことになります． たとえばWebブラウザの場合には，どちらの符号位置でも表示さえできれば問 題は顕在化しにくいかもしれません．というのは，UTF-8のページはUTF-8で保 存するからです．また，Unicodeデータベースアーカイブに既存のJISメールを マージするのも同じです．それは，一般にマッピングが異なる記号類は全文検 索では無視されることが多い（その方がユーザの利便性が高い…たとえば，ハ イフンでもスペースでもよいとか）からです． しかし，nkf風プログラムの場合には，レガシーエンコーディングに戻さなけ ればいけないので，文字が化けてしまうことになります． これを回避するためには，たとえば次のような対策が必要です． 1, UTF-8入力をサポートしない． 2, プログラム内でどちらかに正規化する． 3, 出力時に，どちらも同じ文字に変換できる（例，U+301CとU+FF5EもWAVE DASHに）ようにする． さて，これをどうするか…ということですねえ…． 結局，CP5022Xの導入だけでマッピングの違いをカバーできるのは，UTF-8をサ ポートしないでISO-2022-JPでしかやりとりしないシステムということになり そうです． なお，Unicodeベースのピボット変換をしないシステムについては考えていな いので，何か考察すべきことがあればお願いします． --- 風間 一洋 (kazam****@mac*****)
