管理の手引き


DB2 UDB での Unicode/UCS-2 および UTF-8 サポート

ここでは、2 つの規格について説明します。

概要

Unicode 文字コード化規格は、固定長の文字コード化スキームです。 これには、世界で実際に使われているほとんどすべての言語の文字が含まれています。 Unicode 文字は通常は 「U+xxxx」 のように示されます。この xxxx には文字の 16 進コードが入ります。

言語に関係なく、それぞれの文字は 16 ビット (2 バイト) の大きさです。 世界の主要な言語で使われているほとんどの文字をコード化するのであれば、 65000 のコード要素があれば十分ですが、Unicode 規格の拡張メカニズムでは、 さらに 100 万文字をコード化することが可能です。 この拡張機能は、特定の 32 ビット文字を 2 つの連続したコード要素としてコード化するために、ある範囲のコード値を予約します (U+D800 から U+D8FF (これらを「サロゲート」といいます))。

国際標準化機構 (ISO) および国際電気標準会議 (IEC) 規格 10646 (ISO/IEC 10646) の定める Universal Multiple-Octet Coded Character Set (UCS) には、 2 バイト版 (UCS-2) と 4 バイト版 (UCS-4) があります。 2 バイト版の ISO 規格は、サロゲートのない Unicode と同じものです。 ISO 10646 ではさらに、特定の UCS-4 コードを UCS-2 コード化ストリングでコード化するための拡張機能も定義しています。 この拡張機能を UTF-16 といい、サロゲートのある Unicode と同じです。

DB2 UDB は、UCS-2、すなわちサロゲートのない Unicode をサポートしています。

UTF-8 (コード・ページ 1208) クライアントから 非 Unicode データベースへの接続はサポートされていません。

UTF-8

UCS-2 すなわち Unicode コード化では、ASCII および制御文字も 2 バイトの長さであり、 先頭のバイトはゼロになります。 たとえば NULL は U+0000 で、大文字の A は U+0041 になります。 UCS-2 ストリングでは異質な NULL がストリング内に現れることがあり、 このため、ASCII ベースのアプリケーションや ASCII ファイル・システムで大きな問題になる場合があります。 一定の ASCII コードに依存するプログラムの場合には、 UTF-8 という変換アルゴリズムを使用してこの問題を避けることができます。

UTF-8 (UCS 変換形式 8) は、一種の変換アルゴリズムであり、固定長の UCS-4 文字を可変長のバイト・ストリングに変換します。 UTF-8 では、ASCII 文字はそれぞれ通常の 1 バイト・コードで表されますが、 UCS-2 での非 ASCII 文字は 2 または 3 バイトの長さになります。 つまり、UTF-8 は UCS-2 文字をマルチバイトのコード・セットに変換しますが、 ASCII 文字は一定であるということです。 UTF-8 形式におけるそれぞれの UCS-2 文字のバイト数は、 次の表を見て判断することができます。

    UCS-2 (16 進)   UTF-8 (2 進)                   説明
    ------------    --------------------------     ----------------
    0000 〜 007F    0xxxxxxx                       ASCII
    0080 〜 07FF    110xxxxx 10xxxxxx              最大 U+07FF まで
    0800 〜 FFFF    1110xxxx 10xxxxxx 10xxxxxx     その他の UCS-2
    注: D800 〜 DFFF の範囲は、この表の 3 行目の扱いから除外されます。
        その範囲の値は 0000 0800 〜 0000 FFFF の範囲の UCS-4 を制御します。
 

上記のいずれの場合でも、一連の x は、文字の UCS ビット表記です。 たとえば、U0080 は 11000010 10000000 に変換されます。

DB2 UDB での UCS-2/UTF-8 の実装

コード・ページ / CCSID 番号

IBM では、UCS-2 コード・ページはコード・ページ 1200 として登録されています。 すべてのコード・ページは、増加していく文字セットとして定義されます。 つまり、あるコード・ページに新しい文字が追加されるときに、そのコード・ページ番号が変わってしまうことはありません。 コード・ページ 1200 は、常に現行バージョンの Unicode/UCS-2 を参照し、 DB2 UDB の UCS-2 サポートで使用されます。

