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の中から、それぞれの言語に応じた文字コードのみをピックアップして利用しています。

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オクテットのデータ量になります。

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などに対応したものが必要となります。

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字が収録されています。

CJK Unified Ideographs Extension D（CJK統合漢字拡張D集合）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

解決の方法

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

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

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