● 字形選択子を使って異体字に置き換える
今回はUTS#37に基づいて、どのように異体字シーケンスが規定されているのか詳しく見てみよう。これの符号表現の考え方は、第2部第5回で述べた結合文字を使った合成列と全く同じものだ(第5回図2/第8回図1参照)。合成列では、例えば「ダ」という平仮名は「タ」(U+30BF)に結合文字の濁点(U+3099)を合成させることで「ダ」という文字の形を表現していた。これと同じように、例えば「箸」を表すU+7BB8の後に特定の文字(これを字形選択子と呼ぶ[*1])を並べることで任意の異体字に置き換える。つまり単一の文字で異体字を表すのでなく、符号を並べて表現するので「シーケンス」(並び)と呼ぶわけだ。
|
図1 異体字シーケンスの仕組み。統合漢字、および拡張領域に収録された漢字と、U+E0100からU+E01EFに収録された字形選択子が合成することで、未定義の文字に置き換わる
|
字形選択子は普段は目に見えない特殊な文字とされており、例えば現在のところWindows VistaやMac OS Xでは一般的な手段では入力できない。また、これと合成できるのは統合漢字と拡張領域に収録された漢字だけとされている。つまり互換漢字は異体字シーケンスから排除されている。
ここで注意したいのは、異体字シーケンス用の字形選択子がUnicodeでは第14面のU+E0100からU+E01EFの範囲(240字)に収録されていることだ[*2]。つまりこれを扱うにはサロゲートペアへの対応が前提となる[*3]。もっともWindows VistaやMac OS Xで対応ずみのJIS X 0213の中には第2面に収録された文字があり、これに対応したアプリケーションなら問題なく扱うことができるはずだ。
● メーカー外字をUnicodeに取り込む枠組み
では、異体字シーケンスはどのようにしてUnicodeへの収録が決まるのだろう。これは収録を希望する団体がUnicode社に対して自分たちの文字セットを登録申請する形になっている[*4]。一定の要件と手続きを踏めば誰が登録してもよいし、手続きが適正ならUnicodeは申請を拒む理由はない。一連の流れはUTS#37によって次のように決められている[*5]。
(1)申請者はWebサイトに文字セットのデータ(コレクションと呼ぶ)を公開する。
(2)申請者はUnicodeメーリングリストにコレクションを公開したことを告知する[*6]。
(3)最低90日間の公開チェックが開始される。申請者は質問や指摘に回答しなければならない。
(4)チェック期間の終了後、申請者はUnicode社に登録書類を提出し登録料を支払う。
(5)Unicode社は手続きが正しくされたと判断した後に、コレクションを『Ideographic Variation Database』に登録する[*7]。
|
この手順を通してわかることは、要するにこれは今までメーカーが社内で抱え込んでいた外字セットを、第三者のチェックを経由させた後にUnicodeに取り込む手続きであるということだ。そうすることで今までUnicodeで未定義だった文字を情報交換可能にし、メーカー外字セットとの間で往復の保全性を確立できる。
● 字形選択子は「デフォルト無視可能」
もう1つ大事なことがある。字形選択子はUnicode規格本文によって、これに対応しないOSやアプリケーションにとって不可視であり、同時に無視されなければならないとされる[*8]。つまり同じく不可視である制御符号のように、読み込むと思わぬ動作を引き起こすようなことがあってはならない。だから未対応のOSやアプリケーションで異体字シーケンスを読み込んでも、字形選択子だけ無視されて、その前にある統合漢字が表示されるだけとなる。これをUTS#37では「default ignorable」(デフォルト無視可能)と表現する。
前回述べたように、互換漢字はネットワークを伝送していく中で、いつ、どこでUnicode正規化が行われ、統合漢字に置き換わるかわからない不安定な文字だ。この異体字シーケンスも、同様に対応しない環境では統合漢字が表示されることになるから、互換漢字と同じ不安定なもののように思える。しかしそれと違う点は、互換漢字がどこで置き換わるか全く予想できないのに対し、異体字シーケンスでは、対応した環境では指定された異体字、未対応の環境では統合漢字および「□」「・」などの表示と、環境によって振る舞いがあらかじめ想定できる点だ。
また第2部第7回で紹介したMac OS X版InDesign CS3の例のように、互換漢字がUnicode正規化で統合漢字に置き換わった後、変更後の符号位置が確定してしまう場合もあるのに対し[*9]、異体字シーケンスではそういうことはない。未対応環境で統合漢字及び「□」「・」などが表示された場合でも、同じテキストを対応した環境に持ってくれば何事もなかったように異体字を表示する。少なくともUnicode規格本文ではそのような振る舞いを求めている。
● 包摂された字体が区別可能になる
異体字シーケンスにはここまで述べたメーカーの外字セットを取り込むという目的以外に、常用漢字表の改定など国語施策の動向と関連して、もう1つ大きな目的があると考えられる。実際に今のところ唯一異体字シーケンスのコレクションを登録している、Adobe SystemsのAdobe-Japan1を見てみよう[*10]。UTS#37によれば、異体字シーケンスとしての符号の並びを記録するのは「IVD_Sequences.txt」というテキストファイルということになっている。UnicodeのWebサイトに掲載されているAdobe-Japan1のIVD_Sequences.txtで、ここまで例に挙げてきた「箸」を表すU+7BB8の異体字シーケンスがどうなっているかを抜き出してみよう(図2)。
|
図2 Adobe Systemsが登録したAdobe-Japan1における「箸」(U+7BB8)の異体字シーケンス。IVD_Sequences.txtは「;」を区切りとする3つのフィールドからなっている。第1フィールドは異体字シーケンスで表される異体字の親字にあたる統合漢字の符号位置と、これに組み合わされる字形選択子の符号位置(つまり異体字シーケンス)。第2フィールドはコレクション名、そして第3フィールドはそれぞれの異体字シーケンスを一意で表す名前だ
|
これを見ると、従来のフォントで符号位置に対応させていた文字の形も含め、Adobe-Japan1で表現可能なすべての異体字が定義されていることがわかる。一見すると、これは無駄なように思える。例えば同社のOpenTypeフォント「小塚明朝Pr6N」は異体字シーケンス対応以前からU+7BB8に対してCID+7775を対応させている。つまり何もしなくてもU+7BB8に対してはCID+7775を表示するようになっていた。それを異体字シーケンスに対応後は、これに加えて異体字シーケンスを使った場合でもCID+7775が出るようにしている。
一見すると無駄なように思えるが、しかしこうすることで今までU+7BB8という符号位置に包摂され、どちらか片方しか使えなかった「CID+3384」と「CID+7775」という文字の形を、区別して使うことが可能になり、フォントを切り替えても「U+7BB8/U+E0101」というシーケンスである限り必ずCID+7775を表示するようになる。
● フォントを切り替えると字体が変わってしまう「混乱」
ところで、この図2をWindows Vistaで見たユーザーから次のような疑問が出るかもしれない。「自分の環境ではU+7BB8は“点なし”ではなく“点つき”の箸だ」と(これは図1も同様)。そう、現在の日本のコンピュータにおける日本語環境は過渡期にある。U+7BB8に対してデフォルトで「点なしの箸」を対応させる旧来の環境と、同じく「点付きの箸」を対応させる新しい環境が併存している状態だ。上の図2は「旧来の環境」(フォント)によって作成されたものだから、例えばWindows Vistaなどでこれを見た人は、「自分のパソコンの字と違う」と違和感を持つことになる。
これは具体的にいうと、「旧来の環境」が2000年に制定されたJIS X 0213初版に基づくのに対し、「新しい環境」は2004年改正版に基づくことによる。第2部第1回で少し説明したように、2004年の改正では表外漢字字体表(2000年国語審議会答申)に対応するため、168面区点の例示字体変更を行った(図3)。そこで例えばWindows XPやバージョン10.4までのMac OS XはJIS X 0213初版、対してWindows VistaやMac OS Xバージョン10.5では2004年改正版に基づくフォントをデフォルトとするというような違いが生じた。
|
図3 JIS X 0213初版における面区点1-40-04(上)と、2004年改正版の例示字体(下)。2004年改正版では点が追加されたことがわかる(『JIS X 0208:1997』[*11]1997年、P.135、日本規格協会/『JIS X 0213:2004』2004年、P.28、日本規格協会)
|
つまりOSが標準装備するフォントのマッピングによって、字体が異なる漢字が表示されてしまう。これは文字コード規格の改正により発生した事態なのだが、だからといって責任を文字コード規格に負わすことはできない。文字コード規格では符号位置に対応付けられる文字に対して一定の範囲で字体の揺れを許している。これが包摂の範囲だ(UCS/Unicodeでは統合の範囲)。そのような揺れがあっても「同じ字とされる社会的な合意」があり、混乱は発生しないと信じられたからだ。この「箸」の場合でいえば、点の有無が問題にされること自体が文字コード規格の想定外だったことになる。包摂の範囲内で字体が変わることは、規格にとってある意味当然なのだ。しかし国語施策としての表外漢字字体表はこれを問題にし、点のある「箸」の方を正統とした。この「混乱」はここに起因する[*12]。
異体字シーケンスはこれを解決しようとする目的があると思われる。続きは次回で説明しよう。また次回は第2部の最後として、この異体字シーケンスが本当に互換漢字の代わりとなりうるのかを考えてみたい。
[*1]……Unicode/UCS(ISO/IEC 10646)では「Variation Selector」。字形選択子はUCSの翻訳版であるJIS X 0221における呼び名。この原稿ではJISに従う。
|
[*2]……字形選択子そのものはBMP(注釈3を参照)であるU+FE00~U+FE0Fにも存在するが、これらはUTS#37によって異体字シーケンスでの使用は禁じられている。
|
[*3]……UCS(ISO/IEC 10646)では16ビット(2進数で1文字は16桁、6万5536文字まで表現可能)で符号化できる範囲を面(Plane)と呼び、特に最初の第0面をBMP(Basic Multilingual Plane)という。Unicodeと一本化する以前、UCSでは面を256集めたものを1群とし、全部で128群(21億4748万3648文字)を符号化する計画を立てていた。これに対して最初期のUnicodeは、16ビットの範囲で世界中の文字が符号化可能と主張していた。その後Unicodeは、UCSのBMPを乗っ取る形で一本化に成功したことはすでに述べた(第2部第3回の注釈1参照)。それまでのUnicodeの主張通りならBMP以降の面は不要ということになる。しかし現実にはいくら統合漢字で字数を節約するなどしても、6万5536文字ではとても足りないことはすぐに明らかになった。そこで考案されたのが、第1面から第15面までを利用可能にするUTF-16と呼ばれる符号化方法だ。これは第0面のBMPの範囲の符号表現はそのまま、第1面以降はBMPにある特定の領域の符号を2つ(つまり合わせて32ビット)組み合わせた表現に置き換えることで符号化可能にするものだ。この組み合わせをサロゲートペアと呼ぶ。これによってUnicodeはBMPの範囲は16ビット、第1面以降は32ビットという不等長コードになり、プログラミングの面からは複雑な処理が必要となってしまった。
|
[*4]……Unicodeコンソーシアムは1991年にカルフォルニア州にUnicode Inc.として法人設立している。ここでは「Unicode社」と表記する。
|
[*5]……『Unicode Technical Standard #37 Ideographic Variation Database』(http://www.unicode.org/reports/tr37/)
|
[*6]……『Unicode Email Distribution Lists』(http://www.unicode.org/consortium/distlist.html)
|
[*7]……『Ideographic Variation Database』(http://www.unicode.org/ivd/#versions)
|
[*8]……Unicode 5.1規格本文「16.4 Variation Selectors」を参照(http://unicode.org/versions/Unicode5.0.0/ch16.pdf)。
|
[*9]……ただし、このMac OS X版InDesign CS3のようなUnicode正規化の実装例は、あり得ないことはないにしても現段階ではかなり珍しいものと言える。
|
[*10]……Adobe-Japan1で集められた文字の形そのものについては、『The Adobe-Japan1-6 Character Collection』(http://www.adobe.com/devnet/font/pdfs/5078.Adobe-Japan1-6.pdf)を参照。
|
[*11]……JIS X 0213はJIS X 0208を拡張する規格であり、これと重複する部分はJIS X 0208をそっくり引用する形で規定している。したがってJIS X 0213の面区点1-40-04の例示字体は、JIS X 0208の区点40-04のものとなる。
|
[*12]……ここで「混乱」とカッコで括ったのは、これを保留なしに混乱と書くことで、かえって混乱を助長してしまうののではないかという疑問があるからなのだが、それは第3部で考えることにしよう。
|
● 修正履歴
[訂正]……原稿の以下の部分で、「Unicode」のスペルを書き間違えていました。お詫びして訂正いたします。
誤:[*4]……Unicdeコンソーシアムは1991年にカルフォルニア州にUnicide
Inc.として法人設立している。ここでは「Unicide社」と表記する。
正:[*4]……Unicodeコンソーシアムは1991年にカルフォルニア州にUnicode
Inc.として法人設立している。ここでは「Unicode社」と表記する。
ご指摘いただいた芝野耕司氏に感謝いたします。(2008/9/12)
2008/09/09 12:24
|
小形克宏(おがた かつひろ) 文字とコンピュータのフリーライター。本紙連載「文字の海、ビットの舟」で文字の世界に漕ぎ出してから早くも8年あまり。知るほどに「海」の広さ深さに打ちのめされています。文字ブログ「もじのなまえ」ときどき更新中。 |
- ページの先頭へ-
|