睡人亭

文字コード入門

Unicode

Unicodeとは

多くの国でコンピュータが利用されるようになってきて、文字を扱うための仕組みである文字コードも、その国の数だけ増えていく状態であり、情報交換のために様々な不都合が生ずるようになってきました。また、企業の側でも各国個別の言語に合わせたソフトウェアを開発するためには膨大なコストが必要なため、これを解消する手段が求められるようになってきたのです。

そこでこの問題を解消すべく、IBM、Microsoft、Apple等が加盟(他のメンバーについてはこちらを参照)するNGOであるUnicodeコンソーシアムが中心となって、全ての文字を16ビット(65536文字)に収録してしまおうという、野心的な多重言語文字セット規格の制定を企図していました。またそれとは別に、国際標準化機構(ISO)が、世界中の主要な文字を一括して扱う多重言語文字セット規格を開発していました。国際規格が複数制定されるのは非効率的であるため、両者が歩み寄って(実際には、Unicodeの規格にISO側が合わせる形での規格の変更を行いました)、(Universal multi-octet coded Character Set)が1993年に制定されました。

これがISO/IEC 10646(≒Unicode2.1)です。この規格の日本語版はJIS X 0221(JIS X 0221-1:2001国際符号化文字集合(UCS)―第1部:体系及び基本多言語面)として制定されています。また、Unicodeコンソーシアムの「Unicodeとは何か」 も参照してみてください。

Unicodeの現在の最新規格は、Unicode5.2.0(2010年10月現在)になります。

Unicode4.0の段階で、正式に16ビットで全ての文字を収録するという初めの方針を捨て、あらゆる文字を収録するための文字コードとしての側面を前面に押し立ててきました。現在、(そこに文字が定義されているか否かを別にして)1,112,064字分のコードポイントが存在します。

その中で、漢字については全部で文字(CJK統合漢字+ExtensionA, B, C)が使用可能です。

Unicodeの文字表

上にも書いたように、元々Unicodeは一文字16ビット(=65,536字)に全ての文字を収めてしまおうと企図していました(Unicode1.*の時期)。

しかし、Unicodeへの追加収録文字を検討する過程で、この範囲に収録しきれないことが明確になったため、現在では21ビットに拡張されています。

Unicodeの文字表は、16ビット時代のUnicodeで規定された文字表と、後のバージョンで拡張された部分とに分けられます。

UCSの区分けに従うと、文字表は群(group)・面(plane)・区(row)・点(cell)の四段階の構造を持っています。面が1つの表の単位で、各面はそれぞれ256区×256点=65,536字分のコードポイントが設定されています(UCSでは、更にこの上に0面~255面を単位とする群が128個定義されていますが、Unicodeが使用しな群や面については、永遠に使用しないことになりました)。

このうち、もっとも基本となる0群0面は、基本多言語面(BMP:Basic Multilingual Plane)と定義されます。

また、BMP以外の追加収録文字は、別途表を作成し、第0群第1面~第16面までの範囲で文字が定義されています。

BMP
Unicodeの文字表としては、もっとも基本となるものです。
拡張領域
Unicode3.1以降に割り当てられた領域です。元のBMPとは別の表になります。現在、第1面が古代文字などが収録される追加多言語面(Supplementary Multilingual )、第2面はCJK統合漢字拡張B, Cが収録される追加漢字面(Supplementary Ideographic Plane)、第14面が制御コードを収録する追加特殊用途面。第15面および第16面は私用目的のための面と規定されています。その他、今後第3面に金文や甲骨文などの漢字系出土文字が収録される予定になっています。

Unicodeに収録されている文字を文字表の番号で明示する場合、番号の冒頭にU+を付与します。

Unicodeのエンコーディングスキーム

Unicodeでは、複数のエンコーディングスキームが定義されています。

この中でよく使われるのが、UTF-16, UTF-8, UTF-32です。

