Unicodeとは

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

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

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

※UCSでのエンコーディングの方法としては、一文字=16ビット固定（厳密には異なる）のUCS-2（65536文字収録可能）と、32ビット固定のUCS-4（約21.5億字収録可能）があります。

UCS-2では、上位1オクテッドの値を「区オクテッド」、下位1オクテッドの値を「点オクテッド」とする256×256=65536の升目で構成された文字表に文字が収録されます。

UCS-4では、この256×256の表を1つの面（plane）とみなし、256面を1群（group　群は合計128）と定義しています。従って第1オクテッドから順に「群オクテッド」「面オクテッド」「区オクテッド」「点オクテッド」と定義されます。

この中で、0群0面をBasic Multilingual Plane=BMPと呼びます（UCS-2相当部分）。現在のUnicode標準では、BMP以外にも複数の表を利用することができますが、Unicode2.1ではBMP領域のみが使用可能です。

他の文字集合の番号と区別するために、16進数の頭にU+をつけることもあります。

エンコーディングスキームとしては、BMP収録文字の文字表番号をそのまま16ビットコードとしたUCS2やASCIIとの互換性を保つために1～6バイトの変則コードを採用するUTF-8、4バイトコードのUCS4、2バイト（UCS2）とと4バイト（UCS4）とを混用するUTF-16、4バイトコードのUTF-32などがあります。

よく使われるのがUCS2, UTF-8, UTF-16辺りでしょうか。

従って、Unicode化において「全角・半角」と言った呼称は、エンコーディングシステムによっては相応しい呼び方ではなくなってしまいます。

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

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

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

現在、Windows NT,2000, XP, VISTAやMacOS X等は、内部コードとしてUnicodeを採用し、JAVAやXMLは、Unicodeをデフォルトのデータ型として定義しているように、現在文字コードの主流はUnicodeになりつつあります。

Unicodeは、対応するアプリケーションとフォントさえあれば、世界中の多くの文字を利用することができます。

例えば、Unicodeに対応しているWindowsならば、MS Officeや一太郎、秀丸やEmEditorなど、多くのアプリケーションがUnicodeに対応していますので、Unicodeを利用すれば多言語混在文書やJIS X 0208に収録されていない多くの漢字を使用することが可能です。また、最新のWWWブラウザはUnicodeを表示できます。

実は、このページも、Unicodeのエンコーディングシステムの一つであるUTF-8で作成されています。

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

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

↑ページ先頭

Unicode2.1の文字集合

上述のように、Unicode2.1では、Basic Multilingual Plane=BMP領域のみが使用可能です。

Unicode2.1で扱える漢字

Unicodeの文字表に各文字種毎に収録域が設けられていますが、漢字が収録される領域は、CJK Unified Ideographs(CJK統合漢字　U+4E00-U+9FFF　20,902字）になります。

ベースとなった主な文字集合は、中国（C）のGB 2312、台湾（C）のCNS1,2,14面、日本（J）のJIS X 0208とJIS X 0212、韓国（K）のKS C 5601になります。これらベースとなった文字集合の文字を足すと、20,902にはとうてい収まりませんが、字形的に同一もしくは些細な字形差と認められる文字は、同じコードポイントに割り振ることで、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			丢		两	严		丧	丨		个	丫	丬	中

↑ページ先頭

「漢字統合（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の知らざる世界も参照してください。

↑ページ先頭

Unicodeの拡張

Unicodeの現在の最新規格は、Unicode5.1になります。

Unicode4.0の段階で、正式に16ビットで全ての文字を収録するという初めの方針を捨て、あらゆる文字を収録するための文字コードとしての側面を前面に押し立ててきました。

4.0では、全体として96,248が使用可能です（それに加えて制御文字等2,313＋私用領域137,468文字分の領域が用意されています）。漢字については、全部で70,195文字（ＣＪＫ統合漢字+Extension.A,B）が使用可能です。

Unicodeに収録される漢字は、2.1の段階では各国の文字コードの上位互換の形をとっていましたが、それ以降は独自に収録文字数の拡大を続けています。CJK統合漢字領域以降の増加分は、Unicode3.0の時にはExtension.Aに、Unicode3.1にはExtension.Bにそれぞれ収録されました。

その他Unicode4.0では、易の64卦（4DC0-4DFF）と前漢楊雄著『太玄経』の81首（1D300-1D356）が新たに収録されています。これまで易の卦は8卦しか収録されていませんでしたから、大変喜ばしい限りです。

バージョンの4.1.0では、各ローカルな規格との互換性を計るために、文字の追加などが行われています。そのため、CJK統合漢字領域がU+4E00～U+9FA5からU+4E00～U+9FBBに拡大しました。

また、将来的にはExtension Cの制定や甲骨・金文などの出土文字資料のコード化も計画しているそうです。

Extension.A（CJK統合漢字拡張領域A）

BMPのU+3400-U+4DB5までに6,582字が収録されています（UnicodeコンソーシアムのPDFファイル（1.5MB））。

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

UCS2では2バイトコード、UTF-8では3バイトコードになります。

Extension.B（CJK統合漢字拡張領域B）

U+20000-U+2A6D6までに42,711字が収録されています（UnicodeコンソーシアムのPDFファイル（5MB））。

これらの文字は第二面に収録されているためUCS2では利用できません。

UTF-8やUTF-16を利用する必要があります（UTF-8では4バイトコードとして、UTF-16では、サロゲートペアと呼ばれる方法（二文字分のデータ量で一文字を表す）で4バイトで処理されます）。

Windows2000やXPで利用可能ですが、対応するアプリケーションはMicrosoft Office（XP以降）、一太郎2005、Adobe Indisignなどがあります。

UnicodeベースのアプリケーションでJIS漢字コードの第一～第四水準全てを扱うには、ExtBまで対応している必要があります（MacOS X用のMicrosoft Office2004に収録されているMS明朝・MSゴシックや一太郎2005購入者特典フォントは第四水準までの文字を使用可能です）。

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

↑ページ先頭