MORIYAMA Masayuki
msyk****@mtg*****
2006年 4月 4日 (火) 17:04:31 JST
森山です。 On Mon, 3 Apr 2006 13:03:33 +0900 Kazuhiro Kazama <kazam****@mac*****> wrote: > On 2006/04/01, at 13:33, MORIYAMA Masayuki wrote: > > MUA に関しては、UTF-8 対応が進んできているので、 > > RFC1468 の ISO-2022-JP > > に変換できない文字が使われた場合には、UTF-8 でメール送信 > > する事は現実的な > > 解決策の一つだという事には異論はありません。 > > その通りだと思っています． > > > ただし、MUA の都合だけで、文字コード変換の実装を行ってし > > まうと、「テキス > > トエディタでの利用の場合に、問題が生じるでしょう」という事を書 > > きました。 > > そもそもテキストエディタで，ISO-2022-JP-MSを使わなければい > けないケースって，どのくらいあるのでしょうか？ 逆に、ISO-2022-JP-MS がメールのやりとりにだけしか使われないという保障 があるのか? と考えると、MUA 依存の実装を行う事は、テキストエディタでの 利用の場合のように弊害があるので、避けたいところです。 > > 扱える文字数に関しては、風間さんの意図されている事が、どういう > > 事なのか理 > > 解できませんでしたので、説明していただけると助かります。 > > 講演の質疑応答でも他の方からあった通り，一番主なのはJIS X > 0213対応だと思います．わざわざ収録文字数が少ない符号化文字集合を > 新たに提案する意味はないはずです． MUA で、メール受信の時だけ ISO-2022-JP-MS を使い、メール送信は必ず UTF-8 で行うという事になれば、ISO-2022-JP-MS を IANA Registry に登録す る必要は無くなると思います。 わざわざ、ISO-2022-JP-MS のようなものを定義しようとしているのは、 x-iso2022jp-cp932 では Windows 機種依存文字が扱えないという事と、 Windows の CP50220, CP50221, CP50222 のように複数のものを用意するとい うアイデアは良いとは思えなかった為です。 CP50220 互換の実装に関して、eucJP-ms を G0 集合のみを使う 7ビットJISコー ドにしたものが CP50220 であるという間違った理解に基づく実装が行われて たりするので、いつまでも非標準だからと、この問題に取り組まないでいると、 いろいろと不都合が生じてくるだろうと考えています。 > > ISO-2022-JP という名前で Windows の機種依存文字が扱える > > 拡張(CP50220 のサ > > ブセット?) を実装して使っているものとしては、Mozilla > > Thunderbird や > > Sylpheed などがあります。 > > > > 7ビットJISのエンコーディングで、Windows 機種依存文 > > 字を使える実装というの > > は増えてきていると感じています。 > > 逆に考えれば．Windows機種依存文字をUnicodeとして扱え > る実装は非常に沢山あるわけで，それに対してほとんど無視できるくら > いしか存在しないのでは？ 実装の数は少なくても、実際に利用されている絶対数という事では、無視でき ない数になると考えています。 メール送信の場合 極力、UTF-8 を使って送信するようにする。 メール受信の場合 現状では、ISO-2022-JP という名前で、CP50220 が送られてくることが多い ので ISO-2022-JP-MS で文字コード変換を行う。 という事で良いのであれば、MUA 開発者に負担を強いることなく、Windows 機 種依存文字を含むメールを受信でき、メール送信時には非標準のものを出さず に済むようになるでしょう。 > > 今までは、シフトJIS符号化方式の cp932 を、日本語 > > EUC符号化方式、7ビット > > JIS符号化方式との間で変換して扱う事が困難だったのを、変換して > > 使えるよう > > にするという事がポイントになります。 > > > > 「eucJP-ms と ISO-2022-JP-MS は、CP932 の全 > > 文字レパートリーを扱えま > > す。」と一言で言い表せますから、単純明快だと考えています。 > > いや，実は変換表の齟齬の問題があるから，そんなに簡単にはなりませ > ん． eucJP-ms, ISO-2022-JP-MS, CP932, CP51932 のそれぞれは、変換表の齟齬が 生じないようにします。 他の変換表で Unicode に変換したものを変換しようとすると問題が生じるで しょうけれども、CP932 と同じ変換表を使う ISO-2022-JP-MS といようなもの が無い事で、別の変換表の ISO-2022-JP を使ってしまって問題が生じるとい う類の問題は解消されると考えています。 > ここではっきり言いますが，文字のレパートリだけ考えるのはもう止め > ましょうよ．だって，これは既存の符号化文字集合をシステムでほぼ問 > 題なく扱えるようにする提案だと理解しています．そもそも，扱える文 > 字数はすでにオーソライズされているUTF-8より少なくなるのは > 確実なんですから． 既存の符号化文字集合を考える上で、文字レパートリ(Windows機種依存 文字)の問題を扱わないわけにはいかないと考えています。 > > cp51932 は、ユーザ定義文字を扱えませんが、Internet > > Expolorer や Mozilla > > Firefox が "EUC-JP" として POST してくる文字コード > > と互換があります。 > > > この「互換」というのも微妙だと思うんですが，eucJP-msでは問 > 題があるのでしょうか？CP51932が非常に普及しているのなら異 > 論がありません． IE で POST されてきた CP51932 を PostgreSQL の EUC_JP や MySQL の eucjpms でデータ格納したとします。そして、PostgreSQL や MySQL の文字コー ド変換で Unicode や CP932 で取り出すと、NEC選定IBM拡張文字がユーザ定義 文字に化けてしまうという問題があります。 どれほど普及しているのかまでは不明ですが、日本語EUC符号化方式で処理し、 そのまま HTML の入出力を行っているような Web アプリケーションでは、 CP51932 で多くのデータが蓄積されている可能性はあります。 Unicode ベースのシステムへ移行する段階になって、NEC選定IBM拡張文字が文 字化けする問題が発覚する事になるというケースが、今後出てくる事が予想さ れます。 > しかし，単に文字レパートリの問題で引っ張り出してきたのなら，意味 > はないと思います． 意味が無いとしても、最低限、eucJP-ms と cp51932 が別物であるという事を 明確化しておかないと、間違った理解に基づく開発が行われてしまう危険があ ります。 > > cp51932 を使えるようになると Windows 機種依存文字を扱う > > 必要のある Web-DB > > システムで日本語EUC符号化方式だけで処理する事ができるよ > > うになり、処理の > > 単純化が行えるようになります。 > > これはUnicodeベースのシステムの問題点を解決する提案だと理 > 解していますので，それならUTF-8などで扱える方が単純ですよ > ね．特にWebベースシステムを考えれば，UTF-8しか扱えな > いフレームワークなども多く普及していますし，符号化文字集合は > （iモードなどの特殊な場合を除けば），システム側で決定でき > る自由度があります． 個人的には、Windows 機種依存文字を日本語EUC符号化方式で扱うのはやめて おいた方が良いと考えているのですが、そのような考え方は一般的ではないよ うです。 > > どういった問題が発生するのか明らかにしていただければ、メリッ > > ト、デメリッ > > トを比較して検討する事が出来るようになると思います。 > > 「状況に応じて変換テーブルが変わるというのは，混乱をもたらす」書 > いてあるはずです．結局，開発者は必ずしもよくわかっていないで使う > ことが多いわけで，よく理解しないで非互換性があるコンバータを使う > ことは，別の問題をもたらすことがあります． > > なお，「できる」には，「そのままできる」と「できる選択肢が用意さ > れている」の二つのレベルがあることを考慮に入れるべきです．前者 > は，一旦普及したらそれをなくすことはできないので慎重に検討しなけ > ればいけません．問題が多く，使用が限られている部分などは，あえて > 入れないが，何らかの形で対処法は残しておくというのが，安全な方法 > でしょう． 選択肢が与えられずデフォルトで「そのままできる」ようにしてしまう事は問 題が多すぎるという事に異論ありません。 > たとえば，ISO-2022-JP-MSのような文字符号化に関しては， > Javaでも追加しようと検討したことがありますが，結局おこないません > でした．それは，まずそれがほぼ電子メール＝情報交換専用に使われる > のが明らかでありながら標準ではないことと，要求が少なかったことで > す． > しかし，それが必要な場合は理解していますので，コンバータを拡張す > るAPIを設計・追加しました．実際に，某超大手Webメール > システムに相談された時には，独自にコンバータを追加するようにアド > バイスし，そこではWindowsの機種依存文字は扱えるようになっ > ています． 必要とされるケースがごくまれなのであれば、そのような対処でも良いのでしょ うけれども、日本語のメールを扱うケースでは、Windows 機種依存文字を扱わ ない訳にはいかないという現実があるので、個別に独自のコンバータを追加し て使うという事だと敷居が高いように感じます。 Java では、次のようなものが開発されているようなので、独自のコンバータ を開発する余裕がない場合など、こういったものを利用すれば良いのか… プロジェクト: Windows Japanese Charsets for Java http://sourceforge.jp/projects/wjc4j/ 概要 Windows で使用されるコードページ51932(EUC-JP) および コードページ50220、 50221、50222(ISO-2022-JP)を J2SE1.4以降で使えるようにします。 > また，ISO-2022-JP-MSとeucJP-msは少々意味が異なると > 思っています．前者は明らかに情報交換専用でありながら非標準で，す > でにより優れた代替があるのに対して，後者はシステム内で使われるも > のであることです． > > とにかく，一覧表を書いてしまうと，つい空いている部分をとにかく埋 > めたくなってしまう（笑）ものですが，まずそれがどのような意味を > 持っているかを考えることが必要だと思います． 一覧表に空きがある事、どうして空きがあるのかという事、そして空きがある 部分に関して、どのような処理を行うのが適切なのか? といった事が周知徹底 されていない為、落とし穴にはまる人が後を断たないように思います。 ‖森山 将之 (MORIYAMA Masayuki) ‖e-mail: msyk****@mtg***** ‖ moriy****@mirac*****