UTF-16
Unicode収録文字のうち、BMP領域に割り当てられているものを16ビット(2オクテット)で、その他の領域に収録されている文字を、16ビット2つ分の情報量(4オクテット)で表現する(サロゲートペアと呼びます)方法になります。Windows XPやVISTAの内部処理で使用されます。そのため、文字種によって1文字辺りのデータ量が異なる特徴を持っています。但し、UTF-16の符号化方式として、UTF-16, UTF-16BE(ビッグエンディアン:2オクテットの内、上位の1オクテットから符号化する方法), UTF-16LE(リトルエンディアン2オクテットの内、下位の1オクテットから符号化する方法)の三種類があります。
サロゲートペア(代用対)
BMPの未定義領域1,024文字分を2つペアで使って1文字を表す方法です。UTF-16で拡張領域の文字を使用可能にするために考え出されました。これによって、1,024×1,024=1,048,576字分の拡張が可能となり、UTF-16では、1,048,576+65,536(BMP分)-2,048(サロゲートペアで使用する部分)=1,112,064字が使用可能になりました。
UTF-8
ASCIIの文字をそのままUnicodeで使用可能にするために制定されました。そのため、ASCII相当部分は1バイトで、その他の部分は2~4バイトという可変長の符号化方式となっています(漢字はBMP部分は3バイト、拡張部分は4バイトになります)。LinuxやMac OS Xで標準文字符号化方式として採用され、また、インターネット上でもっともよく使われるUnicode系の符号化方式です。
UTF-32
一文字を32ビット固定で符号化する方式です。UTF-32もUTF-16と同様に、ビッグエンディアンとリトルエンディアンが存在します。アプリケーションソフトでは余り使われませんが、固定長という構造の単純さを生かした分野(データベースなど)で使われています。

これ以外にも、UCSが定義する符号化方式であるUCS-2(一文字2オクテット固定。BMPのみ符号化可能), UCS-4(一文字4オクテット。UCSの群部分まで含めた文字を収録可能)があります。この両者のうち、UCS-2はUnicodeの普及当初よく使われていましたが、Unicodeの拡張が進んだ今日では、BMP部分のみしか符号化できないUCS-2の出番はUTF-8にその座を譲っています。

以上、見てきたように、Unicodeと一口に言っても、その符号化の方法は複数あります。従って、昔ながらの[全角・半角]と言った呼称が厳密には当たらなくなってしまったりしています。

Unicodeのエンコーディングスキームについては、以下のWebページを参照してください。

IBMのdeveloperWorks : UnicodeのKen LundeによるUnicodeエンコード方式

Nomenclator's氏のUCSとUTFつかいこなそうユニコードの下位ページ)

Unicodeで使用可能な漢字

Unicodeでは、多くの漢字が使用可能です。

但し、Unicodeに収録される元の文字コード(原規格)との関係や、Unicode自体の拡張に伴う収録場所の追加によって、漢字は複数の場所(BMP, 拡張第2面)に収録されています。また、漢字以外にも漢字文献特有の文字符号も収録されています。

CJK統合漢字(URO)

Unicodeの文字表に各文字種毎に収録域が設けられていますが、最初に収録された漢字の領域は、CJK Unified Ideographs(CJK統合漢字:U+4E00-U+9FFF, Unicode1.0.1の段階で20,902字、Unicode6.1の段階で、20,941字分割り当てられている)になります。

元々はCJK統合漢字という名称でしたが、Unicodeの漢字エリアが増えたことにより、現在ではこの部分をUnified Repertoire and Ordering(URO)と呼ぶことになりました。

ベースとなった主な文字集合は、中国(C)のGB 2312、台湾(C)のCNS1,2,14面、日本(J)のJIS X 0208とJIS X 0212、韓国(K)のKS C 5601になります。これらベースとなった文字集合の文字を足すと、20,902(Unicode1.0.1時)にはとうてい収まりませんが、字形的に同一もしくは些細な字形差と認められる文字は、同じコードポイントに割り振ることで、20,902という数にまとめています。これを漢字統合(Han Unification)と呼びます。ベースとなった文字集合との変換は、変換表を利用して相互変換しています。ただし、変換テーブルが、各ソフトメーカーによって異なるという問題があり(久保田智広氏の変換表がベンダーによって異なるを参照)、注意が必要です。漢字統合のためにより多くの漢字を収録することに成功しましたが、そのために下に述べるようにさまざなま批判を呼ぶことにもなりました。

