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 月にリリースされた Unicode 5.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 システムの内部処理については、もう少し触れたいことがありますので、次回も同じテーマでお話ししたいと思います。 引き続き、よろしくお願いいたします。

お問い合わせ

  • Webで簡単お問い合わせ

    製品、導入事例、関連セミナーなど
    お気軽にお問い合わせください。

  • SAPアダプタ ショールーム

    製品デモンストレーションを
    見てみませんか?

  • 資料ダウンロード

    製品別のパンフレットや導入事例の資料をダウンロードできます。

  • エンジニアコラム
  • 特別コラム
  • サイト内用語解説