【ConnectPlusユニコード開発】第3回 UTF-16 と SAP ユニコードシステム (1)

今回は、ユニコードのエンコード方式の1つであるUTF-16と、UTF-16を内部処理の文字コードに採用したSAP ユニコードシステムについてお話しします。

UTF-16

前回、ユニコードには、128の群、256の面、256の区、256の点の組み合わせから成る、20 億個の文字集合であるUCS-4と、UCS-4の0群0 面にある65,536個の文字の部分集合であるUCS-2の2通りの文字集合があると説明しました。

UTF-16は、UCS-4の0群に属する0面から16面の文字を対象にしたエンコード方式です。従って、UTF-16は、UCS-4が定義可能なすべての文字コードを完全に処理することはできません。しかし、2006年7月にリリースされたUnicode5.0の時点では、0群の0面から16面のなかにすべての文字が収録されているので、現状では、UTF-16でユニコードのすべての文字を処理できるということになります。

UTF-16は、UCS-2に含まれる文字を2バイト、0群1面から16面の文字をサロゲートペアと呼ばれる仕組みを使って4バイトに符号化します。 一般的に使用される文字が2バイトで符号化されるので、英数字以外の文字データを多く扱うシステムの場合、他のユニコードのエンコード方式に比べるとシステム全体のデータ量が少なくなる傾向があります。逆に、英数字を主に扱うシステムの場合は、UTF-8では1バイトの英数字がUTF-16では2バイトで符号化されてしまうので、システム全体のデータ量が増加することになります。

エンディアンと BOM

UTF-16には、エンディアンとBOM (Byte Order Mark)の関係でいくつかの種類が存在します。SAP ユニコードシステムにはあまり関係がないのですが、少し説明をしておきたいと思います。

エンディアンとは、バイト列を並べる順番のことで、データのバイト列をそのまま並べる方法をビッグエンディアン (big endian)、1バイト目と2バイト目をひっくり返して並べる方法をリトルエンディアン (little endian) といいます。エンディアンは、コンピューターの CPUの処理方法によって使い分けがされていて、例えば、SunマイクロシステムズのSPARCは、ビッグエンディアン、インテルのx86系のCPU は、リトルエンディアンを採用しています。

Byte Order Mark (BOM)は、ファイルストリームの先頭に付与されるエンディアンを表す印のことです。ファイルストリームの先頭にある BOMの値を使って、このファイルがどんなバイト順でデータを保存しているのかを判定することができます。

UTF-16は、エンディアンの違いとBOMの有無によって、
1. BOM ありのビッグエンディアン
2. BOM ありのリトルエンディアン
3. BOM なしのビッグエンディアン
の3通りに分類されます。例えば、Windows 2000やXPのメモ帳で「あ」の文字を入力したとします。文字コードにUnicode big endian　(=UTF-16のBOMありビッグエンディアン)を指定してファイルを保存した場合、ファイル全体のバイト列は、0xFEFF3042になります。この場合、バイト列の先頭の2バイトFEFFがビッグエンディアンを表すBOMで、3042が「あ」のエンコード値3042をビッグエンディアンで並べたバイト列になります。
一方、文字コードUnicode(=UTF-16のBOMありリトルエンディアン)を指定して保存すると、バイト列は、0xFFFE4230になり、バイト列の先頭のFFFEがリトルエンディアンを表すBOM、4230が「あ」のエンコード値0×3042をリトルエンディアンで並べたバイト列になります。

SAP ユニコードシステムの内部処理と MDMP システムとの違い

SAP ユニコードシステムは、内部処理のエンコード方式に UTF-16 を採用しています。一方、ユニコードを採用する前の SAP システムは、MDMP (Multi-Display, Multi-Processing code pages system) と呼ばれる仕組みで多言語対応を行っていて、日本語の場合は、内部処理のエンコード方式にシフト JIS を採用していました。では、内部処理のエンコード方式が シフト JIS から UTF-16 に変わると、何が違ってくるのでしょうか。

