Kazuhiro Kazama
kazam****@mac*****
2006年 3月 31日 (金) 18:55:11 JST
On 2006/03/31, at 16:26, MORIYAMA Masayuki wrote: > MUA (メールソフト) などを想定し、変換元に指定した場合は > 機種依存文字は > 受け付けて、変換先に指定した場合には、機種依存文字などは変換エ > ラーにし > てしまうと、テキストエディタで使う場合に、ファイル読み込みは可 > 能だけれ > ども、保存は出来ないという事になってしまう可能性があります。 > > 文字コード変換の事情を知っていないと、何が問題であるのかという > のが理解 > できず戸惑ってしまう事でしょう。 そのような場合には，沼田さんはUTF-8を使えばよいのではない かと指摘していると思います．まず最初にUTF-8で解決できない 問題は何かを，考えるべきではないでしょうか？ それで，文字レパートリの問題と，変換表の問題は分けて議論すべきだ と思います．私は，少なくとも扱える文字数という点に関しては，増え るのではなく，減る方向の提案だと考えています． >> それとも，ISO-2022-JP-MS を IANA Registry に登 >> 録し，ISO-2022-JP の後継 >> 文字エンコーディングとして広く使わせることを想定されていますか? > > 可能であれば、IANA Registry への登録を行えればと考えてい > ます。 数年前に我々も検討したのですが，その時点でもIANA Registry への新たなcharsetの登録は，基本的にはおこなわないとのこと でした．これは，今後は新たな符号化文字集合を増やすことは避けて， できる限りISO/IEC-10646/Unicodeに統一したいという意図によ るものです．現在，非常に広く使われているが登録されていなかったと いう実績が明確にない限りは難しいでしょう． なお，すでにJIS委員会では，7ビット及び8ビットの 2バイト情報交換用符合化漢字集合は廃止する方向で，JIS X 0221の改訂を進めていると聞いていますし，Microsoftやアップ ルコンピュータなどのメーカも，同じ意向だそうです．使わないように しようとする合意が取れているものに対して，複雑化を進めるのは得策 ではないと思います． > 文字コード変換で指定する名前のエイリアス機能を実現して、 > Shift_JIS が指 > 定された場合には、CP932 の変換を行うというような定義を可 > 能にするのが現 > 実的なのではないかと考えています。この事に関しては、将来的な課 > 題として > あるだろうという認識です。 以前，Javaの設計で国際化エンジニアと議論したことがあるので すが，やはり状況に応じて変換テーブルが変わるというのは，混乱をも たらすからよくないという結論になったことがあります．実際には，た とえば Emacsで変換テーブルを状況に応じて自由に切り替える実 装もあったりするのですが，それは一般的とは言えず，新たな問題を発 生されるだろうと考えています． なおWindowsのコードページ932に関しては，すでに Windows-31JというIANA名が登録されているので，それが使われ ています． --- 風間 一洋 (kazam****@mac*****)
