OSS における統一したレガシーエンコーディングの変換機能の開発（OSC2006）

以下のように資料が公開されている．

http://sourceforge.jp/docman2/?group_id=2198

なお，ここで指摘されている"YEN SIGN Problem"は，どちらかと言えば問題は正しく説明しているとは言えない．正しくは，以下の資料を参照して欲しい．

http://www.opengroup.or.jp/jvc/cde/ucs-conv.html

聴講してきたが，目的はUnicodeを中心としたピボット変換における変換表のミスマッチの問題を解決することと，扱える文字レパートリを増やすということのようである．特に，EUC符号化に若干の対応のばらつきが見られる点は，今後しっかり検討して対処する価値はあるだろう．

ただし，課題がいくつか見受けられた．

一つは，現時点ではアプリケーションが動作するプラットフォームとの適合性が未調査であることである．既存の変換表の修正をおこなうことも予定されているようだが，方法によっては特定のプラットフォームで問題が起こる可能性がある．特に複数OSの上で動く可能性があるアプリケーションは，適合性の検討が必要であろう．

もう一つは，単にレガシーエンコーディングで文字レパートリーを増やすという目的のものには再考の余地があるということである（たとえば，これは既存のMSのコードページ932を扱えるようにすることとは異なる）．Windows Vistaが登場すれば，JIS X 0213の文字が急速に使われるようになり，もう後戻りはできないだろう．その時に，「単に文字レパートリーを増やすために」追加されたものは急速に意味を失い，足かせにしかならないかもしれない．たとえば，資料にある開発予定をISO-2022-JP-MSを，今更すべてのアプリケーションでサポートする必要があるのだろうか？ほとんどのOSSで実装されていないということは，実装する必要がないor実装すべきでないということを示唆している可能性は高いだろうし，基本的に「要求度が低く，問題を引き起こす可能性があるものは標準では追加しない（ただし，システム構築の際の顧客の要求に対処できるように独自に拡張できるようにはしておく）」というのが，一般的な対応だと考えているし，これがJavaでやったことでもある．

あと，できれば今後のUTF-8によるJIS X 0213対応も少し心に止めておいて欲しいと願っている．今後の調査で，ある部分はUTF-8を使った対処にまかせるとしても，それに問題があっては困る．その辺の調査も同時に行ってくれたらなあというのは個人的な希望である．

最後に，今回の話はやはり関係者に何も伝わっていなかったらしく，Linuxの国際化関係者にも相談していなかったとのこと．現在は，Microsoft, Apple Computer, Sun Microsystemsなどの企業，ISOやJIS，Unicode Consortium，W3Cなどの標準化団体，そしてオープンソース開発者は人間ネットワークを構成して，互いに情報交換しながら問題に対処しているが，これが本来の「緩やかな合意」であると考えている．ただし，すでに交流の機会を予定しているようなので，この点はしっかり対処して頂けるだろう．今後が楽しみだ．