Kazuhiro Kazama
kazam****@mac*****
2006年 5月 4日 (木) 02:05:00 JST
On 2006/04/25, at 21:13, MORIYAMA Masayuki wrote: > 次の点が一番の要点となるかと思いますので、よろしくお願いいたし > ます。 > > ・Windows の Codepage 50220, 50221, 50222 による変 > 換で、Unicode の > U+E000〜U+E757 にマッピングされているものは、 > Windows での仕様と考え > てよいか? 問い合わせ中ですが，ちょうどGW連休に入った土曜日にメールし たのと，私の会社が停電なので，結果はまだわかりません． > glibc, libiconv のパッチでは 3. の方法を取っています。 この方法を許してもらえるとしたら（私は，以前のメールでこの方法が 却下されたと勘違いしていたようです），比較的無難だし，メール送受 信にISO-2022-JPを使っても大きな問題はなくなると言えるので はないでしょうか．ただ，この穂法は好まない人もいるようなので，要 検討ですが． > CP5022X を導入した場合、UTF-8 からの変換で、U+301C WAVE > DASH が変換で > きないとしても、CP932, CP51932, eucJP-ms と > CP5022X との変換が可能だと > いう事と、Windows の API で UTF-8 (Unicode) > に変換されたものは、扱える > ようになるので、それなりのメリットはあると考えています。 歴史的経緯としては，ISO-2022-JPと（いわゆる）JISコー ドは区別されていました．CP5022Xは後者の方の立場と考えられ ますので，また別の意味があります．ただ，実際にそれが必要なケース というのがどれくらいあるかですが．少ないとしたら，必須にする必要 はないと思います． > CP5022X や CP51932 をアルゴリズム的な変換で CP932 > へ文字コード変換した > 場合に、CP5022X や CP51932 の NEC選定 > IBM拡張文字(89区〜92区)をそのまま、 > NEC選定IBM拡張文字の符号位置に変換するという実装が多いか > と思います。 > > 表示を行うだけであれば、それだも良いのですが、CSI(Code Set > Independent) > な実装を行っているソフトウェアでは、NEC選定IBM拡張 > 文字とIBM拡張文字 > (115区〜119区)は、表示上同じ文字であっても符号位置 > が異なるという事で別 > 字として扱われてしまうので注意が必要になってきます。 それは実装の問題で，そのような問題が起こりえることは指摘していい と思いますが，本来は照合などの上位レベルで扱うべきものなので，今 回の範囲外でしょう． それで，そろそろ，ある程度，課題や技術的選択肢がある問題を整理し て，可能なものはまとめて結論を出していった方がよいのではないかと 思います． --- Kazuhiro Kazama kazam****@mac*****
