名前: ttk 日時: 2007-07-20 00:38:54 IPアドレス: 61.210.211.*
>>48753 >>48761 >>48765 栗山さん、ZRさんこんばんは。 ZRさん、詳細な解説ありがとうございます。 > Unicode では（1）Latin-1 に含まれる > セクション記号と（2）日本の「全角」セクション記号は同じもの > であると考えているわけですね。 > # もしこの二つが「異なった文字」という認識であれば、例えば > # "FULLWIDTH SECTION SIGN" 等の別な名前が与えられ、別な文字 > # として扱われたと思われるからです（重複している、いないに > # かかわらず） そもそも、(グリフコードではなく)文字コードに、 同じ文字なのにも拘わらず文字幅だけが異なるという理由で別の符号が割り当てられることの方が異常なことだ、 という考え方もあります。 また、JIS X 0208(JIS第1,2水準)やISO 8859-1(Latin-1)、文字幅を規定しているわけでもなく、 「全角」「半角」という区別も、 ShiftJISなど(そしておそらく中韓のBig5,GBK,UHCも)で等幅フォントを使う実装で そういう手段が選ばれてきた例が多数ある、というだけで規定されていたわけではありません。 この観点に立てば、「全角」「半角」の両方が同時に存在するのは忌むべき多重符号化であり、 むしろ「全角」「半角」の差は、区別すべきではない・無視すべき違いである、 ということになります。 Unicodeの考え方は、原則的には、このようなものです。 しかし、それでは、ShiftJISなどとの互換性、相互運用で破壊的なことになるので、 普及している過去の文字コードとの相互変換だけは保証するようにしましょう、ということで 「FULLWIDTH 〜」「HALFWIDTH 〜」というものも互換文字として割り当てられました。 つまり、「＠」「@」などの全角半角の区別は、 Unicodeにおいては、どちらかというと原則から外れた救済措置の意味合いが強いです。 # じゃあ、全角スペース「 」はなぜ互換文字でない? # なぜUnicodeには幅の違うスペースやダッシュが沢山ある? という話もありますが… セクション記号に関しては、 Unicode開発当時に普及していた文字コードの中に、 JIS X 0208(JIS第1,2水準)等(日中韓の多バイトコード)とISO 8859-1(Latin-1)等を同時に含んだものは無かったので 全角半角の区別は必要なかった、ということになります。 (ISO-2022-JP-2のように同時使用が可能なものは存在したが、普及率が低かったので無視された) # じゃあ、セント記号は? という話もありますが… pTeXについて言えば、 ShiftJIS/EUCでそうであるように、 7bit1byte→欧文、8bit2byte→和文という住み分けを利用して 欧文・和文が文字コード上で単純に区別できることを前提にしています。 pTeXで、8bit1byteの欧文を使おうとすると かなり巧妙な抜け道を必要とするのはpTeX+babelでお分かりでしょう。 Unicodeでは、文字コードを見ただけで欧文／和文の区別を容易に決定することは出来ません。 和文主体と最初から決まっているなら、 「JIS X 0208にある文字は全て和文、その他は欧文」のようなやり方も考えられます。 土村さんのpTeXのUTF8対応は、内部動作の基本がJIS X 0208系ですから、このやり方でやったのが自然です。 upTeXでは、pTeXの和文／欧文を明確に区別した組版方法をそのままに、Unicodeベースかつ 和文も欧文も使いやすいことを狙っている(強欲)のでそうは行きません。 和文も欧文も使えるようにするには、文字コードの値を手掛かりにするわけにはいきません。 TeX族では幸いマークアップする機構も習慣もあるので、その手で切り替えることにして、 欧文／和文を切り替える機構を\kcatcode の拡張で作り込もうとしています。 \char や「§」の問題が特に目立つのは、 文字コード0x80〜0xFFの間では生のコード値そのものを欧文TeXで良く使うし、 和文pTeX相当でも無視するわけにいかないからです。 つまり、 「欧文／和文の区別問題」に加え「生のコード値の直接利用」があるので 文字コード0x80〜0xFFの問題が大きくなっています。 OmegaやXeTeXにupTeX的な和文を入れようとすると、 「欧文／和文の区別問題」&「生のコード値の直接利用」のコード領域はさらに広がるので、 もっとややこしいことになりそうです。
この書き込みへの返事：