Unicodeの互換文字

Unicodeの互換文字とは、ユニコードコンソーシアムが使わないことを推奨している、図形文字の一群である。UnicodeとUCSについて議論するときに言及されることが多い。

Unicodeコンソーシアムの用語集によると、既存の文字コードとの互換性と往復変換のためだけに収録された文字のことである。 しかし、定義はその用語集に表れているものよりも複雑である。ユニコードコンソーシアムが文字に与えている特性の1つとして、文字の分解や互換分解がある。ほとんどの文字はこの特性に値を持たないが、5千を超える文字に互換文字から1つかそれ以上の他の文字へ互換分解がある。Unicodeは分解特性が設定されている文字が互換文字であると定めている。これらの互換性を指示することの理由はさまざまであり、詳細は後述する。文字は1文字に「分解」される場合もあるので、分解という用語は混乱を招くことがある。この場合、1文字の分解は単に等価な別の文字への置き換えである。

1. 正準と非正準
---------

5,402種類のUnicode互換文字の互換分解特性には、互換文字を17の論理的なグループに分けるキーワードが含まれている。キーワードのないものは正準等価なもしくは正準分解可能な文字という用語で呼ばれる。これらの文字は最も近い関係を持つ。他のキーワードは以下のとおりである: 、、、、、、、、、、、、、、。これらのキーワードは、互換文字とその互換分解文字の並びとの間に存在する関係を暗示する。しかし、互換文字は — 正準であるかどうかを問わず — 3つの基本的なカテゴリに分けられる:

複数の代替字形に対応する文字と合成済みのダイアクリティカルマーク。完全なUnicodeのテキスト描画処理に対応していないソフトウェアやフォントの実装をサポートするためもの。
他の文字コードから収録された文字。さもなければUnicodeの目的であるプレーンテキストよりむしろリッチテキストの構成要素としてUCSに追加されたもの。
その他の意味的には異なるが、視覚的には似ている文字。これらの意味的に異なる文字は他の文字のグリフと似たグリフで表示されることがあるので、テキスト処理ソフトウェアは起こりうる混乱を解決するようエンドユーザーのために努力すべきである。テキスト文字列の比較や照合を行うとき、異なる字形や文字のリッチテキスト版がテキスト処理の結果を変えるべきではない。たとえば、ソフトウェアの利用者は大文字のラテン文字‘I’をページ上で検索したときに、そのソフトウェアが視覚的に類似したローマ数字の‘JIS2004フォント’を見つけられなかったら混乱するかもしれない。

2. 互換マッピングの種類
-------------

2.1. グリフの置換と合成
--------------

互換文字の中には、テキスト処理や表示を行うソフトウェアにとってUnicode標準へ適合するためにまったく重要でないものも存在する。これらは以下の通り:

合成済みダイアクリティカルマーク。たとえば‘Å’など。Unicodeはこれらの書記素を大文字のラテン文字‘A’にenを結合した、2つの別々の文字として扱うことを好む。
合字。ラテン文字において、‘ffi’のような合字は従来の文字コードではしばしば別々の文字として符号化される。Unicodeの合字に対するアプローチはそれらをリッチテキストとして扱い、もし有効にされたら、グリフ置換で扱うことである。
合成済みローマ数字。たとえば、ローマ数字の12  は、ローマ数字の10  と2つのローマ数字1  に分解できる。
合成済み分数記号。これらの分解はキーワード を持つ。完全に適合するテキスト処理実装は分数‘¼}}’と合成された分数‘1⁄4’を同じように表示すべきである。
文脈依存のグリフや字形。これらは基本的にアラビア文字で発生する。OpenTypeやTrueType GXのようにグリフ置換の機能を持つフォントを使うことにより、Unicodeに適合するソフトウェアは文字が単語の先頭、中央、末尾のどこに現れるか、あるいは単独で現れるかに応じて、同じ文字を適切なグリフに置換できる。このようなグリフ置換機能は東アジア言語の一部で縦書きテキスト描画を行うためにも必要である。この場合グリフは全角、半角、小書きなどの字形に置換されたり合成されたりしなければならない。Unicode適合でないソフトウェアや他の文字コードを使うソフトウェアは、位置に応じて同じ字母を使う代わりに複数の独立した文字を同じ字母に使う。これによってテキスト処理はさらに複雑になる。UCS、Unicodeの文字特性とUnicodeのアルゴリズムはソフトウェア実装がこれらの文字を、その対応する分解から正しく表示するために必要なものをすべて提供する。そのためこれらの分解可能な互換文字は冗長で不必要なものとなる。それらが文字コードに存在することによって、テキストを正しく比較や照合するために余分なテキスト処理が必要になってしまう。しかも、これらの互換文字によって意味が追加されたり区別されたりすることはない。これらの文字にはテキスト描画処理とフォントがUnicode適合であるときに提供される描画結果との、視覚的な違いもない。さらに、これらの文字は他の文字コードとの往復変換のために必要なわけでもない。翻字によって、分解された文字を他の文字コードの対応する合成済み文字にマップできるからである。同様に、アラビア文字の語尾形のような文脈依存の字形は、その単語中の位置によって適切な従来文字コードの字形文字にマップできる。

