情報発信
情報発信
第3回のコラムで少し触れましたが、UTF-16では、サロゲートペアと呼ばれる仕組みで一部の特殊な文字を4バイトで符号化します。今回は、サロゲートペアに関する問題についてお話しします。
UTF-16は、UCS-2に収録されていないUCS-4の0群1?16面の文字集合をサロゲートペアを使って符号化します。したがって、UCS-2に収録された文字は、2バイト、それ以外の文字は、4バイトで符号化されることになり、UTF-8と同様に1文字ごとのバイト長が可変します。
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 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の符号化による問題が発生するでしょう。
このような理由から、ConnectPlus Unicodeは、現時点でサロゲート文字を正しく処理することができませんが、サロゲート文字を含むデータを送受信した場合でも、データの桁ずれなどによってデータ全体が破損することはありません。SAPの関数やデータ変換ツールがサロゲートペア対応されるまでは、一部のJIS X 0213追加漢字で文字化けが発生しますが、データの送受信が失敗することがないように設計されてります。