Kazuhiro Kazama
kazam****@mac*****
2006年 4月 4日 (火) 18:37:53 JST
On 2006/04/04, at 17:04, MORIYAMA Masayuki wrote: >>> ただし、MUA の都合だけで、文字コード変換の実装を行ってし >>> まうと、「テキス >>> トエディタでの利用の場合に、問題が生じるでしょう」という事を書 >>> きました。 >> >> そもそもテキストエディタで，ISO-2022-JP-MSを使わなければい >> けないケースって，どのくらいあるのでしょうか？ > > 逆に、ISO-2022-JP-MS がメールのやりとりにだけしか使われないという保障 > があるのか? と考えると、MUA 依存の実装を行う事は、テキストエディタでの > 利用の場合のように弊害があるので、避けたいところです。 ということは，現在そのような符号化文字集合はエディタで使われれている例 は示せないということですね． では，現在新しい7ビット及び8ビットの2バイト情報交換用符合化漢字集合は 新たに作成しないという合意を覆すまでの必要はないという結論になります． > MUA で、メール受信の時だけ ISO-2022-JP-MS を使い、メール送信は必ず > UTF-8 で行うという事になれば、ISO-2022-JP-MS を IANA Registry に登録す > る必要は無くなると思います。 というか，メールの送受信をUTF-8でおこなってしまえばよいのでは？ もちろん，それだと修正が必要なソフトウェアがある可能性はありますが，そ れは国際的な方向性に一致した，必要なものだと思います． それで，現在の話では，同じ言語を喋る人間からさえ批判が出てくるのですか ら，IANA Registryへの登録は不可能でしょう． > わざわざ、ISO-2022-JP-MS のようなものを定義しようとしているのは、 > x-iso2022jp-cp932 では Windows 機種依存文字が扱えないという事と、 > Windows の CP50220, CP50221, CP50222 のように複数のものを用意するとい > うアイデアは良いとは思えなかった為です。 > CP50220 互換の実装に関して、eucJP-ms を G0 集合のみを使う 7ビットJIS > コー > ドにしたものが CP50220 であるという間違った理解に基づく実装が行われて > たりするので、いつまでも非標準だからと、この問題に取り組まないでいる > と、 > いろいろと不都合が生じてくるだろうと考えています。 だから，そのような用途にはUTF-8があれば十分ではないですか？ 新たな提案を行う時には，その必要性と，解決する問題などを明確に示さない といけません．しかし，すでにオーソライズされているUTF-8の方が上位互換 の仕様であり，すでに提案する文字符号化が広く使われているという実例もな いようなら，合意を得るのは難しいと思います． > 実装の数は少なくても、実際に利用されている絶対数という事では、無視でき > ない数になると考えています。 「利用されている絶対数」と言っても，電子メールの場合を除いた場合には， ほぼゼロになるのではないですか？「アプリケーションを使っているユーザ 数」が「ある特定の符号化文字集合を使っているユーザ数」に等しいわけでは ありません． > eucJP-ms, ISO-2022-JP-MS, CP932, CP51932 のそれぞれは、変換表の齟齬が > 生じないようにします。 > > 他の変換表で Unicode に変換したものを変換しようとすると問題が生じるで > しょうけれども、CP932 と同じ変換表を使う ISO-2022-JP-MS といようなもの > が無い事で、別の変換表の ISO-2022-JP を使ってしまって問題が生じるとい > う類の問題は解消されると考えています。 現時点では必要性，将来性，使用実績ともに不十分ですから，ISO-2022-JP-MS を情報交換用として新たに認めて貰うのはたぶん不可能です．で，電子メール 用が難しいとしたら，使われないわけですから，問題は起こらないと思います． > 既存の符号化文字集合を考える上で、文字レパートリ(Windows機種依存 > 文字)の問題を扱わないわけにはいかないと考えています。 基本的には，既存の文字符号化集合をそのまま扱えばよいだけで，パズルゲー ム的な遊びをする必要はないでしょう． > IE で POST されてきた CP51932 を PostgreSQL の EUC_JP や MySQL の > eucjpms でデータ格納したとします。そして、PostgreSQL や MySQL の文字 > コー > ド変換で Unicode や CP932 で取り出すと、NEC選定IBM拡張文字がユーザ定義 > 文字に化けてしまうという問題があります。 > > どれほど普及しているのかまでは不明ですが、日本語EUC符号化方式で処理 > し、 > そのまま HTML の入出力を行っているような Web アプリケーションでは、 > CP51932 で多くのデータが蓄積されている可能性はあります。 頭の中で考えた可能性ではなく，実例を示して頂けると幸いです．実例が一番 強いので． > Unicode ベースのシステムへ移行する段階になって、NEC選定IBM拡張文字が文 > 字化けする問題が発覚する事になるというケースが、今後出てくる事が予想さ > れます。 ただ何度も言うけど，Unicodeベースのシステムが前提なら，たとえばUTF-8な らその問題は起こらないのでは？ ＃ 別の問題が起こりますが（笑） >> しかし，単に文字レパートリの問題で引っ張り出してきたのなら，意味 >> はないと思います． > > 意味が無いとしても、最低限、eucJP-ms と cp51932 が別物であるという事を > 明確化しておかないと、間違った理解に基づく開発が行われてしまう危険があ > ります。 実際にどのように使われていて，どのような問題が起こるかを，明確化する必 要はあると思います． > 個人的には、Windows 機種依存文字を日本語EUC符号化方式で扱うのはやめて > おいた方が良いと考えているのですが、そのような考え方は一般的ではないよ > うです。 あなたが一般的ではないだけで，すでに世界的には一般的だと思いますし，そ れはMSの方針でもあれば，日本の方針でもあります． それで，もし本当にUTF-8でWindows機種依存文字を扱って問題があるとした ら，その例を挙げてください．それは重要です． > 必要とされるケースがごくまれなのであれば、そのような対処でも良いので > しょ > うけれども、日本語のメールを扱うケースでは、Windows 機種依存文字を扱わ > ない訳にはいかないという現実があるので、個別に独自のコンバータを追加し > て使うという事だと敷居が高いように感じます。 標準ではない・将来的にもならないのなら，敷居が高くなるべきでは？ もちろん，標準になったとしたら，敷居を低くすべきです． それで，どうしてももし私の意見に納得ができないのなら，勝手に作業を始め るまえにIANAやIETFに問い合わせてみる方がいいのでは？それで合意が取れれ ば，問題ないと思いますので．また，それで却下されれば，さすがに納得でき ますよね？ > 一覧表に空きがある事、どうして空きがあるのかという事、そして空きがある > 部分に関して、どのような処理を行うのが適切なのか? といった事が周知徹底 > されていない為、落とし穴にはまる人が後を断たないように思います。 今回のプロジェクトは，それを周知徹底すると聞いていますが． 落とし穴にはまらないためには，できる限り日本固有の文字符号化を複雑にし ないということが重要だと思います． 最後に，日本国内で国際的な方針に逆らったゲリラ活動をするごく少数の人物 のおかげで，日本人全体が批判される不幸なことだけは起こさないようにして 欲しいと思います． --- 風間 一洋 (kazam****@mac*****)