また、Unicode 2.0 および ISO/IEC 10646-1 で定義されている 特別なバージョンの UCS 規格が、 IBM 内部で CCSID 13488 として登録されています。 この CCSID は、漢字ストリング・データを euc-Japan および euc-Taiwan データベースに格納するときに、 DB2 UDB によって内部的に使用されます。 CCSID 13488 およびコード・ページ 1200 はどちらも UCS-2 を参照し、値が「2 バイト」 (DBCS) のスペースの場合を除き、同じ方法で処理されます。

     CP/CCSID        1 バイト (SBCS) スペース      2 バイト (DBCS) スペース
    ---------        ------------------------      ------------------------
      1200                   N/A                           U+0020
      13488                  N/A                           U+3000
    注: UCS-2 データベースでは、U+3000 に特別な意味はありません。

変換表によると、コード・ページ 1200 は CCSID 13488 のスーパーセットであるため、 どちらにも同じ (スーパーセット) 表が使われます。

IBM では、UTF-8 は、 文字セットが増やされた CCSID 1208 として登録されています (コード・ページ 1208 ともいう)。 この規格に新しい文字が追加されたとしても、この番号 (1208) は変わりません。 DB2 の UCS-2/UTF-8 サポートでは、マルチバイトのコード・ページ番号として 1208 が使用されます。

DB2 UDB は、新しいマルチバイトのコード・ページとして UCS-2 をサポートしています。 この MBCS コード・ページ番号は 1208 です。これは、データベースのコード・ページ番号、 そしてそのデータベース内に含まれる文字ストリング・データのコード・ページです。 UCS-2 用の 2 バイトのコード・ページ番号は 1200 です。 これは、データベース内の漢字ストリング・データのコード・ページです。 データベースが UCS-2/UTF-8 で作成されていれば、CHAR、VARCHAR、LONG VARCHAR、 および CLOB データは UTF-8 で格納され、GRAPHIC、VARGRAPHIC、LONG VARGRAPHIC、および DBCLOB データは UCS-2 で格納されます。 これを簡単に UCS-2 データベースと呼んでいます。

UCS-2 データベースの作成

デフォルトでは、データベースは、 データベースを作成しているアプリケーションのコード・ページで作成されます。 したがって、UTF-8 クライアントからデータベースを作成する場合 (たとえば、 AIX の UNIVERSAL ロケール)、 またはそのクライアントの DB2CODEPAGE レジストリー変数を 1208 にセットした場合、 作成されるデータベースは UCS-2 データベースになります。 別の方法として、CODESET 名として「UTF-8」を指定し、 DB2 UDB によってサポートされている任意の 2 文字の地域コードを使うことができます。

たとえば、米国の地域コードを指定して UCS-2 データベースを作成するには、 次のコマンドを発行します。

   DB2 CREATE DATABASE dbname USING CODESET UTF-8 TERRITORY US

sqlecrea API を使用して UCS-2 データベースを作成するには、 それぞれの値を sqledbcountryinfo にセットする必要があります。 たとえば、SQLDBCODESET を UTF-8 にセットし、SQLDBLOCALE を任意の有効な地域コード (たとえば、US) にセットします。

UCS-2 データベースの省略時の照合順序は IDENTITY です。 UCS-2 コード・ポイントの順に処理されます。 したがって、デフォルトでは、すべての UCS-2/UTF-8 文字が順番に並べられ、 それぞれの UCS-2 コード・ポイントの順序に基づいて比較されます。

日時形式、小数点など、地域に関係するパラメーターはすべて、クライアントの現在の地域に基づいています。

UCS-2 データベースでは、DB2 UDB によってサポートされているそれぞれの単一バイトおよびマルチバイト・コード・ページからの接続が可能です。 クライアントのコード・ページと UTF-8 との間のコード・ページ文字変換は、データベース・マネージャーによって自動的に行われます。 漢字ストリング・タイプのデータは常に UCS-2 内に存在し、コード・ページ変換は行われません。 ただしコマンド行プロセッサー (CLP) 環境は例外です。 CLP から漢字ストリング (UCS-2) データを意図的に選択すると、 戻される漢字ストリング・データは、 CLP によって UCS-2 からそれぞれのクライアント環境のコード・ページに変換されます。

各クライアントは、それぞれの環境でサポートされている文字レパートリー、 入力方式、およびフォントによって制限を受けますが、 UCS-2 データベース自体はすべての UCS-2 文字を受け入れて格納します。 そのため、各クライアントでは、通常は UCS-2 文字のサブセットを処理しますが、 データベース・マネージャーでは UCS-2 文字の全レパートリーを処理できます。