これらの互換文字を捨てるために、テキスト処理ソフトウェアはいくつかのUnicodeの規約に適合しなければならない。ソフトウェアは以下のことができなければならない:

字母を表す文字と1つかそれ以上の独立した合成用ダイアクリティカルマークからダイアクリティカルマーク付きの書記素を合成すること。
合字や文脈依存のグリフ変化形を置換できること。
フォントデータから、もしくは必要に応じて合成することにより、小書き、縦書き、半角、全角用のグリフに置換してCJKVのテキストを縦方向に描画できること。
分数用スラッシュ‘⁄}}’ と任意の他の文字を使って分数を組み立てられること。
en  と他の記号と組み合わせられること。たとえば、‘∃’、‘∈’、‘∋’に対する‘∄}}’、‘∉}}’や‘∌}}’ 。互換文字であると指定された5,402種類の文字のうち合計3,779文字が、不完全なUnicode実装のためにまとめて収録されている互換文字である。これらにはキーワード 、、、、、、、、、 を付けられた互換文字がすべて含まれる。さらに、ほとんどすべての正準分解とほとんどの キーワードが付いた互換文字が含まれる 。

2.2. リッチテキスト互換文字
----------------

他の互換文字の多くは、Unicodeがリッチテキストであると考え、それゆえUnicodeとUCSの目標から外れたものからなる。ある意味では前節で述べた互換文字 — 従来のソフトウェアが合字や縦書きテキストを表示するためのもの — でさえリッチテキスト形からなると言える。なぜならばリッチテキストの規約がテキストの表示される方法を決定するからである。しかし、テキストの表示に合字を使うか使わないかや縦書きと横書きのどちらを使うかの選択は、どちらも意味を含まないリッチテキストである。それらは単なるスタイルの違いである。これはのような斜体、上付き文字、下付き文字やリストマーカーのような、スタイルがそれに伴う何らかの意味を暗示する他のリッチテキストとは対照的である。

プレーンテキストの比較、照合、処理、格納の目的では、リッチテキストの変化形は意味的に冗長である。たとえば、上付き数字 4 の使用は標準の数字 4 を使ってからそれを上付きにするリッチテキスト規約を使うことと識別不可能な可能性が高い。このようなリッチテキストを代替する文字は、来往するプレーンテキスト文字にリッチテキストの整形を施したものと視覚的に区別がつかないので、曖昧さを作り出す。これらのリッチテキスト互換文字には以下のものが含まれる:

数学用英数記号。これらの記号は単にラテン文字とギリシア文字とインド・アラビア数字に15の異なる書体で繰り返し複製しただけである。これらは数式表記用に任意の文字を提供するパレットを目的としている。しかし、これらは文字の符号化と視覚的なグリフの符号化との区別や、プレーンテキストの文字のみをサポートするというUnicodeの目標を損ないがちである。このようなスタイルを代わる代わる並べた数学記号用のパレットは、リッチテキストの規約を代わりに使うことで簡単に作成できる。
括弧付き文字。これらは基本的にリストマーカー用として用意された文字である。プレーンテキストの構成要素ではない。しかも、UCSが提供する括弧付き文字の種類は限られているので、他のリッチテキスト規約を使うほうが適切である。
丸付き英数字と丸付き漢字。この丸付き字形もマーカーがよくある用途である。繰り返しになるが、文字とともにリッチテキスト規約を使って文字を丸で囲むほうがより柔軟である。
さまざまな幅の空白とノーブレークスペース。これらの文字は単に、通常の空白  やノーブレークスペース  のリッチテキスト版である。代わりにトラッキング、カーニング、ワードスペーシング属性のような、他のリッチテキスト規約を使うべきである。
上付き文字と下付き文字。上付きと下付きの文字はその多くが国際音声記号や他の文字体系とは実際に意味が異なる文字であり、実際にはリッチテキストの範疇には含まれない。しかし、それ以外のギリシア文字、ラテン文字、数字に関しては、単なるリッチテキストの表現形を構成しているだけである。これらのリッチテキストの上付き文字や下付き文字はこのリッチテキスト互換文字用のカテゴリに正しく所属する。これらのほとんどは "Superscripts and Subscripts" か "Basic Latin" ブロックに存在する。以上のリッチテキスト互換文字のいずれについても、グリフの表示は通常その互換分解文字と異なる。しかし、これらは互換文字であるとみなされ、ユニコードコンソーシアムは使わないことを推奨している。なぜならばそれらはUnicodeがUCSと関連する規約によってサポートしようとしているプレーンテキスト文字ではないからである。リッチテキストはUnicodeの規約ではなく、HTML、CSS、RTF等々のUnicode以外の規約によって処理されるべきである。