Unicodeベースのオペレーティングシステムで日本語や中国語を扱う場合、実はCJK Unified Ideographsの中から、それぞれの言語に応じた文字コードのみをピックアップして利用しています。

CJK統合漢字と各国ローカル文字コードの対応(一部)
U+4E00 0 1 2 3 4 5 6 7 8 9 A B C D E F
Unicode
JIS
BIG5
GB
Unicode
JIS
BIG5
GB
Unicode
JIS
BIG5
GB

Unicode5.1で、この領域に22字が追加(U+9FA5~U+9FBB)されています。

Unicode5.1で、この領域に8字が追加(U+9FBC~U+9FC3)されています。

Unicode5.2で、この領域に8字が追加(U+9FC4~U+9FCB)されています。

Unicode6.1で、この領域に1字が追加(U+9FCC)されています。

CJK互換漢字

CJK統合漢字制定時に漢字統合によって字形の類似する文字は一つにまとめられました。しかし、収録される側の規格において別々に登録されていた文字については、Unicodeと元の規格との間の相互変換(ラウンドトリップ変換)を可能にするために(原規格分離規則)別々に収録されています(Big5で重複となった2文字もここに含まれています。U+FA0C, U+FA0D)。これらの文字は原則としてCJK統合漢字部分に収録されることになったのですが、その中に、互換性を保つためだけの目的で特に分類された漢字が、CJK互換漢字の領域に設定(U+F900~U+FAFF)されることになりました。

また、Unicode3.1で、2F800~2FA1FにCJK Compatibility Ideographs Supplement(CJK互換漢字補助)の領域が設けられています。

CJK Unified Ideographs Extension A(CJK統合漢字拡張A集合)

1999年のUnicode3.0制定時に追加されました。BMPのU+3400~U+4DB5までに6,582字が収録されています(UnicodeコンソーシアムのPDFファイル(1.5MB))。

Unicode1.1の時代にはここにはハングルが収録されていたのですが、Unicode2.0以降ハングルの場所が引っ越しましたのでUnicode3.0の際にこの領域を使って、CJK統合漢字拡張A集合が設定されました。

BMPに収録されているため、フォントさえ対応すればUCS-2しか扱えないアプリケーションでも利用可能です。

一文字辺りUCS-2, UTF-16では2オクテット、UTF-8では3オクテットのデータ量になります。

拡張A集合収録文字の一部
数値は4桁。縦が上3桁、横が下1桁目に相当。
U+0123456789ABCDEF
340
341
342
343
344
345
346
347
348
349
34A
34B
34C
34D
34E
34F

CJK Unified Ideographs Extension B(CJK統合漢字拡張B集合)

2001年のUnicode3.1で追加されました。U+20000~U+2A6D6までに42,711字が収録されています(UnicodeコンソーシアムのPDFファイル(5MB))。

これらの文字はBMPではなく、全て第二面(補助漢字面)に収録されているためUCS-2では利用できません。そのため、UTF-8やUTF-16を利用する必要があります(UTF-8では4オクテット分の、UTF-16でもサロゲートペアを使用しますので、同じく4オクテット分のデータ量が必要となります)。

Windows2000やXPで利用可能ですが、対応するアプリケーションはUTF-16のサロゲートペアに対応している必要があります(例えば、Microsoft Office(XP以降)、一太郎2005、Adobe Indisignが対応しています)。

JIS X 0213:2004収録の文字の中に、一部拡張B領域に収録されるものがあります。そのため、日本のJIS漢字コード収録文字をUnicode上で全て使用したい場合には、UTF-16のサロゲートペアもしくはUTF-8やUTF-32などに対応したものが必要となります。

