NUMATA Toshinori
numat****@jp*****
2006年 3月 30日 (木) 18:20:38 JST
沼田と申します．どなたも発言されないようなので…． ISO-2022-JP-MS の想定される用途というのは何をお考えでしょうか． CP932 にある全ての文字を ISO-2022-JP 系のエンコーディングで表現しよう という強い意思のようなものを感じてしまうのですが，メールで「丸付数字」の ような機種依存文字が紛れ込んでしまうことの対策としてはやり過ぎのように感 じます． メールを受けたときの対処だけなのであれば，ユーザー定義文字への対応は不 要でしょう．送るときのことも考えているのだとしても，そういう文字を送りた ければ，ISO-2022-JP ではなく，UTF-8 で送ってしまえばいいわけですから． それとも，ISO-2022-JP-MS を IANA Registry に登録し，ISO-2022-JP の後継 文字エンコーディングとして広く使わせることを想定されていますか? MORIYAMA Masayuki wrote: > ISO-2022-JP-MS のようなものを作ってしまうと、アプリケーションソフト > 側で適切にフィルタリングせずに、ISO-2022-JP として出力してしまう事に > つながるから問題だという考え方もあるかもしれません。 > > この問題に対する解決策の 1つの案として、重複定義文字を除く CP932 の > 全文字を扱える ISO-2022-JP-MS と、x-iso2022jp-cp932 のように RFC1468 > の ISO-2022-JP としてそのまま使えるものと 2 種類用意する事かなと考え > ているところです。 > > メール受信時は、ISO-2022-JP-MS でデコードし、メール送信時は > x-iso2022jp-cp932 でエンコードして、変換できない文字が含まれる場合は、 > 警告メッセージを出して UTF-8 などで送信するといった処理が、迷惑にな > らない MUA の実装方法ではないかと考えています。 "ISO-2022-JP" というラベルをつけながらそうではないものを送ってくる連中 に対する対処を，iconv ではなく MUA に押し付けようとするから複雑になるの です．iconv 側で対処してしまえば MUA はいじらなくて済みます． つまり，変換元エンコーディングに "ISO-2022-JP" が指定されたら，機種依 存文字を含むものとして処理する．変換先エンコーディングに "ISO-2022-JP" が指定されたら，機種依存文字はエラーとして弾く．「標準との整合性」とかを 考えなければ，これが一番簡単です．「〜」問題のように，Unicode の複数のコ ードポイントを JIS X 0208 の1つのコードポイントに対応付けるような処理も 必要で (まさか，「〜」を WAVE DASH として扱う 日本語 EUC 系エンコーディ ング及びシフト JIS 系エンコーディングと，「〜」を FULLWIDTH TILDE として 扱う[以下略]とを用意して，用途に応じて使い分けろ，とは言いませんよね)， どうせ綺麗にはいきません．ならば，変換エンジン一人に全ての面倒をかぶって もらうのが楽かと． MUA を作る側としても，Content-Type の charset パラメタの値をそのまま iconv に指定するという単純な作りにすればいいので面倒はありません．日本人 であるとは限らない MUA 開発者に，日本の特殊事情を説明して個別に対応して もらうという手間もかからない． 名前ばかり増やしても，誰も使い分けられないと思いますが，いかがでしょう か． -- 富士通(株) ソフトウェア事業本部 開発企画統括部 沼田 利典 (numa****@sysra*****)