文字をローカル・コード・ページから UTF-8 に変換すると、バイト数が増大する可能性があります。 ASCII 文字の場合はこのような増大はありませんが、 他の UCS-2 文字は、いくつかの要因のために増大します。 UTF-8 形式におけるそれぞれの UCS-2 文字のバイト数は、 UTF-8の表を見て判断することができます。

データ・タイプ

DB2 UDB によってサポートされているデータ・タイプはすべて、 UCS-2 データベースでもサポートされています。 特に、漢字ストリング・データは UCS-2 データベースでサポートされており、 UCS-2/Unicode で格納されます。 SBCS クライアントを含むそれぞれのクライアントでは、 UCS-2 データベースへ接続するときに、 UCS-2/Unicode の漢字ストリング・データ・タイプを処理できます。

UCS-2 データベースは、MBCS データベースに似ています。このデータベースでは文字ストリング・データがバイト数で測定されます。 文字ストリング・データを UTF-8 で処理する場合、 それぞれの文字を 1 バイトとみなすことはできません。 マルチバイト UTF-8 コード化では、各 ASCII 文字は 1 バイトですが、 非 ASCII 文字はそれぞれ 2 バイトか 3 バイトになります。 CHAR フィールドを定義するときには、このことを考慮するようにします。 ASCII 文字と非 ASCII 文字の比率に応じて、サイズが 、n バイトの CHAR フィールドには、 n/3 文字から n 文字までの任意のものを指定できます。

さらに、漢字ストリング UCS-2 データ・タイプに対して文字ストリング UTF-8 コード化を使うことも、合計記憶域要件に影響します。 文字の大多数が ASCII で、非 ASCII 文字が少ししか含まれない場合、記憶要件は 1 文字当たり 1 バイトに近づくため、 UTF-8 データを格納することはより良い選択かもしれません。 一方、文字の大多数が非 ASCII 文字であり、 3 バイトの UTF-8 シーケンスで展開される場合 (たとえば表意文字)、 各 UCS-2 文字はちょうど 2 バイトを必要とするため、 UTF-8 形式で UCS-2 文字に相当する文字ごとに 3 バイトを割り当てるよりも、 UCS-2 漢字ストリング形式を選択する方が良いかもしれません。

MBCS 環境では、文字ストリングに対して機能する SQL スカラー関数 (LENGTH、 SUBSTR、 POSSTR、MAX、MIN など) は、 文字数ではなくバイト数に基づいて機能します。 この動作は UCS-2 データベースでも同じですが、 これらの値は常にデータベース・コード・ページのコンテキスト内に定義されるため、 USC-2 データベースにオフセットと長さを指定するときには、特別な注意が必要です。 このことは、UCS-2 データベースを UTF-8 で定義する場合に特に当てはまります。 単一バイト文字の中には UTF-8 で 2 バイト以上を必要とするものもあるため、 単一バイト・データベースに有効な SUBSTR 指標は、 UCS-2 データベースには有効ではない場合があります。 正しくない指標を指定すると、SQLCODE -191 (SQLSTATE 22504) が戻されます。 これらの関数の動作についての詳細は、SQL 解説書 を参照してください。

SQL CHAR データ・タイプは、ユーザー・プログラムに おける C 言語の char データ・タイプによってサポートされています。 SQL GRAPHIC データ・タイプは、ユーザー・プログラムの sqldbchar によってサポートされています。 ただし UCS-2 データベースでは、sqldbchar データは常にビッグ・エンディアン (バイト数の大きい順番) 形式であるということに注意してください。 アプリケーション・プログラムを UCS-2 データベースに接続すると、 文字ストリング・データは DB2 UDB によってアプリケーション・コード・ページと UTF-8 との間で変換されますが、 漢字ストリング・データは常に UCS-2 になります。

識別子

UCS-2 データベースでは、識別子はすべてマルチバイトの UTF-8 です。 ですから、DB2 UDB によって拡張文字セット (たとえば、アクセント記号、 マルチバイト文字) での文字の使用が許可されている箇所では、 識別子として任意の UCS-2 文字を使用することができます。 拡張文字を使用できる識別子について詳しくは、 付録 A, 命名規則を参照してください。

クライアントは、 それぞれの SBCS または MBCS 環境でサポートされている任意の文字を入力することができます。 その後、識別子に入れられたすべての文字がデータベース・マネージャーによって UTF-8 へ変換されます。 UCS-2 データベースで識別子に各国語の文字を指定するときには、 以下の 2 つの点を考慮する必要があります。