拡張B集合収録文字の一部
数値は5桁。縦が上4桁、横が下1桁目に相当。
U+0123456789ABCDEF
2000𠀀𠀁𠀂𠀃𠀄𠀅𠀆𠀇𠀈𠀉𠀊𠀋𠀌𠀍𠀎𠀏
2001𠀐𠀑𠀒𠀓𠀔𠀕𠀖𠀗𠀘𠀙𠀚𠀛𠀜𠀝𠀞𠀟
2002𠀠𠀡𠀢𠀣𠀤𠀥𠀦𠀧𠀨𠀩𠀪𠀫𠀬𠀭𠀮𠀯
2003𠀰𠀱𠀲𠀳𠀴𠀵𠀶𠀷𠀸𠀹𠀺𠀻𠀼𠀽𠀾𠀿
2004𠁀𠁁𠁂𠁃𠁄𠁅𠁆𠁇𠁈𠁉𠁊𠁋𠁌𠁍𠁎𠁏
2005𠁐𠁑𠁒𠁓𠁔𠁕𠁖𠁗𠁘𠁙𠁚𠁛𠁜𠁝𠁞𠁟
2006𠁠𠁡𠁢𠁣𠁤𠁥𠁦𠁧𠁨𠁩𠁪𠁫𠁬𠁭𠁮𠁯
2007𠁰𠁱𠁲𠁳𠁴𠁵𠁶𠁷𠁸𠁹𠁺𠁻𠁼𠁽𠁾𠁿
2008𠂀𠂁𠂂𠂃𠂄𠂅𠂆𠂇𠂈𠂉𠂊𠂋𠂌𠂍𠂎𠂏
2009𠂐𠂑𠂒𠂓𠂔𠂕𠂖𠂗𠂘𠂙𠂚𠂛𠂜𠂝𠂞𠂟
200A𠂠𠂡𠂢𠂣𠂤𠂥𠂦𠂧𠂨𠂩𠂪𠂫𠂬𠂭𠂮𠂯
200B𠂰𠂱𠂲𠂳𠂴𠂵𠂶𠂷𠂸𠂹𠂺𠂻𠂼𠂽𠂾𠂿
200C𠃀𠃁𠃂𠃃𠃄𠃅𠃆𠃇𠃈𠃉𠃊𠃋𠃌𠃍𠃎𠃏
200D𠃐𠃑𠃒𠃓𠃔𠃕𠃖𠃗𠃘𠃙𠃚𠃛𠃜𠃝𠃞𠃟
200E𠃠𠃡𠃢𠃣𠃤𠃥𠃦𠃧𠃨𠃩𠃪𠃫𠃬𠃭𠃮𠃯
200F𠃰𠃱𠃲𠃳𠃴𠃵𠃶𠃷𠃸𠃹𠃺𠃻𠃼𠃽𠃾𠃿

IBMのdeveloperWorks : UnicodeのTony Grahamによる「Unicode3.1:その現状」第一回 第二回も参照 してください。

CJK Unified Ideographs Extension C(CJK統合漢字拡張C集合)

2009年10月制定のUnicode5.2.0で追加された文字です(ISO/IEC 10646:2003/Amd.5:2008)。第二面の(U+2A700~U+2B734)に4,149字が収録されています。

