Kazuhiro Kazama
kazam****@mac*****
2006年 5月 22日 (月) 12:40:14 JST
柳沢さん On 2006/05/22, at 3:26, Yanagisawa wrote: >>>> 今，Mac OS Xで標準のMailを使ってJIS X 0212の >>>> 文字を入れて出してみたとこ >>>> ろ，黙ってUTF-8で送信しました． >>> >>> なんと！、クサナギをいれたら。CP932で出ました。 >> >> これが昨日聞いていたCP932問題ですか（苦笑） > > ところで、これの何が問題かと、修正の仕方に関してこ > の ML 上ではなたも言及されていない... ですよね? > それらを私が推測するに、修正法としては > > 1) CP932 は正式な IANA name ではないので、エンコー > ディングはそのままで、ヘッダーを charset=windows-31j > と修正する。 > 2) CP932 は（何らかの理由で）メールには適切なエン > コーディングでないので、別のエンコーディング、 > 例えば UTF-8 を使う。 > 3) その他 > > などがあると思います。実際にはどれが適切なんでしょうか? 鋭いですね． たぶん，問題は3つに分けられるんじゃないかなと思います． 1) CP932はIANAに登録されていない（Windows-31JとcsWindows31Jは登録）＆ 歴史的経緯で使われているわけでもない（x-ms-cp932はWindowsでは処理可 能）． 2) 指定されている文字符号化でサポートされていない文字があった場合に， どの文字符号化にフォールバックさせるべきか． 3) フォールバックの切り替えポイントはどうなのか． それで，私が指摘したのは1)だけです．まあ，これは論外でしょう． ただ，2)は現在の日本の方向性に合わせてUTF-8になると思っています．ただ， ISO-2022-JP-1などにフォールバックする実装も世の中にあるとしたら，それ は将来的には直してもらった方がよさそうです． 問題は3)です．結局，IANA登録名に，より文字レパートリーが広い別の文字符 号化を割り当てているケースがあり，その場合には切り替えポイントが合致し なくなります． たとえば，UCS正規化方式のメーラだと，文字符号化変換APIで指定した文字符 号化で変換時にエラーが発生した時を切り替える目安にしていると思われるの で，上記のような変更がある場合にはやりたくない解決法（今までレガシーエ ンコーディングの実装を変えるか，国際化フレームワークの範囲を逸脱してア ドホックに対応するとか）しか思いつきません．この辺はいろいろ議論の余地 がありそうです． なお，MSの阿南さんには，この前の御礼を兼ねて，これらのことも報告してお こうと思っていますので，意見があれば教えてください． --- 風間 一洋 (kazam****@mac*****)
