UnicodeのIVS(Ideographic Variation Sequence)は、漢字を表すUnicodeの直後に Variation Selectorと呼ばれるコードを付加し、漢字の「異体字」を表現する方法だ。IVSによって、従来よりも多くの字体が利用可能になる反面、データの「名寄せ」が困難になる恐れもある。文字コードに詳しい京都大学人文科学研究所附属東アジア人文情報学研究センターの安岡孝一准教授が、IVSの利点と懸念すべきポイントを解説する。(日経コンピュータ)
筆者がITproに「漢字1文字が最大8バイト、Unicodeの「IVS」とは?」を寄稿してから約1年が経って、IVSに新たな動きがあった。常用漢字表の改正(2010年11月30日)に前後して、4195字のIVSが追加されると同時に、IVS技術促進協議会が発足したのだ。IVSの拡大によって、これまでフォント切り換えでしか対応できなかった異体字処理が、文字コードのレベルで処理できるようになった。
IVSとは、漢字を表すUnicodeの直後に、Variation Selectorと呼ばれるコードを付加し、漢字の異体字を表現する方法である。例えば「邊」であれば、U+908Aの直後にU+E0100~U+E0110のVariation Selectorを付加することで、以下の17種類の異体字を表現できる。
908A E0100
Adobe-Japan1
CID+6929
908A E0101
Adobe-Japan1
CID+14235
908A E0102
Adobe-Japan1
CID+14236
908A E0103
Adobe-Japan1
CID+14237
908A E0104
Adobe-Japan1
CID+14238
908A E0105
Adobe-Japan1
CID+14239
908A E0106
Adobe-Japan1
CID+14240
908A E0107
Adobe-Japan1
CID+20234
908A E0108
Hanyo-Denshi
JA7820
908A E0109
Hanyo-Denshi
JTBD45
908A E010A
Hanyo-Denshi
JTBD62
908A E010B
Hanyo-Denshi
JTBD61
908A E010C
Hanyo-Denshi
JTBD60
908A E010D
Hanyo-Denshi
JTBD5F
908A E010E
Hanyo-Denshi
JTBD5E
908A E010F
Hanyo-Denshi
KS445320S
908A E0110
Hanyo-Denshi
JTBD6A
IVSを用いれば、これら17種類の「邊」を、UTF-16あるいはUTF-8といった文字コードレベルで使い分けることができるのだ。
UTF-16 | UTF-8 | |
---|---|---|
908A DB40 DD00 | E9 82 8A F3 A0 84 80 | |
908A DB40 DD01 | E9 82 8A F3 A0 84 81 | |
908A DB40 DD02 | E9 82 8A F3 A0 84 82 | |
908A DB40 DD03 | E9 82 8A F3 A0 84 83 | |
908A DB40 DD04 | E9 82 8A F3 A0 84 84 | |
908A DB40 DD05 | E9 82 8A F3 A0 84 85 | |
908A DB40 DD06 | E9 82 8A F3 A0 84 86 | |
908A DB40 DD07 | E9 82 8A F3 A0 84 87 | |
908A DB40 DD08 | E9 82 8A F3 A0 84 88 | |
908A DB40 DD09 | E9 82 8A F3 A0 84 89 | |
908A DB40 DD0A | E9 82 8A F3 A0 84 8A | |
908A DB40 DD0B | E9 82 8A F3 A0 84 8B | |
908A DB40 DD0C | E9 82 8A F3 A0 84 8C | |
908A DB40 DD0D | E9 82 8A F3 A0 84 8D | |
908A DB40 DD0E | E9 82 8A F3 A0 84 8E | |
908A DB40 DD0F | E9 82 8A F3 A0 84 8F | |
908A DB40 DD10 | E9 82 8A F3 A0 84 90 |
Windows 7もMac OS XのSnow Leopardも、すでにOSレベルでIVSに対応している。IVSに対応したアプリケーションは、現時点ではFirefox 4やWindows 7のメモ帳などに限られているものの、今後ますます増えていくだろう。また、新しいIVSに対応したフォントは、IPA(情報処理推進機構)やGlyphWikiにおいて現在鋭意開発中であり、本年4月頃にはほぼ出揃うものと予想される。異体字の表示・出力に関しては、新しいIVSによって薔薇色の未来がひろがっていると言えるだろう。
しかもIVSは、住民基本台帳統一文字(住民基本台帳ネットワークにおいて用いられている文字で、漢字は19432字収録)と戸籍統一文字(戸籍の電算化において用いられる文字で、漢字は55270字収録)を全て網羅するまで、今後も拡充され続ける予定であり、ますます多くの異体字が使えるようになっていくのは間違いない。
だが、そのような利点とは裏腹に、IVS技術が一般にも浸透していくと、例えば、データの「名寄せ」においてどの文字を「同じ」とみなすか、という処理をコーディングする際に、頭痛のタネが増えそうだ。例えば「渡邊」さんをIVSで処理した場合、全ての「邊」を同一視して「名寄せ」してしまったのでは、わざわざIVSを使った意味がない。かと言って、17種類すべてが異なる「邊」をそれぞれ区別するのも、現実的ではない。一般の利用者は「U+908A U+E0107」と「U+908A U+E010B」の違い(10画目をハネるかハネないか)などほとんど意識しておらず、同じ「渡邊」さんに対して、「U+908A U+E0107」を使ったデータと、「U+908A U+E010B」を使ったデータの両方が存在してしまう恐れがある。そのようなデータを「名寄せ」する場合には、どの文字を「同じ」をみなすか、かなり複雑な判断を必要とすることになる。「あいまい」検索などにおいても、どこまでの「あいまい」さを許すのかという点が、IVS技術によって、現在よりさらに複雑になりそうだ。