拡張C集合収録文字の一部
数値はu+5桁。縦が上位4桁、横が下位1桁目に相当。
0123456789ABCEEF
2A70𪜀𪜁𪜂𪜃𪜄𪜅𪜆𪜇𪜈𪜉𪜊𪜋𪜌𪜍𪜎𪜏
2A71𪜐𪜑𪜒𪜓𪜔𪜕𪜖𪜗𪜘𪜙𪜚𪜛𪜜𪜝𪜞𪜟
2A72𪜠𪜡𪜢𪜣𪜤𪜥𪜦𪜧𪜨𪜩𪜪𪜫𪜬𪜭𪜮𪜯
2A73𪜰𪜱𪜲𪜳𪜴𪜵𪜶𪜷𪜸𪜹𪜺𪜻𪜼𪜽𪜾𪜿
2A74𪝀𪝁𪝂𪝃𪝄𪝅𪝆𪝇𪝈𪝉𪝊𪝋𪝌𪝍𪝎𪝏
2A75𪝐𪝑𪝒𪝓𪝔𪝕𪝖𪝗𪝘𪝙𪝚𪝛𪝜𪝝𪝞𪝟
2A76𪝠𪝡𪝢𪝣𪝤𪝥𪝦𪝧𪝨𪝩𪝪𪝫𪝬𪝭𪝮𪝯
2A77𪝰𪝱𪝲𪝳𪝴𪝵𪝶𪝷𪝸𪝹𪝺𪝻𪝼𪝽𪝾𪝿
2A78𪞀𪞁𪞂𪞃𪞄𪞅𪞆𪞇𪞈𪞉𪞊𪞋𪞌𪞍𪞎𪞏
2A79𪞐𪞑𪞒𪞓𪞔𪞕𪞖𪞗𪞘𪞙𪞚𪞛𪞜𪞝𪞞𪞟
2A7A𪞠𪞡𪞢𪞣𪞤𪞥𪞦𪞧𪞨𪞩𪞪𪞫𪞬𪞭𪞮𪞯
2A7B𪞰𪞱𪞲𪞳𪞴𪞵𪞶𪞷𪞸𪞹𪞺𪞻𪞼𪞽𪞾𪞿
2A7C𪟀𪟁𪟂𪟃𪟄𪟅𪟆𪟇𪟈𪟉𪟊𪟋𪟌𪟍𪟎𪟏
2A7D𪟐𪟑𪟒𪟓𪟔𪟕𪟖𪟗𪟘𪟙𪟚𪟛𪟜𪟝𪟞𪟟
2A7E𪟠𪟡𪟢𪟣𪟤𪟥𪟦𪟧𪟨𪟩𪟪𪟫𪟬𪟭𪟮𪟯

CJK Unified Ideographs Extension D(CJK統合漢字拡張D集合)

2010年10月制定のUnicode6.0で追加された文字です(ISO/IEC 10646:2003/Amd.8:2009)。第二面の(U+2B740~U+2B81D)に222字が収録されています。

拡張D集合収録文字
数値はu+5桁。縦が上位4桁、横が下位1桁目に相当。
0123456789ABCEEF
2B74𫝀𫝁𫝂𫝃𫝄𫝅𫝆𫝇𫝈𫝉𫝊𫝋𫝌𫝍𫝎𫝏
2B75𫝐𫝑𫝒𫝓𫝔𫝕𫝖𫝗𫝘𫝙𫝚𫝛𫝜𫝝𫝞𫝟
2B76𫝠𫝡𫝢𫝣𫝤𫝥𫝦𫝧𫝨𫝩𫝪𫝫𫝬𫝭𫝮𫝯
2B77𫝰𫝱𫝲𫝳𫝴𫝵𫝶𫝷𫝸𫝹𫝺𫝻𫝼𫝽𫝾𫝿
2B78𫞀𫞁𫞂𫞃𫞄𫞅𫞆𫞇𫞈𫞉𫞊𫞋𫞌𫞍𫞎𫞏
2B79𫞐𫞑𫞒𫞓𫞔𫞕𫞖𫞗𫞘𫞙𫞚𫞛𫞜𫞝𫞞𫞟
2B7A𫞠𫞡𫞢𫞣𫞤𫞥𫞦𫞧𫞨𫞩𫞪𫞫𫞬𫞭𫞮𫞯
2B7B𫞰𫞱𫞲𫞳𫞴𫞵𫞶𫞷𫞸𫞹𫞺𫞻𫞼𫞽𫞾𫞿
2B7C𫟀𫟁𫟂𫟃𫟄𫟅𫟆𫟇𫟈𫟉𫟊𫟋𫟌𫟍𫟎𫟏
2B7D𫟐𫟑𫟒𫟓𫟔𫟕𫟖𫟗𫟘𫟙𫟚𫟛𫟜𫟝𫟞𫟟
2B7E𫟠𫟡𫟢𫟣𫟤𫟥𫟦𫟧𫟨𫟩𫟪𫟫𫟬𫟭𫟮𫟯
2B7F𫟰𫟱𫟲𫟳𫟴𫟵𫟶𫟷𫟸𫟹𫟺𫟻𫟼𫟽𫟾𫟿
2B80𫠀𫠁𫠂𫠃𫠄𫠅𫠆𫠇𫠈𫠉𫠊𫠋𫠌𫠍𫠎𫠏
2B81𫠐𫠑𫠒𫠓𫠔𫠕𫠖𫠗𫠘𫠙𫠚𫠛𫠜𫠝