リッチテキスト互換文字は5,402種類の互換文字のうち1,451種類を占める。キーワード と が付けられた互換文字はすべてこの中に含まれる; と正規文字のうち空白の変種11種; および "Superscripts and Subscripts" ブロックにある、キーワード と が付けられたもののうちいくつか。

2.3. 意味的に違いのある文字
----------------

多くの互換文字は表現するグリフを他の文字と共有するかもしれないが、意味的には違いのある文字である。これらの文字のうちいくつかは、1つの用字系や表記体系に特化した他の文字コードのほとんどのために含まれている場合がある。たとえば、ISOや他のラテン文字集合はπ  用の文字を含んでいる可能性が高い。なぜならば、基本的に1つの表記体系や用字系に集中するとき、それらの文字コードはそうでもしなければよく使われる数学記号であるπ用の文字を含むことはないからである。しかし、Unicodeでは、数学者は世界中の既知の用字系から自由に文字を使ったり、数学的な集合や数学的な定数の代わりとして統合漢字を選択したりできる。今まで、Unicodeはごく少数の数学定数用に特定の意味的サポートを追加しただけである。そのためUnicodeはギリシア文字やヘブライ文字に基づくいくつかの数学記号を互換文字に指定している。これには以下のものが含まれる:

ヘブライ文字に基づく記号 : ℵ}} アレフ 、ベート 、ギーメル  およびダレット 
ギリシア文字に基づく記号 : ベータ 、シータ 、ファイ 、パイ 、カッパ 、ロー 、大文字のシータ 、プロスゲグラメニ 
ラテン文字の異体 : Long Latin Letter S 。このラテン文字の字母はゲール語で使われる。これらの互換文字はその互換分解文字とは、名前に "symbol" が付けられているという点でのみ区別されるが、数式の表記においては長年異なる意味を表している。しかし、すべての現実的な目的ではそれらは互換等価なギリシア文字やヘブライ文字と同じ意味を共有している。これらは意味的に識別可能な文字の境界線上にあると考えられるので、互換文字の合計数には含めていない。

Unicodeはその他の字母に似た記号28種類も互換文字に指定している。

その他のギリシア文字に基づく記号 : Lunate Epsilon 、Lunate Sigma 、大文字Lunate Sigma 、Upsilon with Hook 
数学定数と物理定数 : オイラー数
単位記号 : オングストローム 、オーム 、ケルビン 、華氏 、摂氏 、マイクロ記号 
通貨記号: ルピー記号 
約物 : 一点リーダ 、ノーブレークスペース 、ノーブレークハイフン 、Tibetan Mark Delimitter Tsheg Bstar 
他の字母に類似した記号 : Information Source 、Account Of 、Addressed to the Subject 、Care of 、Cada una 、Numero 、電話記号 、FAX記号 、商標 、サービスマーク 加えて、いくつかの用字系は意味を区別するために上付きや下付きのグリフ位置を使う。これらの場合、上付き文字や下付き文字は単なるリッチテキストではなく、表記体系において — ダイアクリティカルマークと字母の混合と同様に — 異なる文字を構成する。

国際音声記号のような発音記号からの、抽象的な音素を表現する文字112種類。グリフの位置が意味的な違いを表す 
漢文ブロックからの15文字 
ティフナグ文字からの1文字: Tifinagh Modifier Letter Labialization Mark 
グルジア文字からの1文字: Modifier Letter Georgian Nar 
ラテン1補助ブロックに含まれる男性記号  と女性記号  の序数標識最後に、Unicodeはローマ数字が同じグリフを共有するラテン文字と互換等価であると指定している。ここでUnicode標準はしばしば防ごうと努めてきた、グリフと文字の混同と同じ過ちを犯している。確かにこれらの文字が同じグリフを共有していた場合の視覚的な曖昧さを解決する必要はあるが、桁記号記数法の数字用である片方はラテン文字の大文字や小文字の‘i’とは確実に意味的な違いがある。同様の視覚的な曖昧さはラテン大文字A  とギリシア大文字アルファ  のような文字の間にもあるが、Unicodeはこれらの文字を統合していない。