UCS-2 リテラル

UCS-2 リテラルは、以下の 2 つの方法で指定できます。

コマンド行プロセッサー (CLP) を使用する場合、 UCS-2 文字がローカル・アプリケーションのコード・ページに存在すれば、 最初の方法の方が簡単です (たとえば、 コード・ページ 850 を使用している端末からコード・ページ 850 の文字を入力する場合)。 2 番目の方式は、 アプリケーション・コード・ページのレパートリー外の文字のために使うようにします (たとえば、 コード・ページ 850 を使用している端末から日本語の文字を指定する場合)。

UCS-2 データベースにおけるパターン照合

パターン照合において、 既存の MBCS データベースの動作は UCS-2 データベースの動作とは少し異なります。

DB2 UDB の MBCS データベースの現在の動作を考える場合、 突き合わせ式に MBCS データが含まれていれば、 パターンには SBCS 文字と MBCS 文字の両方が含まれる可能性があります。 パターンに含まれる特殊文字は以下のように解釈されます。

突き合わせ式に漢字ストリング DBCS データが含まれる場合、 その式には DBCS 文字だけが含まれます。 パターンに含まれる特殊文字は以下のように解釈されます。

UCS-2 データベースでは、「単一バイト」文字と「2 バイト」文字とは区別されません。 UCS-2 文字はそれぞれ 2 バイトを使います。 UTF-8 形式では、UCS-2 文字が「混合バイト」でコード化されますが、 UTF-8 において SBCS 文字と MBCS 文字との間の区別はありません。 それぞれの文字は、UTF-8 形式でのバイト数にかかわらず UCS-2 文字です。 ある文字ストリングあるいは漢字ストリングの式を指定する場合、 下線は 1 つの UCS-2 文字を表し、パーセント記号はゼロ以上の UCS-2 文字のストリングを表します。

クライアントでは、この文字ストリング式は、クライアントのコード・ページに含まれており、 データベース・マネージャーによって UTF-8 へ変換されます。 SBCS クライアントのコード・ページには DBCS パーセント記号や DBCS 下線は含まれていませんが、 サポートされている各コード・ページには、 単一バイトのパーセント記号 (U+0025 に相当) および単一バイトの下線 (U+005F に相当) が含まれています。 UCS-2 データベースでの特殊文字の解釈は以下のとおりです。

さらに DBCS コード・ページは、 1 つの DBCS パーセント記号 (U+FF05 に相当) と 1 つの DBCS 下線 (U+FF3F に相当) をサポートしています。 これらの文字は、UCS-2 データベースでは特別な意味がありません。

任意指定の "エスケープ式" を使い、 下線およびパーセント記号の特別な意味を変更する際に使われる文字を指定する場合、 サポートされるのは、ASCII 文字、あるいは 2 バイトの UTF-8 シーケンスに展開される文字だけです。 エスケープ文字を指定して、3 バイトの UTF-8 値に展開すると、 エラー・メッセージ (エラー SQL0130N、SQLSTATE 22019) が戻されます。

インポート / エクスポート / ロードについての考慮事項

このセクションで説明されているように、UCS-2 データベースでは、DEL、ASC、および PC/IXF ファイル形式だけがサポートされています。 WSF 形式はサポートされていません。

UCS-2 データベースから ASCII 区切り (DEL) ファイルへエクスポートすると、 文字データはすべてアプリケーション・コード・ページに変換されます。 文字ストリング・データと漢字ストリング・データはどちらも、 クライアントの同じ SBCS または MBCS コード・ページに変換されます。 これは、いずれのデータベースをエクスポートするときに予想される動作であり、 区切り付き ASCII ファイル全体には 1 つのコード・ページしか含められないので、 この動作を変更することはできません。 したがって、区切り付き ASCII ファイルへエクスポートするときには、 アプリケーション・コード・ページに存在する UCS-2 文字だけが保管されます。 他の文字については、アプリケーション・コード・ページの省略時の置換文字に置き換えられます。 UTF-8 クライアント (コード・ページ 1208) の場合、 UTF-8 クライアント側ですべての UCS-2 文字がサポートされているので、 データが失われることはありません。