CJK漢字に対応するフォント

CJK漢字に対応するフォントの例です。

表のデータは、『漢字文献情報処理研究』第九号の上地宏一氏作成のものをベースにしています。上地氏の論攷には、各フォントの特徴や問題点なども書かれていますので、是非参考にして下さい。

また、上地氏が中心となって進めているGlyphWiki(Wikiの方法を用いて、多くの人でフォントを作成する)があります。関連するプロジェクトととして、完全フリーな漢字フォント作成を目標とする花園フォントがあります(花園明朝は、拡張C,D集合収録文字を実装している数少ないフォントです)。

CJK漢字と言っても、CJK統合漢字、拡張A、拡張Bなど、各領域の実装状況はフォントによって異なります。

これに加えて、True Type Fontの仕様によって、1フォントファイルには65,536字しか収納できません。そのため、CJK統合漢字+拡張A(BMP実装部分)と拡張B(補助漢字面)の収録漢字全てを、1フォントファイルに実装する事はできません。

Windowsでは、この問題に対し、FontLink(一つのフォントに対し、そのフォントが実装していない文字をどのフォントで代替表示するかを指定する機能。FontLinkの情報は、レジストリファイルに保持されます)を使用しています。

Windows XPの標準フォント
フォント名書体収録漢字数
拡張A統合漢字互換漢字拡張B互換拡張
MS 明朝明朝12,20434
MS ゴシックゴシック12,20434
SimSun明朝5220,90221
SimHeiゴシック20,90221
MingLiU明朝20,902302
Batang明朝7,476268
Dotumゴシック7,476268
Windows Vistaの標準フォント
フォント名書体収録漢字数
拡張A統合漢字互換漢字拡張B互換拡張
MS 明朝明朝16412,57998304
MS ゴシックゴシック16412,57998304
メイリオゴシック20210,75535933945
SimSun明朝6,58220,91021
SimSun-ExtB明朝42,711
SimHeiゴシック6,58220,90221
YaHeiゴシック6,58220,909218
MingLiU明朝6,58220,916302
MingLiU-ExtB明朝42,71111
JhengHeiゴシック6,58220,902302
Batang明朝7,476268
Dotumゴシック7,476268
MalgunGothicゴシック
Windows用 Office、Proofing Toolsに付属するフォント
フォント名書体収録漢字数
拡張A統合漢字互換漢字拡張B互換拡張
Simsun(Founder Extended)明朝6,58220,9022136,862
Arial Unicode MSゴシック20,902302
Mac OS Xの標準フォント
フォント名書体収録漢字数
拡張A統合漢字互換漢字拡張B互換拡張
ヒラギノ明朝 Pro W3明朝20210,75511033945
ヒラギノ明朝 Pro NW3明朝20210,75511033945
ヒラギノ 角ゴ Pro W3ゴシック20210,75511033945
ヒラギノ 角ゴ ProN W3ゴシック20210,75511033945
Osakaゴシック6,356
STSong明朝6,58220,910216
STXiheiゴシック6,58220,910214,241
STHeitiゴシック6,58220,910216
Heiゴシック6,763
Apple LiSung明朝13,0602
LiSong Pro明朝51117,60741,64011
Apple LiGothicゴシック13,0602
LiHei Proゴシック51117,60741,64011
AppleGothicゴシック4,620268
Arial Unicode MSゴシック20,902302
Webで配布されているフォント
フォント名書体収録漢字数
拡張A統合漢字互換漢字拡張B互換拡張
HAN NOM A明朝6,58220,902362
HAN NOM B明朝42,711542

HAN NOMフォントのダウンロード先(hannomH.zipが高解像度)。

Unicodeのメリット・デメリット

どの様な文字コードであっても、メリット・デメリットが存在します。Unicodeについてもそれは同じです。幾つか挙げてみましょう。

メリット

Unicodeは、多重言語文字セットを目指して策定されていますので、初めから複数の言語を同時に使用可能な規格となっています。そのため、Unicodeに対応するアプリケーションとフォントさえあれば、世界中の多くの文字を利用することができます。

