情報システムのトピックス-PR-

UnicodeのIVSがもたらすメリットとデメリット

2011/01/27

 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-16UTF-8
908A DB40 DD00E9 82 8A F3 A0 84 80
908A DB40 DD01E9 82 8A F3 A0 84 81
908A DB40 DD02E9 82 8A F3 A0 84 82
908A DB40 DD03E9 82 8A F3 A0 84 83
908A DB40 DD04E9 82 8A F3 A0 84 84
908A DB40 DD05E9 82 8A F3 A0 84 85
908A DB40 DD06E9 82 8A F3 A0 84 86
908A DB40 DD07E9 82 8A F3 A0 84 87
908A DB40 DD08E9 82 8A F3 A0 84 88
908A DB40 DD09E9 82 8A F3 A0 84 89
908A DB40 DD0AE9 82 8A F3 A0 84 8A
908A DB40 DD0BE9 82 8A F3 A0 84 8B
908A DB40 DD0CE9 82 8A F3 A0 84 8C
908A DB40 DD0DE9 82 8A F3 A0 84 8D
908A DB40 DD0EE9 82 8A F3 A0 84 8E
908A DB40 DD0FE9 82 8A F3 A0 84 8F
908A DB40 DD10E9 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技術によって、現在よりさらに複雑になりそうだ。

今週のトピックス-PR-

この記事に対するfacebookコメント

nikkeibpITpro

▲ ページトップ

CIO Computerworld

Twitterもチェック