大文字のローマ数字: 1 、5 、10 、50 、100 、500 、1000 
および小文字版: 1 、5 、10 、50 、100 、500 、1000 
18種類の合成済みローマ数字の大文字版と小文字版ローマ数字の1000は実際には同じ意味的な単位を表す第三の字形またはグリフを表現する第三の文字を持つ: One Thousand C D 。このグリフからは、ラテン文字 M 使用の慣習によって生ずるものを見られる。奇妙なことに、Unicodeは sign-value ローマ数字をまったく異なるラテン文字に統合しているが、インド・アラビアの位取り十進記数法に使われる数字はUCS全体を通して24回繰り返され、それらの間にはいかなる関係や分解マッピングも定義されていない。

互換文字の中にこれら146種類の視覚的には類似しているが意味的に異なる文字が存在していることが、互換文字の話題を複雑にしている。内容の書き手は互換文字を使わないよう推奨することを提案している者もいる。しかし、特定の専門領域ではこれらの文字は重要であり、互換文字に混ざられなかった他の文字ときわめて類似している。たとえば、特定の学会においてはローマ数字の使用を同じグリフを共有するラテン文字と区別することには、楔形文字の数字と古代ギリシア文字の数字を区別することと違いがない。ローマ数字の文字をラテン字母の文字にまとめることは、意味的な違いを失わせる。同様の状況が上付きや下付きのグリフを使用する発音記号にも存在する。発音記号を使用する専門分野の学会では、書き手はリッチテキスト規約の助けを借りずに達成できるべきである。

3. 互換ブロック
---------

いくつかのUnicode文字のブロックは完全に、もしくはほとんど完全に互換文字のみを含んでいる。これらの互換ブロックは意味的に違いのある互換文字を含んでいないので、推奨されない文字の集合へ曖昧さなしに分類できる。Unicodeはプレーンテキストの対応する互換分解を代わりに使用し、リッチテキストのマークアップで補完することを書き手に推奨している。このアプローチは、ひとつだけ例をあげれば丸付きや括弧付きの英数字の有限の集合を使うよりもはるかに柔軟で、制約が少ない。

しかし、互換ブロックに存在しながらそれ自身は互換文字ではなく、それゆえに書き手に混乱をもたらす可能性のある文字が少数存在する。"Enclosed CJK Letters and Months" ブロックは互換文字でない文字を1つ含んでいる: ‘韓国規格記号’  である。この記号と 12 の他の文字が互換文字のブロックに含まれている理由は不明である。“CJK互換漢字”ブロックがこれらの互換漢字ではない統合漢字を含んでいる。

これら13種類の文字は互換文字でもなければ、いかなる意味で使用が非推奨なわけでもない。

これらのブロックに含まれる他の文字のいくつかは互換分解を持たないが、明らかに従来文字コードのサポートを意図している:

アルファベット表現形 

Hebrew Point Judeo-Spanish Varika : ﬞ. これは Hebrew Point Rafe : ֿ の異体字であるが、Unicodeは互換分解を与えていない。アラビア文字表現形 

"Ornate Left Parenthesis" : ﴾. U+0029 ‘)’の異体字
"Ornate Right Parenthesis" : ﴿. U+0028 ‘ (’の異体字
"Ligature Bismillah Ar-Rahman Ar-Raheem" : ﷽. バスマラ }} は Teh Marbuta }}、Lam }}、Meem }}、Seen }}、Beh }}、の合字である。
"Arabic Tail Fragment" : ﹳ. バスマラ }} は Te 文脈依存のグリフ処理に対応していない文章システムのサポート用CJK互換形

傍点 :
白い傍点 : 囲み英数字

11種類の黒丸数字: ⓿}}、
10種類の二重丸付き数字:

4. 正規化
------

正規化は、Unicodeに適合するソフトウェアがテキスト文字列の比較や照合を最初に行う互換分解の手続きである。これは、たとえば、利用者があるテキスト内で大文字小文字やダイアクリティカルマークを区別しない検索を行うときに必要とされる他の処理に似ている。このような場合ソフトウェアは通常同一視したり無視したりしない文字を同一視したり無視したりしなければならない。一般に正規化は構成する格納テキストのデータを変更することなしに行われる。しかし、ソフトウェアによっては正準等価な互換文字を、場合によっては正準等価でない互換文字さえも取り除く永久的な変更をテキストに加える可能性があるかもしれない。

5. 脚注
-----

用語の日本語表記は原則として次にならった。