【SAP ERP（SAP S/4HANA）データ連携製品ユニコード開発】第2回 ユニコードについて

　～第２回～　
　SAP ERP（SAP S/4HANA）ユニコードシステム専用の接続ツール開発談　
　ユニコードについて　

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

ユニコードとは

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

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

ユニコードはコンピューターが扱いやすいように、世界中で使用される文字を１つの体系にまとめるためにつくられた文字コード体系と言い換えられるかもしれません。
ユニコードは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 では 0×E38182

というバイト列になります。
ユニコードで同じ文字を入力しても、エンコード方式によってバイト列が異なっていることが分かります。
また、1文字を表すバイト列の長さ、つまりデータ量もエンコード方式によって変わっています。
「あ」のバイト列がUTF-16 LEとUTF-16 BEでは2バイトなのに対して、UTF-8では3バイトになっていることが分かります。
文字を統一的に処理するために生まれたユニコードを、なぜ複数のエンコード方式を使って別のバイト列に変換するのでしょうか？
なかなか理解しにくいところですが、前述した文字集合規格の変遷のなかで、旧来の文字コードとの互換性やデータ処理量・サポートすべき文字の範囲など様々な目的に応じたエンコード方式が作られていったのではないかと思います。
前回お伝えしたように、SAP ERPではUTF-8とUTF-16の2つのエンコード方式が併用されています。

次回は、2つのエンコード方式の1つUTF-16についてお伝えします。
【SAP ERP（SAP S/4HANA）データ連携製品ユニコード開発】第3回 UTF-16について　は こちら