ぼくがまとめたものを見てもらえるとわかるように、マイクロソフトは前者、ほかは後者の考えをとっているようです (実際には、変換テーブルの混乱が見られるのは Shift-JIS 系のコードですが、Shift-JIS と EUC-JP の JIS X 0208 部分は計算式で変換するものなので、EUC-JP もその混乱の影響を受けます)。ただし、これらの変換表は Unicode Consortium によって obsolete とされてしまいました。ちなみに、Unicode Consortium 公式と思われるこのコメントは、前者の考え方に立っているようです。
次に、Unicode の各々の文字のどれを全角、どれを半角にするか、という問題ですが、Unicode Standard Annex #11 East Asian Width という文書があります。それは、すべての Unicode 文字を、「半角」「全角」「文脈依存」に分けます (ほんとはもっとたくさんに分けるのですが)。で、U+00A3 は「半角」に分類されています。
Re:ロケール自動認識 (スコア:4, 参考になる)
えっと、きちんと説明しましょう。EUC-JP には、ポンド記号はひとつしかありません。JIS X 0208 に含まれているもので、通常は全角文字の扱いになります。
一方、Unicode には、通常の「ポンド記号」U+00A3 £ のほかに、「全角ポンド記号」U+FFE1 £ があります。EUC-JP のポンド記号「£」をどちらに割り振るか、には、ふたとおりの考えができます。
ぼくがまとめたものを見てもらえるとわかるように、マイクロソフトは前者、ほかは後者の考えをとっているようです (実際には、変換テーブルの混乱が見られるのは Shift-JIS 系のコードですが、Shift-JIS と EUC-JP の JIS X 0208 部分は計算式で変換するものなので、EUC-JP もその混乱の影響を受けます)。ただし、これらの変換表は Unicode Consortium によって obsolete とされてしまいました。ちなみに、Unicode Consortium 公式と思われるこのコメントは、前者の考え方に立っているようです。
次に、Unicode の各々の文字のどれを全角、どれを半角にするか、という問題ですが、Unicode Standard Annex #11 East Asian Width という文書があります。それは、すべての Unicode 文字を、「半角」「全角」「文脈依存」に分けます (ほんとはもっとたくさんに分けるのですが)。で、U+00A3 は「半角」に分類されています。
「文脈依存」に指定されている文字には、たとえば記号の多くやロシア文字があります。EUC-JP ではロシア文字や記号の多くは全角で表示されますから。
ところが、ポンド記号は、対応する全角ポンド記号が Unicode に定義されているために、半角に指定されています。これが問題のもとです。これを解決するには、
の3とおりの解決法があります。いずれにしても、全世界で統一した解決法をとるべきです。
ところで (忘れてた)、現バージョンの XTerm は、「ポンド半角問題」のような複雑な問題だけではなく、もっと単純な問題も抱えています。それは、「文脈依存」に指定されている文字を必ず半角に割り振っている、ということです。Robert Brady さんが作ってぼくがちょっとだけ手直しした xterm-152-27 では、ロケール自動認識に加え、文字幅モードも複数用意するなど、いちおう使える (ただしポンド半角問題は Unicode の定義と変換テーブルの問題なので、XTerm 単体では解決しない) ところまできていました。しかし、XFree86 に巣食う、UTF-8 以外は使いにくくなければならないという信念に基づいて行動しているとしか思えない人々のせいで、それは棚上げとなっています。
というわけで、XTerm では、ポンド記号以外にも、非常に多数の記号において、全角で表示したいものが半角になってしまうという問題があるのでした。