ConnectPlusユニコード開発

第7回 サロゲートペア

第 3 回のコラムで少し触れましたが、UTF-16 では、サロゲートペアと呼ばれる仕組みで一部の特殊な文字を 4 バイトで符号化します。今回は、サロゲートペアに関する問題についてお話しします。

 

■ サロゲートペア

サロゲートペアは、UCS-2 の 2 つの未使用領域 0xD800 – 0xDBFF、0xDC00 – 0xDFFF を使い、1 文字分のコードを 2 つ組み合わせて 1 つの文字を表す仕組みです。2 つの領域には、それぞれ 1,024 文字分のコードがあるので、2 つ組み合わせると最大 1,024 X 1,024 = 1,048,576 の文字を表現することが可能になります。

 

UTF-16 は、UCS-2 に収録されていない UCS-4 の 0 群 1 – 16 面の文字集合をサロゲートペアを使って符号化します。したがって、UCS-2 に収録された文字は、2 バイト、それ以外の文字は、4 バイトで符号化されることになり、UTF-8 と同様に 1 文字ごとのバイト長が可変します。

 

■ JIS X 0213 と Windows Vista

このような規定があるのですが、UTF-16 の符号化で文字を 2 バイト固定長として処理するソフトウエアが少なからず存在するのが実情です。この背景には、サロゲートペアで符号化する文字(以下、サロゲート文字)のコ ンピューター入力が一般的に行われていなかったので、文字を 2 バイト固定長で処理しても問題がなかったという事情があります。
日本語の場合、半角カナ、全角かな、JIS 第一、第二水準漢字、NEC 拡張文字、IBM 拡張漢字など、一般に使われる文字は、UCS-2 に収録されています。したがって、例えば Windows XP でマイクロソフト標準のフォントと文字変換ソフト(以下、IME)を使っている限りは、UCS-2 の範囲で文字入力が行われるので、UTF-16 の符号化でサロゲートペアの対応を行う必要がありませんでした。しかし、JIS X 0213 という新しい文字規格と、この規格に対応した Windows Vista の登場によって、状況が大きく変わろうとしています。

 

JIS X 0213 は、2000 年に制定され、2004 年に改正された日本語の文字コードに関する JIS 規格です。JIS X 0213 では、常用漢字表にない特殊な漢字を、第三水準漢字(1,259 字)、第四水準漢字(2,436 字)として新たに定義しました。
ユニコードでは、JIS X 0213 の追加漢字の一部をすでに UCS-2 に収録していましたが、JIS X 0213 に完全対応するため、残りの漢字を UCS-4 の 0 群 2 面、つまり UTF-16 のサロゲート文字の範囲に追加しました。
一方、マイクロソフトは、Windows Vista で JIS X 0213 対応を行うため、マイクロソフト標準の日本語フォントである MS ゴシックと MS 明朝に追加漢字の字体を追加しました。また、IME のJIS X 0213 対応を行い、JIS X 0213 の追加漢字を含んだ単語の文字変換を可能にしました。

 

JIS X 0213 と Windows Vista によって、パソコンでもサロゲート文字の入力が行われるようになります。したがって、Windows Vista で動作するソフトウエアは、UTF-16 の符号化でサロゲートペアの対応を行う必要があります。Windows XP や Windows 2000 で正常に動作しているソフトウエアでも、サロゲートペアに未対応であれば、Windows Vista では正しく動作するとは限りません。

 

■ ConnectPlus と サロゲートペア

2007 年 2 月現在、弊社製品 ConnectPlus Unicode は、サロゲート文字への対応が完全ではありません。現時点の SAP RFC ライブラリーとデータ変換ソフト AnyTran の仕様により、サロゲート文字を正しく符号化できないのが原因です。

 

ConnectPlus Unicode は、SAP 社が提供しているユニコード対応の C 言語ライブラリーを使って開発を行っています。このライブラリーのなかに、UTF-16 で内部処理されたデータをファイルに出力する関数 fwriteU、fputsU があります。これら関数は、UTF-8 ではなく CESU-8 という特殊なエンコード方式を使って文字を符号化するので、サロゲート文字を正しく処理できません。

 

CESU-8 は、プログラム内部での使用を前提にしたエンコード方式で、UTF-16 のバイト列をすべて 1 文字 2 バイトで扱い、UTF-8 と同一の変換ルールで符号化します(ユニコードコンソーシアム技術文書 Unicode Technical Report #26 参照)。このため、UCS-2 に含まれる文字は、UTF-8 とまったく同じバイト列で符号化されるのですが、サロゲートペア文字は、2 文字扱いで処理されるので、正規の UTF-8 とは異なるバイト列で符号化されます。
ユニコードコンソーシアムでは、データの外部出力で CESU-8 を使用することを推奨していません。しかし、日本語、中国語、韓国語などの「特殊な」言語を除けば、UCS-2 の文字集合で事が足りるので、UTF-8 の代わりにサロゲートペアの例外処理が不要な CESU-8 をエンコード方式に採用しているソフトウエアが存在します。SAP のファイル出力関数の場合でも、JIS X 0213 追加漢字が文字列に含まれていなければ、UTF-8 と全く同じバイト列で日本語を符号化できるので問題がありません。しかし、 Windows Vista が普及し、JIS X 0213 の追加漢字が普通に入力されるようになれば、日本語を扱う SAP システムでは、CESU-8 の符号化による問題が発生するでしょう。

 

AnyTranは、株式会社データ・アプリケーションが販売するデータ変換ツールソフトです。EDI のデータ変換やシステム間の文字コード変換で非常に実績のあるソフトウエアで、ConnectPlus も SAP システムのデータ形式 IDoc のデータ変換に AnyTran を採用しています。AnyTran は、UTF-8 データを編集したり、シフト JIS などの他の文字コードに変換することが可能ですが、執筆時点(2007 年 2 月)では、この機能で処理可能な文字に 「UTF-8 UNICODE(UCS-2)日本語1~3バイト表現」という制約があります。UTF-16 のサロゲート文字は、UTF-8 の 4 バイト表現になるので、AnyTran では、SAP ユニコードシステムで入力されたサロゲート文字を正しく編集することができません。

 

このような理由から、ConnectPlus Unicode は、現時点でサロゲート文字を正しく処理することができませんが、サロゲート文字を含むデータを送受信した場合でも、データの桁ずれなどによってデータ全体が破損することはありません。SAP の関数やデータ変換ツールがサロゲートペア対応されるまでは、一部の JIS X 0213 追加漢字で文字化けが発生しますが、データの送受信が失敗することがないように設計されてります。

 

■ 次回は ConnectPlus の仕組みをお話しします

このコラムは、次回で最終回になります。最後に、当社が開発した ConnectPlus Unicode についてお話しします。よろしくお願いいたします。

お問い合わせ

  • Webで簡単お問い合わせ

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

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

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

  • 資料ダウンロード

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

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