今回は、ユニコードについてお話ししたいと思います。ユニコードについては、インターネットや書籍などで様々な情報が提供されていますので、 このコラムでは、SAP ユニコードシステムを理解するために必要な部分に絞ってお話ししたいと思います。

ユニコードとは

ユニコードは、アップル、ヒューレットパッカード、IBM、マイクロソフトなど、多くのコンピューター関連企業が中心となって設立された団体、ユニコードコンソーシアムによってつくられた文字コード体系です。下の言葉は、ユニコードコンソーシアムのサイトから引用したものです。

ユニコードは、すべての文字に固有の番号を付与します
プラットフォームには依存しません
プログラムにも依存しません
言語にも依存しません

ユニコードは、コンピューターが扱いやすいように、世界中で使用される文字を 1 つの体系にまとめるためにつくられた文字コード体系と言い換えられるかもしれません。

ユニコードは、UCS-4とUCS-2という2つの文字集合の規格があります。それぞれの文字集合の違いと、2つの文字集合が存在している理由について簡単に説明してみたいと思います。

UCS-4とUCS-2

UCS-4は、Universal multi-octet Character Set 4の略で、ISO/IEC 10646-1で定められた国際文字集合規格です。128の群 (group)、256 の面 (plane)、256 の区 (row)、256 の点 (cell) の組み合わせで文字を表し、計算上は、20 億個の文字を文字コード体系に収めることができます。

UCS-2は、Universal multi-octet Character Set 2 の略で、UCS-4 の0群0面にある65,534個の文字に限定した文字集合です。UCS-2は、いわばUCS-4の部分集合で、このなかには、世界で一般的に使用される文字、記号のほとんどが収録されています。このことから、UCS-2をBMP (Basic Miltilingual Plane 基本多言語面) と呼ぶこともあります。

当初、ユニコードコンソーシアムは、漢字の異字体などを整理して、UCS-2の文字集合のなかに世界中の文字をまとめて収容する構想を持っていました。しかし、最終的にはUCS-2が格納できる文字数にまとめることができず、一般的にあまり使われていない文字をUCS-4の0群1、2、14、15、16面に収めることになりました。

日本語の場合、半角カナ、かな、JIS 第一水準、第二水準漢字、NEC 拡張文字、IBM 拡張漢字などは、UCS-4の0群0面、つまりUCS-2に収録されていますが、JIS X 0213 規格で制定されたJISの第三、第四水準の漢字の一部は、0面に収めることができずに第2面に収録されています。

このような背景から、厳密に言えば、UCS-2の文字集合では、ユニコードが定義するすべての文字を扱うことができないのですが、世界中で一般的に使われている文字がほぼ収録されているので、現在でもユニコードの文字集合として広く使用されています。

ユニコードのエンコード方式

コンピューターが文字をバイトの列に変換することをエンコード（符号化）といいます。

例えば、Windows2000やXPのメモ帳でファイル名を指定して保存するとき、ポップアップウィンドウの一番下に「文字コード」という項目があるのをご存知でしょうか。この項目でテキストの内容をどのエンコード方式でファイルに書き出すのかを指定することができます。

メモ帳の場合、通常使用さ れる ANSI 以外に、Unicode、Unicode big endian、UTF-8 という3つの選択肢があります。実は、これら 3つの選択肢は、いずれもユニコードのエンコード方式を表しています。つまり、文字をユニコードのバイト列として保存するためのエンコード方式が複数あるということになります。そして、エンコード方式が異なれば、同じユニコードといってもバイト列の中身が変わってきます。

エンコード方式によるバイト列の違いを具体的に説明したいと思います。メモ帳の場合、文字コードの選択肢 Unicode は、UTF-16 Little Endian（以下、UTF-16 LE）、Unicode big Endianは、UTF-16 Big Endian（以下、UTF-16 BE）、UTF-8 は、そのまま UTF-8 というエンコード方式を表しています。

メモ帳で「あ」という文字を入力してファイルに保存した場合、「あ」の文字は、

UTF-16 LE では 0×4230、 UTF-16 BE では 0×3042、 UTF-8 では、0xE38182

というバイト列になります。ユニコードで同じ文字を入力しても、エンコード方式によってバイト列が異なっていることが分かります。また、1文字を表すバイト列の長さ、つまりデータ量もエンコード方式によって変わっています。「あ」のバイト列が、UTF-16 LE と UTF-16 BE では2バイトなのに対して、UTF-8 では3バイトになっていることが分かります。

文字を統一的に処理するために生まれたユニコードを、なぜ複数のエンコード方式を使って別のバイト列に変換するのでしょうか？なかなか理解しにくいところですが、前述した文字集合規格の変遷のなかで、旧来の文字コードとの互換性やデータ処理量、サポートすべき文字の範囲など、様々な目的に応じたエンコード方式が作られていったのではないかと思います。
前回お話ししたように、SAPシステムでは、UTF-8とUTF-16の2つのエンコード方式が併用されています。次回は、2つのエンコード方式の1 つ、UTF-16についてお話しします。引き続き、よろしくお願いいたします。