シフトJISのMDMPシステムとUTF-16のユニコードシステムの大きな違いの1つに、「1文字の長さ」が挙げられるのではないかと思います。「1文字の長さとは、プログラミング言語ABAPの文字型(TYPE C)や数値文字型(TYPE N）の1個分のバイト長を指しています。SAP社が公開している文書Supported Languages in Unicode SAP Systemsに、MDMPシステムでは1文字の長さを1バイト、ユニコードシステムでは 2バイトで処理するとの記述があります。

1 文字の長さの違い

では、1文字の長さが変わると、どのようなことが起こるのでしょうか。例えば、「あ」という文字をSAPシステムに入力したとします。MDMP システムは、文字型1個分の長さが1バイトで、シフトJISで全角かな文字を1文字当たり2バイトで符号化するので、「あ」は、2バイトに符号化され、文字型長さ2の領域が必要になります。
一方、ユニコードシステムは、文字型1個分の長さが2バイトで、UTF-16で全角かな文字を1文字当たり2バイトで符号化するので、「あ」が 2バイトに符号化されるのは変わりませんが、文字型長さ1の領域があればよいことになります。

SAP システム	エンコード方式	1 文字の長さ	文字型長さ2の領域
MDMP	シフト JIS	1 バイト	82	A0
ユニコード	UTF-16	2 バイト	30 42　*	不要

*ビッグエンディアンの場合

この1文字の長さの違いでどのような差が現れるのでしょうか。
得意先マスターの得意先名称項目（項目名 KNA1-NAME1）を例にして説明します。得意先名称項目の属性は、文字型の長さ 40 です。 MDMP システムでは、全角かな漢字文字で得意先の名前を入力すると最高で20文字しか入力できません。
では、MDMPシステムからユニコードシステムにバージョンアップするとどうなるでしょうか。ユニコードシステムにバージョンアップしても、得意先名称項目の属性は、文字型の長さ40のままです。しかし、ユニコードシステムでは、長さ1当たり2バイトで、80バイト分のデータを入力できるので、UTF-16で1文字2バイトで符号化される全角文字は、40文字まで入力可能です。つまり、得意先名称に限らず、これまで全角文字を入力していた項目は、ユニコードシステムに切り替えると、入力可能な文字数が倍に増えることになるのです。これは、日本語ユーザにとっては、大きなメリットになるかもしれません。

1 文字の長さとデータ量

では、1文字の長さの違いによるデメリットはないのでしょうか。まず考えられるのは、処理されるデータ量の問題です。先ほど、UTF-16 によるデータ量の増減について触れましたが、それは、ユニコードの他のエンコード方式との比較であって、シフト JIS を使うMDMPシステムと比較すれば、明らかにデータの処理量は多くなります。

シフトJISは、英数字、半角カナ文字を1バイトで符号化しますが、UTF-16は、これらの文字を2バイトで符号化します。一方、シフトJIS、UTF-16とも、全角かな漢字を2バイトで符号化するので、SAPシステムをユニコードに切り替えると、全角かな漢字のデータ量は変わらず、英数字、半角カナのデータ量が倍になるということになります。
SAPシステムで日本語を使っているといっても、データの大部分は英数字だと思いますので、英数字のデータ量が倍になるのは、コンピューターの処理能力からみると大きな問題です。このことは、前述のSupported Languages in Unicode SAP Systemsでも触れられていて、MDMPシステムとの比較で、ユニコードシステムは、CPUの処理能力で30％、メモリ容量で50%、データベースの容量については、35%から70 %（データベースソフトの依存）と、より性能の高いハードウエアを用意することが求められています。

しかし、この点は、あまり大きな問題にならないかもしれません。R/3リリース4.6Cからのバージョンアップを想定すると、現在使用中の SAPシステムは、3,4年ほど前のハードウエアを使って稼動していることでしょう。SAPシステムのバージョンアップと同時にハードウエアの入替を行えば、最新のハードウエアとの対価格性能比を考えると、データ量の増加によるシステム負荷を許 容できるかもしれません。

UTF-16 の話は、もう少し続きます

今回は、ユニコードのエンコード方式UTF-16とSAPシステムの内部処理についてお話ししました。SAPユニコードシステムについては、SAP 文書Suppoeted Languages in Unicode SAP Systemsに依っていますが、最新の情報などは、SAP社から入手されることをお勧めいたします。

UTF-16とSAPシステムの内部処理については、もう少し触れたいことがありますので、次回も同じテーマでお話ししたいと思います。引き続き、よろしくお願いいたします。