異体字セレクタ

異体字を扱う新たな仕組み

InDesignやIllustratorでOpenTypeフォントを使っている人なら異体字切り替えの機能がどれだけ便利か分かっているのではないでしょうか。

コンピュータで文字を扱う場合、システムはシフトJISやユニコードといった文字コードを利用して個々の文字の符号（コードポイント）を特定し、その符号をキーにコンピュータに搭載されているフォントデータから文字の形状データを呼び出します。システムがその文字コードをサポートしていて対応するフォントさえあれば、この仕組みによって我々は確実に特定の文字を呼び出すことができるわけです。

すべての文字は文字コードで管理されるため、文字コードに登録されていない文字は扱うことができません。そのため、標準的でない文字を使う場合、これまでは外字データを作ったり外字専用フォントを使うなどして対処していたわけです。OpenTypeフォントとユニコード、そしてそれらをサポートするInDesignのようなソフトが登場してこの事態は大きく改善されます。

OpenTypeフォントは標準的な文字の異体字を数多く含んでおり、それを異体字切り替えという機能で利用することができます。日本人の名前によく出てくる“はしご高”や渡辺さんの“辺”の異体字なども、OpenTypeフォントを使うことで外字を作成する手間を大幅に軽減することができるようになったわけです。

ただしこの方法には弱点がありました。異体字切り替え機能を備えたOpenTypeフォントと、OpenTypeフォントをサポートするOS、アプリケーションでこの機能を使うというのがこの方法の前提であり、どれかひとつでも欠けていると使えないのです。

たとえば、プレーンなテキストのやり取りを考えてみましょう。プレーンなテキストはOpenTypeフォントの異体字切り替え機能はサポートしません。たとえテキストエディタがOpenTypeフォントの異体字切り替えに対応していたとしても、プレーンなテキストに保存した段階で異体字切り替えの情報は失われてしまいます（InDesignでInDesignタグに書き出すと異体字切り替え情報を書き出せるが、テキストそのものに異体字切り替えの情報が含まれるわけではなくInDesign独自のタグ情報で保持される。つまりInDesign以外のソフトでは利用できない）。

テキストデータは、文字コードのコードポイントで文字を特定します。通常、文字コードに異体字の情報は含まれません。テキストデータのフォーマットが異体字の情報に対応していない以上、プレーンなテキストのやり取りで異体字の指定はできないのです。DTPの場合、元原稿のテキストデータがOpenTypeフォントの異体字切り替え機能を利用できない形で入力される（プレーンなテキストやWordなどのデータ）ため、結局はテキストを流し込んだ後、InDesign上でオペレーターがいちいち異体字を切り替えていく必要があるわけです。

異体字の問題はDTPに限った話ではなく、学術論文や戸籍の管理など社会の多岐にわたって存在します。さまざまなケースで同じデータを使うことを考えると、OpenTypeの異体字切り替え機能はかなり限定的にしか利用できないでしょう。

こういった問題をOpenTypeフォントというフォントに依存する機能でなく、文字コードレベルで解決する方法として考え出されたのが「異体字セレクタ」です。

異体字セレクタの仕組み

異体字セレクタは、異体字の元になる文字を表す文字コードポイントに、字形を指定するコードを付加することで字形をより詳細に特定するという仕組みです。たとえば、「葛」という文字は現在、下が「人」の字形と下が「ヒ」の字形が一般に使われていますが、ユニコードではいずれも同じ文字として扱われ「U+845B」というコードポイントが与えられています。このコードポイントに「U+E0100」というコードポイントを付け加えると下が「ヒ」の葛、「U+E0101」を付け加えると下が「人」の葛が特定できるのです。

この元の文字に付加された「U+E0101」が異体字セレクタです。元の文字と比べて桁が多いことでも分かるように異体字セレクタが収録されているユニコードの領域は一般的な文字が収録されているBMP（基本多言語）面ではなく、追加特殊用途面と呼ばれる領域のU+E0100～U+E01EFになります。

異体字セレクタを使うためには、異体字セレクタに対応したOS、アプリケーション、フォントが必要です。対応するものとして、OSではWindows 7やMac OS X 10.6、アプリケーションではWindows 7のメモ帳やInDesign（CS4以降）など、フォントは小塚フォントのPr6N書体やIPAフォントなどがあります。また、Windows 7上のOperaやFirefoxでも異体字セレクタを使う文字を表示できるようです。

たとえばWindows 7で異体字セレクタを使うには、異体字セレクタに対応するアプリケーションで対応する書体を指定して元になる文字を入力します。次にMS-IMEのIMEパッドを開いて文字一覧を選び、文字カテゴリから「Unicode（追加漢字面）」-「バリエーションセレクター補助」を表示してU-E0100以降のセルをクリックし、Enterキーを押すことで確定、表示されます（InDesignはEnterキーを押さなくても確定する）。なお、現状のMS-IMEでは実際の字形が一覧に表示されないので、どこをクリックするとどのような字形になるか分からないという不便さがあります。

異体字セレクタが他の異体字を扱う仕組み（たとえばOpenTypeフォントの異体字タグなど）と違うのは、あくまでプレーンなテキストデータ上で異体字を指定するという点です。OpenTypeフォントの異体字タグなどは、OpenTypeフォントの異体字タグにアクセスできるInDesignのようなアプリケーションが、文字コード情報と別に異体字タグの情報を保持する必要があります。この場合、アプリケーションからいったんプレーンなテキストとして書き出した段階で異体字の情報はなくなります（InDesignタグのような専用テキストデータであれば保持できる）。つまり、アプリケーションをまたがった異体字の共有は難しかったわけです。

異体字セレクタは、その仕組みをサポートするすべての環境で利用することができます。しかも、書き出されたテキストデータ自体に異体字の情報が含まれるため、異体字セレクタをサポートしていない環境を経由しても情報が欠落しないのです（Unicodeのサロゲートペア領域を使うため、この領域が保持できない環境には対応しない）。

現状では異体字セレクタを使うには環境が十分整っているとは言えず、また、手間がかかるため使われるケースは多くはないでしょう。しかし、今後アプリケーションの対応が進み、対応フォントも増えてくると利用が急速に進むことも考えられます（特にMS-OfficeとMS書体が対応すれば一気に環境が整うことになる）。特に、電子書籍などで異体字を扱うためにはもっとも有効な方法と言えるでしょう。

なお、現在、異体字セレクタで表現される異体字には、Adobe-Japan1-6をベースにしたものと汎用電子コレクションという文字セットをベースにしたものがあります。この2つの文字セットはそれぞれ別々にISOに登録されていて、重複する字形が少なからずあります。実際に運用が進むと重複する字形がダブって登録されていることで混乱する可能性もあります。

（田村　2012.6.4初出）

（田村　2016.5.25更新）