アカウント名:
パスワード:
ここで述べている文字幅問題は、何度か紹介してきた、こちらで述べている問題 (日本語版を用意しました:-) とは違います。それ以前の問題です。
XFree86 の XTerm の UTF-8 モードは、Unicode Standard Annex #11 East Asian Width で「EastAsiamAmbiguous」に分類されている文字を、1 カラム (半角) 扱いします。そして、JIS X 0208 に含まれる多くの文字が (文字の多くが、ではない!)、EastAsianAmbiguous に分類される Unicode 文字にマッピングされます。それには、ロシア文字、ギリシア文字、●や★などの記号、が含まれます。
つまり、luit を使った EUC-JP XTerm は、現状では、ロシア文字、ギリシア文字、東アジアローカルな記号以外のほとんどの記号類を、半角で表示してしまいます。
昔懐かし日本語 EUCでは (いや,日本語だけではなく中国語等でもそうですが) 「G0, G1, G2 及び G3 の,各 G バッファ毎に文字の幅が一意に決定される」という,暗黙の前提があって, それを前提に多くのプログラムが書かれていたわけです.しかし,それはそれで一種の文字コード依存 (Code Set Dependence) ではあるわけで, そういうのを前提にしてプログラムを書いていた人は, Unicode べったりにプログラムを書く人を責められませんね.
でも, 文字コードのもつ性質に依存しない (Code Set Independence, CSI) ようにプログラムを書くのは, 移植性を考慮してプログラムを書くのと同じで, なかなか一朝一夕にできるものではありません. 移植性は,各種の OS やライブラリやコンパイラの 違いを知った上でなければ 考慮しろと言われてもできるものではないのですが, CSI による国際化は,各種文字コード,言語,習慣等の違いに対する移植性を考慮しろと言われるようなもので,こんどはそれらがどれくらい変わり得るかを知らなければならないわけですから.
たとえば,日本語 EUC や シフト JIS や Big5 や UTF-8 では, 「複数バイトの文字は,文字の1バイト目を見れば, その文字が残り何バイトあるかがわかる」 という性質があったわけですが,これが中国の新しい文字コードである GB18030 では成立しません. (GB18030 では,2バイト目まで見ればわかる.) いままで,それを想定していたプログラムはみんな書き直しになります.
それ以前にも,たとえば, 「文字のバイト数と画面上の表示カラム数は一致する」 という想定が破られたりしたことがありますね. (この想定は,シフト JIS では成立するが,日本語 EUC では成立しない.) どうもこの世界では,都合のいい想定は必ずいつかは破られることになっているらしい.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
問題点について解説 (スコア:2, 参考になる)
ここで述べている文字幅問題は、何度か紹介してきた、こちらで述べている問題 (日本語版を用意しました:-) とは違います。それ以前の問題です。
XFree86 の XTerm の UTF-8 モードは、Unicode Standard Annex #11 East Asian Width で「EastAsiamAmbiguous」に分類されている文字を、1 カラム (半角) 扱いします。そして、JIS X 0208 に含まれる多くの文字が (文字の多くが、ではない!)、EastAsianAmbiguous に分類される Unicode 文字にマッピングされます。それには、ロシア文字、ギリシア文字、●や★などの記号、が含まれます。
つまり、luit を使った EUC-JP XTerm は、現状では、ロシア文字、ギリシア文字、東アジアローカルな記号以外のほとんどの記号類を、半角で表示してしまいます。
Re:問題点について解説 (スコア:2, 興味深い)
昔懐かし日本語 EUCでは (いや,日本語だけではなく中国語等でもそうですが) 「G0, G1, G2 及び G3 の,各 G バッファ毎に文字の幅が一意に決定される」という,暗黙の前提があって, それを前提に多くのプログラムが書かれていたわけです.しかし,それはそれで一種の文字コード依存 (Code Set Dependence) ではあるわけで, そういうのを前提にしてプログラムを書いていた人は, Unicode べったりにプログラムを書く人を責められませんね.
でも, 文字コードのもつ性質に依存しない (Code Set Independence, CSI) ようにプログラムを書くのは, 移植性を考慮してプログラムを書くのと同じで, なかなか一朝一夕にできるものではありません. 移植性は,各種の OS やライブラリやコンパイラの 違いを知った上でなければ 考慮しろと言われてもできるものではないのですが, CSI による国際化は,各種文字コード,言語,習慣等の違いに対する移植性を考慮しろと言われるようなもので,こんどはそれらがどれくらい変わり得るかを知らなければならないわけですから.
たとえば,日本語 EUC や シフト JIS や Big5 や UTF-8 では, 「複数バイトの文字は,文字の1バイト目を見れば, その文字が残り何バイトあるかがわかる」 という性質があったわけですが,これが中国の新しい文字コードである GB18030 では成立しません. (GB18030 では,2バイト目まで見ればわかる.) いままで,それを想定していたプログラムはみんな書き直しになります.
それ以前にも,たとえば, 「文字のバイト数と画面上の表示カラム数は一致する」 という想定が破られたりしたことがありますね. (この想定は,シフト JIS では成立するが,日本語 EUC では成立しない.) どうもこの世界では,都合のいい想定は必ずいつかは破られることになっているらしい.
これに気付いたのは (スコア:1)