ASCII ファイル (DEL または ASC) から UCS-2 データベースへインポートする場合、 文字ストリング・データはアプリケーション・コード・ページから UTF-8 に変換され、 漢字ストリング・データはアプリケーション・コード・ページから UCS-2 に変換されます。 失われるデータはありません。 別のコード・ページに保管された ASCII データをインポートする場合は、 インポートのコマンドを発行する前に、 データ・ファイルのコード・ページを変更する必要があります。 そのための方法の 1 つは、ASCII データ・ファイルのコード・ページに、 DB2CODEPAGE をセットすることです。

SBCS および MBCS クライアントで有効な ASCII 区切り文字の範囲は、 DB2 UDB によってこれらのクライアント向けに現在サポートされている、 有効な ASCII 区切り文字の範囲と同じになります。 UTF-8 クライアントでの有効な区切り文字の範囲は 0x01 〜 0x7F で、通常の制約があります。 これらの制約の完全なリストは、データ移動ユーティリティー 手引きおよび解説書 の付録 『エクスポート / インポート / ロード・ユーティリティーのファイル形式』を参照してください。

UCS-2 データベースから PC/IXF ファイルにエクスポートする場合、 文字ストリング・データはクライアントの SBCS/MBCS コード・ページに変換されます。 漢字ストリング・データは変換されず、UCS-2 (コード・ページ 1200) で格納されます。 失われるデータはありません。

PC/IXF ファイルから UCS-2 データベースへインポートする場合、 文字ストリング・データは、 PC/IXF ヘッダーに示されている SBCS/MBCS コード・ページに含まれるものとみなされ、 漢字ストリング・データは、 PC/IXF ヘッダーに示されている DBCS コード・ページに含まれるものとみなされます。 文字ストリング・データは、インポート・ユーティリティーにより、 PC/IXF ヘッダーで指定されたコード・ページからクライアントのコード・ページに変換され、 その後、(INSERT ステートメントにより) クライアントのコード・ページから UTF-8 へ変換されます。 漢字ストリング・データは、インポート・ユーティリティーにより、 PC/IXF ヘッダーで指定された DBCS コード・ページから UCS-2 (コード・ページ 1200) へ直接に変換されます。

ロード・ユーティリティーはデータを直接にデータベースへ入れ、デフォルトで、 ASC または DEL ファイルのデータはデータベースのコード・ページであるとみなします。 したがって、ASCII ファイルについては、デフォルトではコード・ページ変換は行われません。 (codepage 修飾子を使用して) データ・ファイルのコード・ページを 明示的に指定しておけば、 ロード・ユーティリティーはその情報を利用して コード・ページをデータベースのコード・ページに変換し、 それからデータをロードします。 PC/IXF の場合、 ロード・ユーティリティーは常に IXF ヘッダーで指定したコード・ページから データベースのコード・ページ (CHAR の場合は 1208、 GRAPHIC の場合は 1200) へ変換します。

DBCLOB ファイルのコード・ページは、UCS-2 では必ず 1200 です。 CLOB ファイルのコード・ページは、インポート、ロード、エクスポートされるデータ・ファイルのコード・ページと同じです。 たとえば、PC/IXF 形式を使用してデータをロードまたはインポートするときには、 CLOB ファイルは、PC/IXF ヘッダーで指定したコード・ページであるとみなされます。 DBCLOB ファイルが ASC または DEL 形式である場合、 ロード・ユーティリティーは、(codepage 修飾子を使って 別のコード・ページを明示的に指定しない限り) CLOB データがデータベースの コード・ページであるとみなし、インポート・ユーティリティーは、 クライアントのアプリケーション・コード・ページであるとみなします。

UCS-2 データベースでは、 以下の理由で nochecklengths 修飾子を常に指定します。

ロード、インポート、およびエクスポート・ユーティリティーについての詳細は、 データ移動ユーティリティー 手引きおよび解説書 を参照してください。

非互換性

UCS-2 データベースに接続されるアプリケーションの場合、 漢字ストリング・データは常に UCS-2 (コード・ページ 1200) です。 UCS-2 以外のデータベースに接続されるアプリケーションの場合、 漢字ストリング・データはアプリケーションの DBCS コード・ページにあります。 ただし、アプリケーション・コード・ページが SBCS であれば、これは許可されません。 たとえば、932 クライアントが日本語の非 UCS-2 データベースに接続されている場合、漢字ストリング・データはコード・ページ 301 になります。 UCS-2 データベースに接続された 932 クライアント・アプリケーションの場合、 漢字ストリング・データは UCS-2 に存在します。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]