Unicodeに対応したアプリケーションソフト
Microsoft Office
一太郎
Adobe社の製品
Webブラウザ(Internet Explorer, Mozilla FireFox等)
Google社の製品・Webサービス

ただし、「Unicode対応!」を唱っていても、その実JIS X 0208相当部分しか利用出来ないアプリケーションソフトも多いことに注意してください。

MS Officeに収録されているArial unicode MSはUnicodeのBMP面の多くの文字に対応したフォントです。とりあえず字形だけ表示できればよい方には最適のフォントです。

デメリット:「漢字統合(Han Unification)」問題

Unicodeは、漢字統合によって多くの文字を収録していますが、日本で一般的に使われている明朝体の字体と、中国大陸・臺灣の字形が異なるにも関わらず、同じコードに「統合」されている場合もよくみられます。

このことによって、本来区別したい字が区別できないという問題が発生しました。これが漢字統合問題です。

「骨(U+9AA8)」での実例
  GB BIG5 JIS
文字
文字表番号 0-2539 1-5676 0-2592

これらは一見問題にも見えますが、実際には明朝体という文字デザインの字体差の範疇に含まれる部分と言えるでしょう。明朝体と楷書体の字形の違いならさほど問題にもならなかったのでしょうが、これが同じ明朝体故に問題が大きくなったのでしょう。検索などには、ある特定の文字を捜すのに、複数の文字を検索するよりも同じコードに包括されている方がむしろ便利です(euc.jpの従来の文字コードとUnicodeの対応に関する諸問題や久保田智広氏の漢字統合の問題などを参照してください)。

デメリット:コードセパレート問題

上に、漢字統合はそれほど問題でもないという趣旨の記事を書きました。むしろ現状のUnicodeで問題なのは「ベースの文字集合で区別され、一見同じ様な字形に見えながら、違うコードに登録されているもの」の存在です。これらの文字はベースの文字集合で区別されている文字のために、互換性維持のためにUnicodeでも区別されています。これはソースセパレーションの原則に則った行為であり、また各国の文字コードとの互換性維持のためには当然行われるべき措置である以上非難されるべきものではありませんが、不便なことには違いありません。

これをコードセパレート問題と呼びます。

漢字統合で同じ文字や些細な違いしかない異体字が一つのコードポイントで扱われるのが原則なのにも関わらず、別のコードに収録される文字が存在するため、情報交換で不具合が発生する、これがコードセパレート問題です。

これは、上にも書いたとおり、ベースの文字集合で区別されている文字のために、互換性維持のためにUnicodeでも区別されている(原規格分離の原則)ために生ずる問題です。

身近なところではJIS漢字コードの新旧字体が当てはまりますし、台湾のCNS第14字面収録文字にも、これに引っかかる文字が多く収録されています。

JIS漢字コードの新旧字体
区点 新字体 区点 旧字体
1657 6410
4630 4932
3124 5873
CJK統合漢字中のコードセパレート文字の一例
GB BIG5 JIS Unicode
1-3689 5167
0-3658 14-0140 0-3866 5185
1-7509 8AAA
1-4321 14-4170 0-3266 8AAC
0-7444 885E
1-4632 1-7876 0-1750 885B

コードセパレート文字による文字化けにより、データ交換が妨げられる場合があります。特に、繁体字を使用している台湾系のデータベースの閲覧や検索で、コードセパレート文字を理解していないことによる検索漏れという事態が発生します。

解決の方法

コードセパレートされた文字を、同一群の文字としてコンピュータに宣言することが必要になります。これを異体字シソーラスの設定とよびます。

ただし問題となるのは、このシソーラスをコンピュータ側で持つか、データベース側で持つのか? という点です。データベース側で持つのが現状の主流ですが、そのために基準が異なる異体字シソーラスが複数存在することにもつながります。従って、自分が利用する所の異体字の癖を認識する必要があります。例えば、JISならば新字体or旧字体のどちらを使っているか、台湾系ならば、外字処理するのか、BIG5内に包摂してしまうのか…といった類のことです。

IBMのdeveloperWorks : UnicodeのSuzanne ToppingによるUnicodeの知らざる世界も参照してください。