MORIYAMA Masayuki
moriy****@mirac*****
2006年 3月 31日 (金) 16:26:17 JST
森山です。 NUMATA Toshinori <numat****@jp*****> wrote: > 沼田と申します．どなたも発言されないようなので…． > > ISO-2022-JP-MS の想定される用途というのは何をお考えでしょうか． 特定の用途に縛られないようにしたいと考えています。 MUA (メールソフト) などを想定し、変換元に指定した場合は機種依存文字は 受け付けて、変換先に指定した場合には、機種依存文字などは変換エラーにし てしまうと、テキストエディタで使う場合に、ファイル読み込みは可能だけれ ども、保存は出来ないという事になってしまう可能性があります。 文字コード変換の事情を知っていないと、何が問題であるのかというのが理解 できず戸惑ってしまう事でしょう。 > それとも，ISO-2022-JP-MS を IANA Registry に登録し，ISO-2022-JP の後継 > 文字エンコーディングとして広く使わせることを想定されていますか? 可能であれば、IANA Registry への登録を行えればと考えています。 ただ闇雲に登録していっても使われなければ意味がありませんから、登録するの に妥当なものであるかの検討が必要と考えています。 > "ISO-2022-JP" というラベルをつけながらそうではないものを送ってくる連中 > に対する対処を，iconv ではなく MUA に押し付けようとするから複雑になるの > です．iconv 側で対処してしまえば MUA はいじらなくて済みます． 機種依存文字を Unicode に変換可能な 7ビットJISエンコーディングを ISO-2022-JP という名前で使えるようにするという事は、エイリアス機能など で実現した方がよいのではないかと個人的には考えています。 > つまり，変換元エンコーディングに "ISO-2022-JP" が指定されたら，機種依 > 存文字を含むものとして処理する．変換先エンコーディングに "ISO-2022-JP" > が指定されたら，機種依存文字はエラーとして弾く．「標準との整合性」とかを > 考えなければ，これが一番簡単です．「〜」問題のように，Unicode の複数のコ > ードポイントを JIS X 0208 の1つのコードポイントに対応付けるような処理も > 必要で (まさか，「〜」を WAVE DASH として扱う 日本語 EUC 系エンコーディ > ング及びシフト JIS 系エンコーディングと，「〜」を FULLWIDTH TILDE として > 扱う[以下略]とを用意して，用途に応じて使い分けろ，とは言いませんよね)， > どうせ綺麗にはいきません．ならば，変換エンジン一人に全ての面倒をかぶって > もらうのが楽かと． 「変換エンジン一人に全ての面倒をかぶってもらう」という考え方だと、最低 でも次の 2 つの変換を行うものを別の名前で用意して使い分けるようにする 必要があるのではないかと思いますがいかがでしょう? (1) MUA 用の 7ビットJISエンコーディング 7ビットJIS から Unicode への変換 Windows 機種依存文字、JIS X 0201 片仮名 が変換可能 Unicode から 7ビットJIS への変換 US-ASCII、JIS X 0208:1997 (エスケープシーケンスは JIS X 0208:1983 のものを使用する) で定義されている文字だけを変換 (RFC1468 準拠) (2) テキストエディタ用の 7ビットJISエンコーディング 7ビットJIS から Unicode への変換 Windows 機種依存文字、JIS X 0201 片仮名(、ユーザ定義文字)が変換可能 Unicode から 7ビットJIS への変換 Windows 機種依存文字、JIS X 0201 片仮名(、ユーザ定義文字)が変換可能 > MUA を作る側としても，Content-Type の charset パラメタの値をそのまま > iconv に指定するという単純な作りにすればいいので面倒はありません．日本人 > であるとは限らない MUA 開発者に，日本の特殊事情を説明して個別に対応して > もらうという手間もかからない． > > > 名前ばかり増やしても，誰も使い分けられないと思いますが，いかがでしょう > か． 名前を増やさずに対応してしまうと、意図しない変換が行われるケースが出て くるので、きちんと区別して使えるようにすべきと考えています。 libiconv 1.8 のパッチでは、ISO-2022-JP の変換に細工をほどこして、CP932 から Unicode に変換した場合に出てくる U+FF5E を Unicode から ISO-2022-JP への変換で '〜' に変換できるようしたのですが、メンテナの方には不評でし た。そのような経緯もり libiconv 1.9 以降のパッチでは、ISO-2022-JP に対 して細工は施さないようにしてあります。 あと、Unicode とのマッピングを JIS規格準拠とし JIS X 0212 補助漢字を含 む EUC-JP だと、U+FF5E FULLWIDTH TILDE は、0x8FA2B7 にマッピングされる ので、CP932→Unicode→EUC-JP といった変換を可能なようにするという事は、 本来無理な話といえます。(機種依存文字を除く文字の変換の話です) というわけで、個人的には、JIS準拠の Shift_JIS, EUC-JP, ISO-2022-JP に U+FF5E を '〜' に変換するような細工を施す事は、やらない方がいいという 結論に達しています。(あくまでも個人的な見解です) しかし、現実的にはアプリケーション側で、明示的に CP932 などを使うよう に修正するというのは面倒であるので、次のような機能が必要になってくるの だろうと考えています。 文字コード変換で指定する名前のエイリアス機能を実現して、Shift_JIS が指 定された場合には、CP932 の変換を行うというような定義を可能にするのが現 実的なのではないかと考えています。この事に関しては、将来的な課題として あるだろうという認識です。 -- 森山 将之 moriy****@mirac***** ミラクル・リナックス株式会社
