名前: ZR 日時: 2007-07-18 20:14:56 IPアドレス: 59.140.98.*
>>48753 栗山さん、こんばんは。 いま問題になっていることをその背景とともに説明します。（長文失礼） ■ 日本語の符号系と Unicode の間の互換性 - 多くの実用の日本語の符号系は、ASCII 類似の「半角」の文字集合と JIS X 0208 に由来する「全角」からなる。これに JIS X 0201 カナの集合(いわゆる 「半角カナ」)が含まれることがある。 # 半角/全角の呼称は等幅環境での字幅に由来する。プロポーショナル幅の # フォントと文字によっては、両者の違いを視認し難い場合もある。 - この組み合わせには幾つかの変種があり、Unicode への対応付けはそれぞれ 異なるが、ここではその詳細は扱わない。 * ASCII + JIS X 0201 カナ + JIS X 0208 * JIS X 0201 ローマ字 + JIS X 0201 カナ + JIS X 0208 * Microsoft のコードページ 932 # JIS X 0201 カナ(= 半角カナ)は省かれることもある。 - Unicode は上述の集合とのラウンドトリップの対応を保証する。すなわち、 日本語符号で「半角/全角」で重複する文字は Unicode でも重複した符号位置 (片方は互換文字)をもつ。 日本語符号(GL 表現) - Unicode ! - 半角 21h - U+0021 EXCLAMATION MARK ！ - 全角 212Ah - U+FF01 FULLWIDTH EXCLAMATION MARK A - 半角 41h - U+0041 LATIN CAPITAL LETTER A Ａ - 全角 2341h - U+FF21 FULLWIDTH LATIN CAPITAL LETTER A ア - 全角 2522h - U+30A2 KATAKANA LETTER A ｱ - 半角カナ 31h - U+FF71 HALFWIDTH KATAKANA LETTER A - しかし、上述の日本語符号の「半角」部分には Latin-1 は含まれない。だから Latin-1 の文字は、「全角」にのみ存在するか、全く含まれないかのいずれか であり、従って Unicode では重複する符号位置をもたない。 § - 全角 2178h - U+00F7 SECTION SIGN <a-acute> - (なし) - U+00E1 LATIN SMALL LETTER A WITH ACUTE # * Unicode の U+00A0〜00FF の範囲の文字は Latin-1 (GR 表現)で同じ符号 # 位置を持つ。 # * a-acute は JIS X 0212(補助漢字)の 2B21h に存在する。恐らく Unicode # のラウンドトリップ補償範囲に補助漢字は含まれると思うが、それでも # 日本語符号での「重複」は起こっていない。 - なお、ASCII/JIS X 0201 ローマ字以外の文字で Unicode に互換文字を持つもの が存在する(例: U+FFE0 FULLWIDTH CENT SIGN)が、これは CJK 圏内で用いられ た他の「半角」の国家規格/ベンダー規格の影響(と思う…)。 ここから導かれる重要な帰結は 「全角」の文字の中には Unicode で符号位置 U+0080〜00FF をもつものが存在 する(そしてそれは Latin-1 の符号位置と一致する)。しかし U+0000〜007F を もつものは存在しない。 というもので、これが upTeX の設計で問題になります。 ■ \char の仕様の問題 - pTeX/upTeX では文字を「欧文」「和文」の 2 つに分別して扱う。欧文は 00 〜FFh の符号空間をもつ。和文の符号空間は各実装の「内部(和文)コード」と 一致する(pTeX は EUC または SJIS; upTeX では Unicode)。 - TeX の \char<数値> は符号位置が <数値> であるプリミティブである。pTeX/ upTeX ではこれは和文にも使える。 - pTeX では欧文と和文の符号位置が重なっていないので、引数の数値によりその \char が欧文と和文のいずれのものかを判断できる。 - upTeX では和文の符号空間が Unicode なので、00h〜FFh の和文文字が存在 する。現状(v0.09)の upTeX では、この範囲の値の \char は * \kcatcode<n> が 15 ならば、\char<n> は欧文扱いとなり、欧文のエンコー ディング(例えば T1)の位置 <n> が出力される * \kcatcode<n> が 15 以外ならば、\char<n> は和文扱いとなり、Unicode の 位置 <n> が出力される のように処理される。 - ただし、upTeX の kcatcode は「Unicode ブロック」毎に値をもち、例えば \kcatcode0 と \kcatcode100 は常に同じ値になる。ここで問題になるブロック は「ASCII」(U+0000〜007F)と「Latin-1」(U+0080〜00FF)の 2 つ。 - 問題になるのは、この 2 つのブロックの kcatcode の既定値である。 - 注意すべきは pTeX では「和文文字」の集合は「全角文字」と一致していたと いう事である。つまり「ASCII ブロック」の全角文字は存在しないので、この 範囲の文字を和文扱いすることはない。だから、upTeX では欧文扱い(kcatcode =15)を既定値とすれば互換性が保たれる。 - 「頭が痛い」問題は「Latin-1」の方であり、先述のとおり、この範囲には全角 文字が存在する。従って次のようなことになる。 * この範囲の欧文扱いの \char は pTeX でも(fontenc 等で)頻繁に使われる。 * 一方、和文扱いを意図した \char<n> の n がこの範囲に来ることもある。 従って、upTeX においてこの kcatcode の既定値をどちらにしても、pTeX との 互換性の問題が生じる可能性がある。 - しかし、「Latin-1」の範囲の文字の和文扱いは欧文扱いよりも頻度がずっと低い ことが期待できる。その意味では、「Latin-1」の kcatoode を 15 にすること が妥当となる。しかし、kcatcode の「本来の」用法により、ソース中に「×」 を書いたときにそれが和文として扱われるという pTeX の動作を保つには、この kcatcode を 15 以外にする必要がある。(>>48752 の議論) - つまり、現状の仕様では、どうしても無視できない程度の互換性問題が生じる。 >便利さも含めて考えると(4)案がベストかもしれません。 この案というのは、 和文扱いの \char を欧文とは別(例えば \kchar)に設けるが、100h 以上の値 に対する \char は \kchar とみなす というものです。この場合、「全角の Latin-1 文字」に対する \char の互換性 が失われますが、その他は大丈夫です。
この書き込みへの返事：