ユニコードの文字幅問題(6)

この文字幅問題にどのような対応方法があるか考えてみた。

案1) GNU libc 等の文字マッピングを変更して、CP932 のように全角扱いの文字へ変換するようにする。

例外もあるが、ほぼJIS規格に沿っている glibc のマッピングを変更するには筋か違う。変更するとしてもポンド記号とかの JIS X 0208 (第一水準)の文字はよくても、将棋駒などのJIS X 0213 (第三水準)の文字は対応する全角文字がないので、そもそも無理。


案2) Unicode Consortium に働きかけて Ambiguous な大量に文字を増やしてもらう。

これは難しい。技術的には合理的な案だと思うけど政治的な問題として、ユニコードの利用を推進する人たちに、(彼らから見たら)少数利用者のためだけの他の文字コードとの互換規定を入れてもらうのは無理筋。

案3) 過去のことはきっぱり忘れて、全ての文字がユニコード指定の文字幅だと思って UTF-8 を使う。

まさに未来に生きる感じで、これができれば問題はないのだけど、現在 UTF-8 以外にも EUC-JIS-2004、ISO-2022-JP、SJIS(CP932) などの文字コードを併用していてる状況では難しい。個人的に JIS X 0213 の文章を大量に作ちゃったのが致命的...

案4) ユニコードや UTF-8 のことはきっぱり忘れて EUC-JIS-2004 とかを使い続ける。

逆に過去に生きる感じ。オープンソースの素晴しいところはサポートがなくても自分で何とかできる点で、死ぬまで今のまま使い続けるのも何とかなるかもしれない。でもとても無駄な努力な気がする。

案5) アプリケーションで複数の文字コードと文字幅を使える状況を準備して、状況に合わせて使い分ける。特に文字コードを併用するために EUC や SJIS と同じ幅で表示できる UTF-8 環境を整備しておく。

結局は、この案5)の方法しかないという判断になりました。