この節では、アプリケーションで考慮すべき各国語サポート (NLS) による問題を説明します。主なトピックを以下に示します。
データベース・マネージャーは、照合順序 によって文字データを比較します。照合順序とは、一組の文字のうちどちらを大きくまたは小さく、あるいは等しく判断するかの順序付けです。
注: | FOR BIT DATA 属性および BLOB データで定義した文字ストリング・データは、 2 進分類順序に従って分類されます。 |
たとえば、照合順序は特定の文字の小文字と大文字を同等に判断するために使用されます。
データベース・マネージャーにより、固有の照合順序を持つデータベースの作成が可能となります。以降の節では、データベースで使用する特定の照合順序の決定と実際の使用に役立つ情報を示します。
データベースの 1 バイト文字はそれぞれ、内部では 0〜255 (16 進数表記で X'00'〜X'FF') の固有の番号で表されます。この番号を、文字のコード・ポイント といいます。ひとかたまりの文字に割り当てられた数字をコード・ページ と呼びます。照合順序は、分類後の順序列の中で各文字を配置したい位置とコード・ポイントとの間のマッピングです。位置の数値は、照合順序における文字の重み と呼ばれます。最も単純な照合順序では、コード・ポイントと重みとが同じです。これは基本順序 と呼ばれます。
たとえば、文字 B (X'42') と b (X'62') を例にとって考えてみましょう。照合順序表に従い、いずれも分類の重みが X'42' (B) である場合、これらは同様に照合されます。 B の分類の重みが X'9E' で b の分類の重みが X'9D' の場合は、 b が B の前に分類されます。実際の重みは使用する照合順序表によって決まり、照合順序表はコード・セットとロケールにより決まります。照合順序表は、コード・ポイントを定義するコード・ページ表とは異なることに注意してください。
次の例を考えてみてください。 ASCII 文字 A〜Z は X'41'〜X'5A' で表されます。照合順序を記述する場合、これらが (無関係な文字が間に入らずに) 分類されて連続する順序になっていれば、 X'41'、X'42'、... X'59'、X'5A' と記述できます。
多重バイト文字の 16 進数値もまた重みとして使用されます。たとえば、X'8260' と X'8261' は 2 バイト文字 A と B のコード・ポイントです。この場合、X'82'、X'60'、および X'61' に対する照合の重みを使って、これらの 2 つの文字をコード・ポイントに従って分類します。
照合順序における重みは、固有である必要はありません。たとえば、ある文字の大文字の文字と小文字に同じ重みを与えることができます。
照合順序によりすべての 256 コード・ポイントの重みを決めると、照合順序の指定が容易になります。各文字の重みは、その文字のコード・ポイントを使用して判別することができます。データベース・マネージャーの照合順序の指定には、この方法が用いられます。 256 バイトのストリングで n 番目のバイト (0 から始まる) には、コード・ポイント n の重みが付けられます。
すべての場合に、 DB2 はデータベース作成時に指定された照合表を使用します。コード・ポイント表に現れる順序で多重バイト文字を分類する場合は、データベースの作成時に照合順序として IDENTITY を指定しなければなりません。
注: | GRAPHIC フィールドの DBCS 文字については、分類順序は常に IDENTITY です。 |
照合順序が確定されると、2 つの文字の比較はコード・ポイント値を直接に比較する代わりに、その重みを比較することによって実行されます。
固有でない重みが使用されると、異なる文字が同じ文字として比較される場合があります。このため、ストリングの比較には次の 2 段階の処理が必要になります。
照合順序に 256 の固有の重みが含まれる場合には、最初のステップのみが実行されます。照合順序が基本順序の場合は、2 番目のステップのみが実行されます。いずれの場合もパフォーマンスが向上します。
文字比較の詳細については、 SQL 解説書 を参照してください
大文字小文字に無関係な文字比較を実行するために、 TRANSLATE 関数を使用して、大文字小文字の混在した列データを大文字に変換した上で、データを選択および比較することができます。ただし、この変換は比較の目的でのみ行われます。次のデータを例にとって考えてみましょう。
Abel abels ABEL abel ab Ab
次の SELECT ステートメントを作成したとします。
SELECT c1 FROM T1 WHERE TRANSLATE(c1) LIKE 'AB%'
すると、以下を戻します。
ab Ab abel Abel ABEL abels
"v1" ビューの作成時に、以下の SELECT ステートメントも指定し、大文字でビューを比較して、大文字小文字が混在した形で INSERT 表を要求します。
CREATE VIEW v1 AS SELECT TRANSLATE(c1) FROM T1
データベース・レベルで、 sqlecrea (データベースの作成 API) の一部として照合順序を設定することができます。これにより、"a" を "A" より前に処理するか、"A" を "a" の後に処理するか、またはどちらも同じ重みで処理するかを決定することができます。同じ重みを持たせるならば、ORDER BY 文節を使用して照合または分類するときに、等しく処理されます。 "A" と "a" はすべてのセンスで等しいため、 "A" は常に "a" の前に処理されます。分類するときの唯一の基準は 16 進値です。
そのため、次のように入力すると
SELECT c1 FROM T1 WHERE c1 LIKE 'ab%'
以下を戻します。
ab abel abels
また、次のように入力すると
SELECT c1 FROM T1 WHERE c1 LIKE 'A%'
以下を戻します。
Abel Ab ABEL
次のステートメントは、
SELECT c1 FROM T1 ORDER BY c1
以下を戻します。
ab Ab abel Abel ABEL abels
したがって、sqlecrea だけでなく、スカラー関数 TRANSLATE() を使用することもできます。ただし、照合順序を指定できるのは、sqlecrea だけであることに注意してください。コマンド行プロセッサー (CLP) から照合順序を指定することはできません。 TRANSLATE() 関数については、 SQL 解説書 を参照してください。 sqlecrea の詳細については、 管理 API 解説書 を参照してください。
次のように UCASE 関数を使用することもできます。ただし、この場合 DB2 は選択に索引を使用するのではなく、表走査を実行することに注意してください。
SELECT * FROM EMP WHERE UCASE(JOB) = 'NURSE'
データベース内のデータを分類する順序は、そのデータベースに定義した照合順序によって決まります。たとえば、データベース A は EBCDIC コード・ページの省略時の照合順序を使用し、データベース B は ASCII コード・ページの省略時の照合順序を使用すると仮定します。これら 2 つのデータベースの分類順序には、以下の 図 19 で示すような違いがあります。
図 19. EBCDIC ベースの順序における分類順序と ASCII ベースの順序における分類順序の相違例
SELECT..... ORDER BY COL2 EBCDIC-Based Sort ASCII-Based Sort COL2 COL2 ---- ---- V1G 7AB Y2W V1G 7AB Y2W |
同様に、データベースでの文字比較は、そのデータベースに定義した照合順序によって決まります。それで、データベース A が EBCDIC コード・ページの省略時の照合順序を使用し、データベース B は ASCII コード・ページの省略時の照合順序を使用する場合、その 2 つのデータベースにおける文字比較の結果は異なります。 図 20 で、その違いについて示します。
図 20. EBCDIC ベースの順序における文字比較と ASCII ベースの順序における文字比較の相違例
SELECT..... WHERE COL2 > 'TT3' EBCDIC-Based Results ASCII-Based Results COL2 COL2 ---- ---- TW4 TW4 X72 X72 39G |
連合データベースを作成する場合には、ユーザーの照合順序がデータ・ソースでの照合順序と一致するよう指定してください。こうすると、"後入れ先出し" の機会が最大になるため、照会のパフォーマンスは可能な限り増大します。後入れ先出しの分析と照会パフォーマンスの関係について詳しくは、 管理の手引き: インプリメンテーション を参照してください。
データベースの照合順序は、データベースの作成時に指定されます。いったんデータベースを作成してしまうと、照合順序は変更できません。
CREATE DATABASE API は、データベース記述子ブロック (SQLEDBDESC) と呼ばれるデータ構造を受け入れます。この構造内では、ユーザー独自の照合順序を定義できます。
データベースの照合順序の指定は次のように行ってください。
SQLEDBDESC 構造には次のものが含まれています。
注: | これらの定数は、SQLENV インクルード・ファイルに定義されています。 |
省略時に使用されるワークステーションの照合順序ではなく、 EBCDIC 照合順序を使用したデータベースを作成しやすくするためのいくつかのサンプルが (インクルード・ファイルとして) 提供されています。
これらのインクルード・ファイルでの照合順序は、 SQLEDBDESC 構造の SQLDBUDC フィールドに指定することができます。これらの照合順序は、別の照合順序の構造のモデルとしても使うことができます。
照合順序を含むインクルード・ファイルについての詳しい説明は、次の節を参照してください。
アプリケーションのコード・ページ は、データベース接続時の活動環境から導出されます。 DB2CODEPAGE レジストリー変数が設定されていれば、その値がアプリケーションのコード・ページとなります。ただし、DB2 はオペレーティング・システムから適当なコード・ページ値を決定するため、必ずしもレジストリー変数 DB2CODEPAGE を設定する必要はありません。 DB2CODEPAGE レジストリー変数を誤った値に設定すると、予測できない結果が生じる場合があります。
データベースのコード・ページ は、データベースの作成時に指定される (明示的にまたは省略時値により) 値から取得されます。以下は、さまざまな操作環境において活動環境 が定められる方法を定義したものです。
コード・ページ値の環境マッピングの完全なリストは、 管理の手引き を参照してください。
ロケールの設定は、Windows と UNIX ベースでそれぞれ異なります。 UNIX ベースのシステムでは 2 つのロケールがあります。
Windows では、「コントロール パネル」の「地域の設定」で国別設定ができます。ただし、UNIX ベースのシステムのような環境ロケールはありません。
プログラムは、開始されると省略時の C ロケールを取得します。環境ロケールのコピーは取得しません。 プログラム・ロケールを "C" 以外のいずれかに設定すると、 DB2 ユニバーサル・データベースは現行のプログラム・ロケールを使用して、アプリケーション環境のコード・ページおよびテリトリー設定を決定します。そうでない場合は、これらの値はオペレーティング・システム環境から得られます。 setlocale() はスレッド・セーフではないため、 setlocale() をアプリケーション内から出すと、プロセス全体に新しいロケールが設定されることに注意してください。
UNIX ベースのシステムでは、DB2 で使用される活動ロケールはロケールの LC_CTYPE 部分によって決定されます。詳細については、ご使用のオペレーティング・システムに対応する NLS の資料を参照してください。
静的 SQL ステートメント中の定数文字ストリングは、バインド時にアプリケーションのコード・ページからデータベースのコード・ページに変換され、このデータベースのコード・ページの表現形式で実行時に使用されます。このような変換が適切でない場合にそれを避けるには、ストリング定数の代わりにホスト変数を使用できます。
プログラムに固定文字ストリングが含まれる場合、同じコード・ページを使用して、アプリケーションをプリコンパイル、バインド、コンパイル、および実行することを強くお勧めします。 Unicode データベースの場合には、ストリング定数の代わりにホスト変数を使用する必要があります。これは、バインド段階と実行段階のいずれにおいても、サーバーによるデータ変換が行われる可能性があるためです。プログラムの中で固定文字ストリングが使われている場合には、この点に注意する必要があります。これらの組み込みストリングは、バインド実行時に、そのバインド・フェーズで有効であるコード・ページに基づいて変換されます。 7 ビット ASCII 文字は DB2 ユニバーサル・データベースのサポートするすべてのコード・ページで共通なので、問題は発生しません。非 ASCII 文字については、バインドと実行において、同一の変換表が同一のコード・ページを用いて使用されているかどうか確認してください。アプリケーションが活動コード・ページを決定する方法の説明については、 コード・ページ値の導出を参照してください。
アプリケーションが取得する外部データは、アプリケーションのコード・ページに存在すると想定されます。これには、ファイルやユーザー入力から得られるデータも含まれます。アプリケーション以外のソースからのデータが、アプリケーションと同じコード・ページを使用していることを確認してください。
C または C++ のアプリケーションでグラフィック・データを使用するホスト変数を使用する場合は、特殊なプリコンパイラー、アプリケーション・パフォーマンス、アプリケーション設計を考慮する必要があります。これらの考慮事項の詳細については、 C および C++ でのグラフィック・ホスト変数の処理を参照してください。アプリケーションで EUC コード・セットを処理する場合は、 日本語および中国語 (繁体字) EUC および UCS-2 コード・セットに関する考慮事項を参照し、そこに示されている指針を考慮してください。
SQL ステートメントのコーディングは言語に依存していません。 SQL キーワードは大文字、小文字、またはそれらが混在した形で入力できますが、いずれも本書に示されているとおりに入力しなければなりません。 SQL ステートメントにおけるデータベース・オブジェクト名、ホスト変数、およびプログラム・ラベルには、コード・ページによりサポートされる拡張文字セット以外の文字は含めることはできません。外字セットの詳細については、 SQL 解説書 を参照してください
サーバーはファイル名を変換しません。ファイル名をコーディングするには、ASCII 不変セットを使用するか、またはファイル・システムに物理的に保管される 16 進数値でパスを指定します。
複数バイト環境では、不変文字セットに属さない特殊な文字が 4 つあります。それらは次の 4 つです。
以下の表は、上記 4 つの文字の各コード・ポイントをコード・ページごとに示したものです。
コード・ページ | 2 バイトパーセント記号 | 2 バイト下線記号 | 2 バイト空白文字 | 2 バイト置換文字 |
---|---|---|---|---|
932 | X'8193' | X'8151' | X'8140' | X'FCFC' |
938 | X'8193' | X'8151' | X'8140' | X'FCFC' |
942 | X'8193' | X'8151' | X'8140' | X'FCFC' |
943 | X'8193' | X'8151' | X'8140' | X'FCFC' |
948 | X'8193' | X'8151' | X'8140' | X'FCFC' |
949 | X'A3A5' | X'A3DF' | X'A1A1' | X'AFFE' |
950 | X'A248' | X'A1C4' | X'A140' | X'C8FE' |
954 | X'A1F3' | X'A1B2' | X'A1A1' | X'F4FE' |
964 | X'A2E8' | X'A2A5' | X'A1A1' | X'FDFE' |
970 | X'A3A5' | X'A3DF' | X'A1A1' | X'AFFE' |
1381 | X'A3A5' | X'A3DF' | X'A1A1' | X'FEFE' |
1383 | X'A3A5' | X'A3DF' | X'A1A1' | X'A1A1' |
13488 | X'FF05' | X'FF3F' | X'3000' | X'FFFD' |
UCS-2 データベースでは、GRAPHIC スペースが X'0020' であり、 CCSID 13488 に使われる "2 バイト・スペース" の X'3000' とは異なっています。 EUC データベースからのデータと UCS-2 データベースからのデータを比較する時は、この違いを考慮に入れる必要があります。 UCS-2 データベースでは、 Unicode 表示の ASCII パーセント記号と 1 つの ASCII 下線記号を使ってパターン照合を行います。 DBCS パーセント記号と DBCS 下線記号は、UCS-2 データベースでは特別な意味がありません。 DBCS 置換文字が使用されるのは、EUC の非 SBCS 文字を置き換える必要がある場合です。 3 ないし 4 バイトの置換文字という概念はありません。
リモートに実行されるストアード・プロシージャーをコーディングする場合は、次の考慮が必要です。
省略時設定では、DB2 DARI ストアード・プロシージャーと UDF を呼び出すと、それらは省略時の各国語環境で実行します。これは、データベースの各国語環境と一致しない場合があります。その結果、C wchar_t 図形ホスト変数や関数など、国またはコード・ページに特有の操作を使用すると、期待どおりに作動しないことがあります。ストアード・プロシージャーまたは UDF の呼び出し時には、必ず適切な環境 (適用される場合) が初期化されるようにする必要があります。
パッケージ名は、PRECOMPILE PROGRAM コマンドまたは API の呼び出し時に判別されます。省略時設定では、パッケージ名はアプリケーション・プログラムのソース・ファイルの最初の 8 バイト (ファイル拡張子は除く) に基づいて生成され、大文字で表示されます。任意に、名前を明示的に定義することができます。パッケージ名の由来とは無関係に、異なるコード・ページ環境で実行している場合、パッケージ名の文字が不変の文字セットを使用するようにしなければなりません。そうでないと、パッケージ名の修正に伴って、問題が発生することがあります。データベース・マネージャーがアプリケーションのパッケージを検出することができないか、または、クライアント側のツールがパッケージの正確な名前を表示しないということが生じます。
パッケージ名の文字のいずれかが、データベースのコード・ページの有効な文字に直接マッピングしない場合に、文字変換が理由となって、パッケージ名が修正されます。そのような場合、置換文字は変換されない文字を置き換えます。この場合の修正後には、パッケージ名がアプリケーションのコード・ページに戻されても、元のパッケージ名と一致しなくなることがあります。この振る舞いが望ましくない例としては、 DB2 データベース・ディレクターを使用してパッケージをリストしたり、その処理を行ったりする場合です。表示されるパッケージ名が、予期している名前と一致しないことがあります。
パッケージ名の変換問題を回避するには、アプリケーションとデータベースの双方のコード・ページで有効な文字だけを使用することです。
プリコンパイル / バインド時には、プリコンパイラーが実行中のアプリケーションとなります。プリコンパイルの要求に先立つデータベース接続のさいの活動コード・ページは、プリコンパイル済みステートメント、および SQLCA 中に戻される文字データに適用されます。
実行時は、データベース接続時のユーザー・アプリケーションの活動コード・ページが、その接続の続いている間有効となります。すべてのデータはこのコード・ページに基づいて解釈されます。これには、動的 SQL ステートメント、ユーザー入力データ、ユーザー出力データ、および SQLCA 中の文字フィールドが含まれます。
これらの指針に従わないと、予測不能な結果になる場合があります。これらの条件はデータベース・マネージャーによっては検出できないため、エラー・メッセージや警告メッセージは出されません。たとえば、C アプリケーションに、 1 つの列が C1 CHAR(20) と定義されている表 T1 に対する処理を行う次の SQL ステートメントが含まれるとします。
(0) EXEC SQL CONNECT TO GLOBALDB; (1) EXEC SQL INSERT INTO T1 VALUES ('a-constant'); strcpy(sqlstmt, "SELECT C1 FROM T1 WHERE C1='a-constant'); (2) EXEC SQL PREPARE S1 FROM :sqlstmt; Where: application code page at bind time = x application code page at execution time = y database code page = z
バインド実行時、ステートメント (1) の 'a-constant' は、コード・ページ x からコード・ページ z に変換されます。この変換は、(x>z) と示すことができます。
実行時には、ステートメント (1) が実行されると、 'a-constant' (x>z) が表に挿入されます。しかし、ステートメント (2) の WHERE 文節は 'a-constant' (y>z) で実行されます。定数のコード・ポイントが 2 つの変換 (x>z と y>z) で値が異なるものだった場合、ステートメント (2) の SELECT は、ステートメント (1) によって挿入されたデータの取り出しに失敗することがあります。
最適なパフォーマンスを得るためには、アプリケーションが常にデータベースと同じコード・ページを使用するのが理想的です。ただし、これが常に実用的または可能であるとは限りません。 DB2 製品は、アプリケーションとデータベースが異なったコード・ページを使用できるようにする文字変換をサポートします。 1 つのコード・ページの文字は、データの意味を保持するために別のコード・ページにマップされなければなりません。
文字変換は、以下のような状況において行われます。
このようなデータベース変換は、アプリケーションのコード・ページからデータベースのコード・ページに変換する場合にも、データベースのコード・ページからアプリケーションのコード・ページに変換する場合にも、データベース・サーバー・マシンにて行われます。
状況によっては、クライアント / サーバー文字変換を最小化したり除去することさえできる場合があります。
Windows ODBC アプリケーションを Windows データベース・クライアント内の IBM DB2 ODBC ドライバーとともに使用する場合は、 odbc.ini または db2cli.ini ファイル内で TRANSLATEDLL および TRANSLATEOPTION キーワードを使用することによってこの問題が解決される場合があります。
注: | DB2 (OS/2 版) バージョン 1.0 およびバージョン 1.2 データベース・サーバーは、異なるコード・ページ間での文字変換をサポートしません。サーバーとクライアントでのコード・ページが矛盾していないかを確認してください。サポートされているコード・ページの変換については、 管理の手引き を参照してください。 |
このデータ変換は、クライアントがデータベース・サーバーにアクセスする前に、データベース・クライアント・マシンで行われます。そのアプリケーションがデータベースのコード・ページとは異なったコード・ページで作動している場合には、さらに別のデータ変換が行われます (前述のもの)。
データ変換が行われる場合は、これはインポート・ユーティリティーの呼び出し方によっても異なります。詳細については、 管理の手引き を参照してください。
以下の状況では、文字変換は行われません。
アプリケーションがあるコードから別のコードに変換されるとき、ターゲットのコード・ページで 1 つまたは複数の文字が表示されなくなる場合もあります。このことが生じた場合、DB2 はターゲット・ストリング内の表示されない文字の位置に、 置換 文字を挿入します。この置換文字は、その後、ストリングの有効な部分とみなされます。置換が行われた場合には、SQLCA の SQLWARN10 標識が 'W' に設定されます。
注: | WCHARTYPE CONVERT プリコンパイル・オプションを使用した場合、置換が行われても、その文字に警告のフラグが付けられることはありません。 |
データ変換が発生する場合、ソース・コード・ページから ターゲット・コード・ページへの変換が行われます。
ソース・コード・ページは、データのソースにより決定されます。アプリケーションのデータは、アプリケーションのコード・ページと同じソース・コード・ページを持ち、データベースからのデータはデータベースのコード・ページと同じソース・コード・ページを持ちます。
ターゲット・コード・ページの決定はより複雑で、最終的にデータが配置される場所だけでなく、中間操作の規則も考慮されます。
変換のステップが 2 つ発生する可能性がある場合は注意が必要です。文字データが失われる可能性をなくすためには、必ず管理の手引き にリストされているサポートされる文字変換に従ってください。さらに、各グループ内で、ソースとターゲットの両方のコード・ページに存在する文字だけに、有効な変換が行われます。他の文字は、"代入" として使用され、ターゲット・コード・ページからソース・コード・ページに戻されるときにのみ意味を持ちます (必ずしも上記の 2 つのステップの変換プロセスによって無意味な変換が行われるとは限りません)。アプリケーションのコード・ページがデータベースのコード・ページと同じであれば、そのような問題は防げます。
DB2 ユニバーサル・データベースでサポートされているコード・ページのリストについては、 管理の手引き を参照してください。 "グループ" という見出しの下に示されている値によって、どこで変換がサポートされるかを判別できます。コード・ページは、同じ IBM 定義言語グループにリストされている任意のコード・ページにも変換できます。たとえば、コード・ページ 437 は、37、819、850、1051、1252、または 1275 に変換することができます。
注: | 複数バイト・コード・ページどうしで文字ストリング変換 (たとえば、DBCS と EUC) が行われる場合、ストリングの長さが変化する可能性があります。 |
アプリケーションが DB2 データベース・サーバーへの接続を正常に完了したならば、戻された SQLCA の次のフィールドを調べる必要があります。
グラフィック・ストリング・データについての考慮事項は、コード・ページが異なる状況には当てはまりません。このようなストリングのおのおのの長さは、データがアプリケーションのコード・ページであるかデータベースのコード・ページであるかに関係なく、常に同じ文字数になります。
コード・ページが異なる場合の処理については、 コード・ページが異なる場合の状況を参照してください。
結合した 1 バイト文字セット (SBCS) または 2 バイト文字セット (DBCS) の各コード・ページでは、
1 バイト文字と 2 バイト文字の両方のコード・ポイントを使用できます。このことは、通常は 2 バイトのコード・ポイントの最初のバイトに対して未定義のコード・ポイントまたは割り当て済みのコード・ポイントのいずれかの剰余分と一緒に、単一バイト文字が混合しているコード表の 256 使用可能コード・ポイントのサブセットを予約することにより行います。以下の表で、これらのコード・ポイントについて示します。
国 | サポートされている混合コード・ページ | 単一バイト文字のコード・ポイント | 2 バイト文字の最初のバイトのコード・ポイント | ||
---|---|---|---|---|---|
日本 | 932、943 | x00-7F、xA1-DF | x81-9F、xE0-FC | ||
日本 | 942 | x00-80、xA0-DF、 xFD-FF | x81-9F、xE0-FC | ||
台湾 | 938 (*) | x00-7E | x81-FC | ||
台湾 | 948 (*) | x00-80、FD、FE | x81-FC | ||
韓国 | 949 | x00-7F | x8F-FE | ||
台湾 | 950 | x00-7E | x81-FE | ||
中国 | 1381 | x00-7F | x8C-FE | ||
韓国 | 1363 | x00-7F | x81-FE | ||
中国 | 1386 | x00 | x81-FE | ||
|
こうした区分のどこにも割り当てられていないコード・ポイントは定義されていません。それは、単一バイトの未定義のコード・ポイントとして処理されます。
暗黙の DBCS コード表ごとに、有効な最初のバイトの 2 番目のバイトとしてそれぞれ利用できる 256 のコード・ポイントがあります。 2 番目のバイト値は、0x40 から 0x7E、および 0x80 から 0xFE までの任意の値にすることができます。 DBCS 環境では、DB2 が個々の 2 バイト文字に対して妥当性検査を行うことはありませんのでご注意ください。
EUC コード・ページはそれぞれ、1 バイト文字のコード・ポイントと、最大 3 つの異なるマルチバイト文字のコード・ポイント・セットを両方とも使用することができます。このことは、それぞれの暗黙の 1 バイト文字 SBCS コード・ページ識別子で利用可能な 256 のコード・ポイントのサブセットを予約することにより行います。コード・ポイントの剰余分は未定義であったり、マルチバイト文字の要素として割り当てられたり、マルチバイト文字の単一シフト接頭部として割り当てられたりします。以下の表で、これらのコード・ポイントについて示します。
グループ | 1 番目のバイト | 2 番目のバイト | 3 番目のバイト | 4 番目のバイト |
---|---|---|---|---|
G0 | x20-7E | n/a | n/a | n/a |
G1 | xA1-FE | xA1-FE | n/a | n/a |
G2 | x8E | xA1-FE | n/a | n/a |
G3 | x8E | xA1-FE | xA1-FE | n/a |
グループ | 1 番目のバイト | 2 番目のバイト | 3 番目のバイト | 4 番目のバイト |
---|---|---|---|---|
G0 | x20-7E | n/a | n/a | n/a |
G1 | xA1-FE | xA1-FE | n/a | n/a |
G2 | n/a | n/a | n/a | n/a |
G3 | n/a | n/a | n/a | n/a |
グループ | 1 番目のバイト | 2 番目のバイト | 3 番目のバイト | 4 番目のバイト |
---|---|---|---|---|
G0 | x20-7E | n/a | n/a | n/a |
G1 | xA1-FE | xA1-FE | n/a | n/a |
G2 | x8E | xA1-FE | xA1-FE | xA1-FE |
G3 | n/a | n/a | n/a | n/a |
グループ | 1 番目のバイト | 2 番目のバイト | 3 番目のバイト | 4 番目のバイト |
---|---|---|---|---|
G0 | x20-7E | n/a | n/a | n/a |
G1 | xA1-FE | xA1-FE | n/a | n/a |
G2 | n/a | n/a | n/a | n/a |
G3 | n/a | n/a | n/a | n/a |
こうした区分のどこにも割り当てられていないコード・ポイントは定義されていません。それは、単一バイトの未定義のコード・ポイントとして処理されます。
DB2 ユニバーサル・データベースに 2 バイト文字セット (DBCS) 環境でアクセスする Java プログラムの実行方法については、
DB2 Java - DBCS Support を参照してください。上記の Web ページには、現在のところ以下の情報が記載されています。
JDBC および SQLJ プログラムは、DB2 CLI/ODBC ドライバーを使用して DB2 にアクセスするので、これらのプログラムは同一の構成ファイル (db2cli.ini) を使用します。 DBCS 環境で DB2 ユニバーサル・データベースにアクセスする Java プログラムを実行する場合には、この構成ファイルに以下のような項目を追加する必要があります。
注: |
これらのキーワードの設定方法については、インストールおよび構成 補足 を参照してください。 |
拡張 UNIX コード (EUC) とは、UNIX 系の操作環境において 1 つないし 4 つまでの文字セットをサポートできる一連のコード化規則のことを言います。このコード化規則は、制御文字が文字セットの一部を分離させるために使用される、 7 ビットおよび 8 ビット・データをコード化するための ISO 2022 定義に基づいています。しかし EUC は、コード・セットのコード化スキーマではなく、コード・ページの集合を指定する手段です。 EUC に基づくコード・セットは、基本的には EUC コード化規則に従いますが、固有のインスタンスに関連付けられた固有の文字セットをも識別します。たとえば、日本語用である IBM-eucJP コード・セットは、 EUC コード化規則に従って日本工業規格文字のコード化も参照します。サポートされるコード・ページの一覧は、ご使用のプラットフォームの概説およびインストール を参照してください。
図形 (つまり 2 バイト文字) データに対するデータベースおよびクライアント・アプリケーション・サポートは、長さが 2 バイト以上の文字コード化を使用する EUC コード・ページで実行される場合、制限されてしまいます。 DB2 ユニバーサル・データベース製品は、すべての文字が 2 バイト幅でなければならないという厳密な規則をグラフィック・データに適用します。このような規則のために、日本語および中国語 (繁体字) EUC コード・ページからはほとんどの文字が使用できません。このような状況の解決を目的として、日本語および中国語 (繁体字) EUC グラフィック・データを表示するためのサポートが、アプリケーション・レベルとデータベース・レベルの双方で備えられました。このサポートでは、まったく別個のコード化スキーマを使用します。
日本語もしくは中国語 (繁体字) EUC コード・ページで作成されたデータベースでは、グラフィック・データの保管および操作が ISO 10646 UCS-2 コード・セットによって行われます。このコード・セットは、完全な ISO 10646 標準規格の適格なサブセットの一つといえる 2 バイトのコード化スキーマです。これと同様に、このコード・ページで実行されるアプリケーションは、グラフィック・データを UCS-2 コード化データとしてデータベース・サーバーに送信します。このサポートにより、EUC コード・ページで実行されるアプリケーションでも、 DBCS コード・ページで実行されるアプリケーションであるかのように同じタイプのデータにアクセスすることが可能になります。 EUC 環境に関する追加情報は、SQL 解説書 を参照してください。 UCS-2 に関連付けられた IBM 定義のコード・ページ識別子は 1200 で、同じコード・ページの CCSID 番号は 13488 です。 eucJP または eucTW データベースのグラフィック・データは、CCSID 番号 13488 を使用します。 UCS-2 データベースでは、グラフィック・データに対してコード・ページ番号 1200 を使用してください。
ISO 10646 標準規格では、インド語、タイ語、アラビア語、ヘブライ語など、さまざまなスクリプトで必要となる結合 文字のコード化を指定します。このような文字は、ラテン、キリル、およびギリシャ語の文字を生成するためにも使用されます。ただし、このような文字が存在する場合、同じテキストを表すのに代わりのコーディングが用いられる可能性もあります。たとえコーディングが確実なものでデータ生成が予約されていても、テキストに結合文字が含まれていると、その処理は含まれていないときよりも複雑なものになります。結合文字の処理を行わないことにしたアプリケーションを一致できるようにするため、 ISO 10646 では 3 つのインプリメンテーション・レベルが定義されています。
DB2 ユニバーサル・データベースは、結合文字を含む UCS-2 文字の全セットをサポートしますが、それらの文字を構成したり分解したりすることはしません。 Unicode 標準の詳細については、Addison-Wesley による Unicode Standard Version 2.0 を参照してください。 UCS-2 の詳細については、国際標準化機構規格の ISO/IEC 10646-1 を参照してください。
これらの文字セットを使用するアプリケーションまたはデータベースを処理する場合には、 UCS-2 コード化データの処理を考慮する必要があります。 UCS-2 グラフィック・データをアプリケーションの EUC コード・ページに変換すると、データ長が大きくなる可能性があります。データ拡張の詳細については、 文字変換の拡張係数を参照してください。また、大量のデータを表示しようとする場合、バッファーを割り振ったり、 1 連の断片化にあるデータを変換および表示したりする必要の生じる場合があります。
以下の節では、そのような環境内にあるデータを処理する方法について説明します。以下の節の中では、EUC という用語が、日本語および中国語 (繁体字) EUC 文字セットだけを指して用いられています。以下の節の説明は、DB2 韓国語または中国語 (簡体字) EUC サポートにはあてはまりません。これら 2 つの文字セットのグラフィック・データは EUC コード化によって表示されるからです。
EUC および 2 バイトが混在しているコード・ページ環境にあるデータベース・ オブジェクトは、クライアントおよびデータベースのコード・ページ間で変換するために、オブジェクト名の長さが拡張または縮小することがあり、管理が複雑になります。特に、管理コマンドおよびユーティリティーの多くは、入力または出力パラメーターとして使用する文字ストリングの長さに限界を設けて明示しています。これらの限界は、特に明示されていなければ、一般にクライアント側にも適用されます。たとえば、表名の限界は 128 バイトです。 2 バイト・コード・ページでは 128 バイトの文字ストリングが、 EUC コード・ページではもっと長く、たとえば 135 バイトとなることがあります。この 135 バイトの表名は、宛先の 2 バイト・データベースでは有効であっても、 REORGANIZE TABLE などのコマンドで入力パラメーターとして使用すると、無効とみなされます。同様に、データベースのコード・ページからアプリケーションのコード・ページへ変換した後、出力パラメーターに許可される最大長を超えてしまうことがあります。これは、変換エラーまたは出力データの切り捨てのいずれかの原因となります。
EUC と 2 バイト文字が混在している環境で管理コマンドおよびユーティリティーをよく使用する場合は、データベース・オブジェクトおよびその関連データを、サポートされる限界より長く定義する必要があります。 2 バイト・クライアントから EUC データベースを管理する場合は、 EUC クライアントから 2 バイト・データベースを管理するよりも、制限が少なくなります。 2 バイト文字ストリングの長さは常に、対応する EUC 文字ストリングの長さ以下となります。これは一般に、文字ストリング長の限界を適用するよりも、問題が少なくてすみます。
注: | SQL ステートメントの場合、入力パラメーターの妥当性検査は、ステートメント全体がデータベースのコード・ページに変換されるまで、実施されません。したがって、クライアントのコード・ページで表すときには、技術的に許可されるよりも長い文字ストリングを使用することができます。ただし、それはデータベースのコード・ページで表すときには、長さの要件に適合する必要があります。 |
中国語 (繁体字) の標準定義のため、2 バイトまたは EUC コード・ページと UCS-2 との間で、ある種の文字を変換する際に、副次作用が発生することがあります。変換した場合に、コード・セットの別の文字と同じ UCS-2 コード・ポイントを共用する文字が 189 文字 (187 の部首および 2 つの数字) あります。これらの文字を 2 バイトまたは EUC に戻すと、元のコード・ポイントではなく、同じ UCS-2 コード・ポイントを共用する同じ漢字のコード・ポイントに変換されます。表示された文字は同じように見えますが、実はコード・ポイントが異なっています。アプリケーションの設計によっては、この振る舞いを考慮に入れなければならないことがあります。
例として、EUC コード・ページ 964 のコード・ポイント A7A1 を UCS-2 に変換した後、元のコード・ページ EUC 946 に戻した場合にどうなるかを考えてみましょう。
上図のように、コード・ポイント A7A1 および C4A1 は、変換後、コード・ポイント C4A1 になります。
EUC コード・ページ 946 (中国語 (繁体字) EUC) または 950 (中国語 (繁体字) Big-5 ) と UCS-2 とのコード・ページ変換表が必要であれば、 製品およびサービス技術ライブラリーのホーム・ページを参照してください。
EUC アプリケーションを開発するにあたっては、次の事柄を考慮する必要があります。
ストアード・プロシージャーに関する追加の考慮事項については、 ストアード・プロシージャーに関する考慮事項を参照してください。言語固有のアプリケーション開発に関する考慮事項については、次の箇所で説明しています。
この節では、グラフィック・データの処理を目的とした、EUC アプリケーション開発の考慮事項について説明します。この節では、グラフィック定数の処理について、また UDF 内のグラフィック・データ、ストアード・プロシージャー、 DBCLOB ファイルの処理について、さらには照合についても説明します。
グラフィック定数 (すなわちリテラル) は、混合文字データとして分類され、SQL ステートメントの一部ともなります。日本語または中国語 (繁体字) EUC クライアントからの SQL ステートメント内のグラフィック定数は、データベース・サーバーによってコード化された図形に、暗黙に変換されます。 EUC コード化文字を構成する図形リテラルであれば、 SQL アプリケーション内で使用することができます。そのようなリテラルは、EUC データベース・サーバーによってグラフィック・データベース・コード・セットに変換され、UCS-2 になります。 EUC クライアントからのグラフィック定数には、CS0 7 ビット ASCII 文字や日本語 EUC CS2 (カタカナ) 文字などの、単一幅の文字を絶対に含めないでください。
グラフィック定数の追加情報については、 SQL 解説書 を参照してください。
UDF は、データベース・サーバーで呼び出される、データベースと同じコード・セットでコード化されたデータを処理する手段です。日本語または中国語 (繁体字) コード・セットで実行されるデータベースの場合は、そのデータベースを作成する EUC コード・セットによって、混合文字データがコード化されます。グラフィック・データは UCS-2 によってコード化されます。このことは、UCS-2 によってコード化されるグラフィック・データを UDF は認識し処理する必要があることを意味します。
たとえば、グラフィック・ストリングを混合文字ストリングに変換する VARCHAR という UDF を作成したとします。この場合 VARCHAR 関数は、データベースが EUC コード・セットで作成されているのであれば、 UCS-2 としてコード化されたグラフィック・ストリングを EUC 表記に変換しなければなりません。
日本語または中国語 (繁体字) EUC コード・セットで実行されるストアード・プロシージャーは、 UCS-2 によってコード化されたグラフィック・データを認識および処理できるよう準備しなければなりません。そのようなコード・セットを実行する場合、ストアード・プロシージャーの入力 / 出力 SQLDA によって送受信したグラフィック・データは、UCS-2 を使用してコード化します。
DBCLOB ファイルに関して 2 つの重要な考慮事項があります。
グラフィック・データは 2 進順序で分類されます。混合データは各バイトに適用されるデータベースの照合順序で分類されます。分類順序については、 SQL 解説書 を参照してください。同一国用であっても EUC コード・セットの場合と DBCS コード・セットの場合では文字を順序付ける仕方に違いがあるため、同じデータであっても EUC データベース内のデータを分類する場合と DBCS データベース内のデータを分類する場合とでは異なる結果が生じる可能性があります。
EUC と DBCS が混在している環境でアプリケーションを開発する場合、状況によってはデータ長の増減が生じます。この節ではそのような場合の考慮事項について、次に示すトピックに分けて取り扱っています。
アプリケーションのコード・ページやデータベースのコード・ページが使用する文字コード化スキーマによっては、ソース・コード・ページからターゲット・コード・ページに変換される際に、ストリングのデータ長が変わる可能性があります。このようなデータ長の変化は、多くの場合、異なるコード化スキーマ (たとえば DBCS と EUC) を使用する多重バイト・コード・ページ間での変換に起因します。
ほとんどの場合、データ長が短くなるよりもデータ長が長くなる方が多くのあるいは深刻な問題が生じます。それは、メモリーの割り振りに余裕がある方が不足するよりも当然勝っているからです。データ長拡張の可能性があるかどうかによっては、データの送信や取り出しに関するアプリケーションの考慮事項を別個に扱う必要が生じます。さらに、データ長の拡張または縮小が見られそうな場合の最善 状況と最悪 状況の違いに注意することも重要です。正の値 (拡張の可能性を示す) は、 最悪 状況を乗算係数で示します。たとえば、SQLERRD(1) または SQLERRD(2) フィールドに 2 の値が示された場合、それは変換後のデータの処理に記憶域のストリング長が変換前の最大 2 倍必要になることを意味します。これが最悪 標識です。この例で最善 の状況とは、変換後もデータ長が変わらないことです。
SQLERRD(1) または SQLERRD(2) に負の値 (縮小の可能性を示す) が示される場合も、同様の最悪 拡張係数を表します。たとえば、値 -1 は必要となる記憶域の最大値が変換前のストリング長と同じであることを示します。負の値によって、記憶域のサイズが変換前よりも小さくてよいことが示される場合もありますが、受信側のアプリケーションがソース・データの構造をはじめから識別しているのでないかぎり、負の値がそのような状況を示すために使われることはほとんどありません。
変換後に拡張が行われても大丈夫なよう十分な量の記憶域を割り振るためには、値 max_target_length と同量の記憶域を割り振るようにしてください。この値は次のような計算から得られます。
アプリケーションからデータベースにデータを転送する場合
expansion_factor = ABS[SQLERRD(1)] if expansion_factor = 0 expansion_factor = 1
データベースからアプリケーションにデータを転送する場合
expansion_factor = ABS[SQLERRD(2)] if expansion_factor = 0 expansion_factor = 1
上記の計算において、ABS は絶対値を参照しています。
expansion_factor = 0 の検査は不可欠です。というのは、DB2 ユニバーサル・データベース製品の中には SQLERRD(1) および SQLERRD(2) に 0 を戻すものがあるからです。そのようなサーバーでは、データの拡張または縮小が生じるようなコード・ページの変換をサポートしていません。このことは拡張係数 1 によって示されます。
temp_target_length = actual_source_length * expansion_factor
(1) if temp_target_length < actual_source_length max_target_length = type_maximum_length else (2) if temp_target_length > type_maximum_length max_target_length = type_maximum_length else (3) max_target_length = temp_target_length
長さの計算中に生じるかもしれない桁あふれを許容するには、上記のチェックのすべてが必要になります。それぞれのチェックを以下に詳しく説明します。
2 つの正の値を乗算した結果がデータ・タイプの最大値を超えてしまう場合、 行が折り返され、2 つの値のうちの大きい方に満たない分の値が返されます。
たとえば、2 バイト符号付き整数 (CLOB 以外のデータ・タイプの長さに使用される) の最大値は 32 767 です。仮に actual_source_length が 25 000 で拡張係数が 2 であるとすると、 temp_target_length は当然のことながら 50 000 になります。 2 バイト符号付き整数にこの値では大きすぎるので、行は折り返され、値 -15 536 が返されます。
CLOB データ・タイプの場合には、4 バイト符号付き整数が長さに使用されます。 4 バイト符号付き整数の最大値は 2 147 483 647 です。
データ・タイプをステップ 3 にリストされた値よりも長くすることはできません。
変換によって、そのデータ・タイプで認められている以上のスペースが必要とされる場合には、より大きなデータ・タイプを使用すれば結果を保持できるようになるかもしれません。たとえば、CHAR(250) 値が変換後のストリングの保持に 500 バイトを必要とする場合、 CHAR 値の最大長は 254 バイトなのでそのストリングを保持することはできません。しかし、VARCHAR(500) を使用すれば、そのストリングを変換後も保持できます。詳細については、 文字変換によりデータ・タイプの限界を超える場合を参照してください。
データベースへの接続時に返された SQLERRD(1) および SQLERRD(2) 値と上記の計算を基にして、文字変換後にはストリングの長さがどうなるかを判別できます。一般に、0 または 1 の値は、長さが変わらないことを示し、1 より大きい値は長さが長くなることを、負の値は切り捨てが生じることを示します。
('0' の値が示されるのは下位の DB2 ユニバーサル・データベース製品からだけであることに注意してください。)
さらに、これらの値は他のデータベース・サーバー製品では定義されていないことにも注意してください。
表 25 には、DB2 ユニバーサル・データベースを使用した場合のさまざまなアプリケーション・コード・ページとデータベース・コード・ページの組み合わせにおける理想的な値が示されています。
表 25. CONNECT 時の SQLCA.SQLERRD 設定値
SQLERRD(1) 項目にデータベース・サーバーでの拡張が示された場合、アプリケーションの側では、クライアントでは有効だった長さ依存の文字データがデータベース・サーバーにおいては変換の影響で無効になる可能性はないかについて考慮する必要が生じます。たとえば、DB2 製品では、列名の長さが 128 バイト以下でなければなりません。しかし、文字ストリングが DBCS コード・ページによって 128 バイトの長さでコード化されていても、EUC コード・ページに変換すると、この 128 バイトの制限を超えてしまう場合があります。つまり、アプリケーション・コード・ページとデータベース・コード・ページとが同じだったときには有効だった動作でも、これらのコード・ページが異なる場合には無効になり得る、ということです。コード・ページが異なる状況下で EUC および DBCS データベースを設計する際には、これらの点に注意してください。
SQLERRD(2) 項目にクライアント・アプリケーションでの拡張が示された場合、アプリケーションの側では、長さ依存の文字データが変換後にはどの程度拡張されるかを把握する必要が生じます。たとえば、CHAR(128) 桁の行を取り出すとします。この場合、データベース・コード・ページとアプリケーション・コード・ページが同じであれば、返されるデータの長さは当然 128 バイトで問題はありません。しかし、この両者のコード・ページが異なる場合には、 DBCS コード・ページでは 128 バイトでコード化されたデータでも EUC コード・ページに変換すると 128バイトを超えてしまう可能性があります。したがって、このような場合には、ストリング全体を取り出せるようにするため、追加の記憶域を割り振る必要がでてきます。
クライアントとサーバーとの間で文字データの拡張や縮小が行われることの重大な影響の 1 つとして、クライアント・アプリケーションとデータベース・サーバーとの間で受け渡しされるデータを検証する必要が生じることが挙げられます。クライアントとサーバー間でコード・ページが異なる場合、クライアントでは有効と判断されたデータが、変換の結果、データベース・サーバーでは無効になるという状況も十分に生じ得ます。これとは反対に、クライアントでは無効だったデータが、変換の結果、データベース・サーバーで有効になるという場合もあります。
クライアントとサーバー間でコード・ページが異なる場合には、特定のエンド・ユーザー・アプリケーションや API ライブラリーであらゆる処理が行えなくなる可能性があります。さらに、一部のパラメーター (ストリング長など) はクライアントでコマンドや API によって検証されるのに対し、 SQL ステートメント内のトークンはデータベースのコード・ページに変換されるまで検証されません。その結果、コード・ページが異なる環境でも SQL ステートメントを使用してはデータベース・オブジェクト (表など) にアクセスできるのに、特定のコマンドもしくは API ではその同じオブジェクトにアクセスできないという状況が生じ得ます。
ここであるアプリケーションの例を考えてみましょう。そのアプリケーションはエンド・ユーザーが作成した表に含まれているデータを返そうとしています。その表の名前が 128 バイトよりも長くならないことに注目してください。ではさっそく、以下に示されているこのサンプル・アプリケーションのシナリオを考慮してみましょう。
EUC データベースに対して DESCRIBE を実行すると、データベース内の GRAPHIC 列の定義に基づいた、混合文字と GRAPHIC 列についての情報が返されてきます。この情報は、クライアントのコード・ページに変換される前のサーバーのコード・ページに基づいています。
アプリケーション文脈 (例: VALUES SUBSTR(?,1,2)) で解決された選択リスト項目に対して DESCRIBE を実行し、その結果文字データまたはグラフィック・データが関係していた場合、返されてくる SQLLEN 値に加えて、返されてくるコード・ページも評価してください。返されてきたコード・ページがアプリケーション・コード・ページと同じ場合、拡張は行われません。返されてきたコード・ページがデータベース・コード・ページと同じ場合は、拡張の可能性があります。 FOR BIT DATA (コード・ページ 0) である選択リスト項目やアプリケーション・コード・ページ内の選択リスト項目は、アプリケーションに返されても変換されません。したがって、報告される長さに拡張や縮小はありません。
アプリケーションのコード・ページが EUC コード・ページの場合、 DBCS コード・ページのデータベースに対して DESCRIBE を発行すると、 CHAR および GRAPHIC 列について返された情報がデータベース文脈に返されます。たとえば、 DESCRIBE の一環として返された CHAR(5) 列には、SQLLEN フィールドに 5 の値があります。 EUC 以外のデータの場合は、この列からデータを取り出すと、記憶域を 5 バイト割り振ることになります。 EUC データの場合には、このことはあてはまりません。 DBCS から EUC へのコード・ページ変換が行われると、CHAR 列の文字に使用されるコード化に違いがあるため、データ長が大きくなる可能性があります。たとえば、中国語 (繁体字) 文字セットの場合、このようなデータ拡張が最大で 2 倍になります。つまり、DBCS コード化での最大文字長が 2 バイトのとき、EUC では 4 バイトになる可能性があります。日本語コード・セットの場合も、2 倍の拡張が生じ得ます。ただ中国語の場合とは異なり、日本語 DBCS で最大文字長が 2 バイトだったものが、日本語 EUC では 3 バイトになることもあることに注意してください。このような拡張は係数 1.5 によってのみ知ることができますが、日本語 DBCS では単一バイト・カタカナ文字がたったの 1 バイトなのに対し、日本語 EUC では 2 バイトと違いがあります。最大サイズの判別に関する詳細については、 文字変換の拡張係数を参照してください。
文字変換の結果としてのデータ長の変化は、混合文字データの場合にのみ起こるものです。図形文字データのコード化は、コード化スキーマがどのようなものであろうと、常に同じ長さ、つまり 2 バイトです。データを誤って失わないようにするため、コード・ページが異なるなどの状況が存在しているかどうか、およびそれが EUC アプリケーションと DBCS データベースとの間のものであるかどうかなどについて評価する必要があります。データベース・コード・ページとアプリケーション・コード・ページがどのようなものかは、CONNECT ステートメントから返された SQLCA 内にあるトークンから判別できます。詳細については、コード・ページ値の導出または SQL 解説書 を参照してください。そのような状況が存在する場合、アプリケーションの側では、そのコード化スキーマの最大拡張係数に基づいて混合文字データ用の追加の記憶域を割り振る必要が生じます。
アプリケーション・コード・ページが DBCS コード・ページで、 DESCRIBE を EUC データベースに対して発行する場合にも、EUC アプリケーションと DBCS データベースで説明したのと同様の事柄が生じます。ただしこちらの場合には、SQLLEN フィールドの値で示されるほどの記憶域は必要とされません。この状況で最悪なケースとなるのは、すべてのデータが EUC で単一バイトまたは 2 バイトのどちらかであることです。この場合、SQLLEN に示されたのとまったく同じバイト数が DBCS コード化スキーマで必要になります。このような状況を除いては、SQLLEN で示されるよりも少ないバイト数で済みます。どの EUC 文字を保管するにも最大で 2 バイトあれば十分だからです。
DBCS コード・ページと EUC コード・ページ間での変換時に生じ得るストリング長の変化を考慮に入れると、固定長データ・タイプを使わない方が良いかもしれません。ブランク埋め込みが必要になるかどうかによっては、DESCRIBE の実行後、SQLTYPEを固定長文字ストリングから可変長文字ストリングに変更する方が良いかもしれません。たとえば、EUC と DBCS 間の接続で最大拡張係数 2 が示されている場合、 (EUC アプリケーションと DBCS データベースの例 CHAR(5) を再び使用すると) アプリケーションは 10 バイト割り振る必要があります。
SQLTYPE が固定長の場合、EUC アプリケーションは列を DBCS データ (それ自体は末尾部分の空白として 5 バイトを含めることができる) から変換された EUC データ・ストリームとして受け取ることになります。コード・ページ変換によってデータ要素がその最大サイズまで至らない場合には、これにさらにブランクが埋め込まれます。 SQLTYPE が可変長であれば、CHAR(5) 列の中身の元の意味は保ったまま、ソースの 5 バイトに 5 〜 10 バイトのターゲットを含めることができます。これと同様に、データが縮小する場合にも (DBCS アプリケーションと EUC データベース間で)、可変長データ・タイプの処理を考慮した方が良いかもしれません。
余分のスペースを割り振ったりデータ・タイプをプロモートする代わりに、データを断片化させるという方法もあります。たとえば、同じ VARCHAR(3000) を選択して変換後も 6000 バイト含められるようにするため、2 つの選択手段、すなわち SUBSTR(VC3000, 1, LENGTH(VC3000)/2) と SUBSTR(VC3000, (LENGTH(VC3000)/2)+1) を別々に実行して 2 つの VARCHAR(3000) アプリケーション域に分けることができます。このメソッドを使用できるのは、データ・タイプがもうこれ以上プロモートできないという場合です。たとえば、日本語 DBCS コード・ページでコード化され、最大長が 2 ギガバイトの CLOB では、日本語 EUC コード・ページでコード化する際、そのサイズをおそらく最大 2 回プロモートできます。言い換えると、データを断片化しなければならなくなるのは、 2 ギガバイトを超えデータ・タイプのサポートがなくなってからです。
EUC と DBCS が混在するコード・ページ環境では、ストリング全体を 1 つの列に収めきれるだけのスペースを割り振っていないと、変換後に問題が生じる場合があります。この場合、ストリング長の最大拡張は 2 倍になります。拡張が列の容量を超える場合には、SQLCODE -334 (SQLSTATE 22524) が返されます。
このような結果、次のような、すぐには明らかにならなかったり前もっては考慮できない状況に陥ります。
混合したコード・ページ環境用のアプリケーションを設計する場合、以下の状況については、 SQL 解説書 を参照してください。
上記の状況では、データベース・コード・ページではなく、アプリケーション・コード・ページに対して起こる変換を考慮しています。
EUC と DBCS が混在するコード・ページ環境では、混合文字やグラフィック・ストリングの長さがそのデータ・タイプで許可されている最大長を超えていると、変換後に問題が生じる場合があります。拡張後のストリング長がデータ・タイプの制限を超える場合、データ・タイプのプロモートは行われません。代わりに、許可されている拡張の最大値を超えたことを示すエラー・メッセージが返されます。この状況は、挿入時よりも、述部の評価中によく起こります。挿入時には、アプリケーションが容易に列幅を識別でき、最大拡張係数も容易に把握できるからです。大半の場合、文字変換のこの副次作用は、最大長がもっと長い関連データ・タイプに値をキャストすることによって、回避できます。たとえば、CHAR 値の最大長は 254 バイトなのに対し、 VARCHAR の最大値は 32672 バイトです。 拡張によってデータ・タイプの最大長を超えてしまう場合には、SQLCODE -334 (SQLSTATE 22524) が返されます。
ホスト変数に指定された混合文字データやグラフィック・データ、および sqleproc() または SQL CALL 呼び出しでの SQLDA は、アプリケーション・コード・ページとデータベース・コード・ページが異なる場合に変換が起きます。変換の結果としてストリング長の拡張が行われる場合、その拡張に対応できるだけのスペースが割り振られていないと、SQLCODE -334 (SQLSTATE 22524) が返されてしまいます。そのためストアード・プロシージャーを開発する際には、生じ得る拡張に備えて十分のスペースを割り振っておく必要があります。拡張に対応できるだけのスペースを割り振ることができるよう、可変長データ・タイプを使用するようにしてください。
前述の節、混合コード・セット環境における開発に記載されている情報は、 UCS-2 データベースにも適用できることに注目してください。
どんなコード・ページ環境のアプリケーションでも、 Unicode データベースに接続できます。 Unicode データベースに接続するアプリケーションに対して、データベース・マネージャーは、文字ストリング・データを、アプリケーション・コード・ページとデータベース・コード・ページ (UTF-8) との間で変換します。 UCS-2 データベースでは、グラフィック・データは必ず UCS-2 形式になります。しかし、コマンド行プロセッサーを使用してグラフィック・データを検索する場合には、グラフィック文字もクライアント・コード・ページに変換されます。この変換によって、コマンド行プロセッサーは、グラフィック文字を現行のフォントで表示できます。データベース・マネージャーによって UCS-2 文字がクライアント・コード・ページに変換される場合には、一部のデータが失われる可能性があります。データベース・マネージャーがクライアント・コード・ページ内の有効な文字に変換できない文字は、そのコード・ページの省略時の置換文字に変換されます。
DB2 がコード・ページからの文字を UTF-8 に変換すると、文字のコード・ページおよびコード・ポイントに応じて、その文字を表す合計のバイトの数は増減します。 UTF-8 では 7 ビット ASCII は不変です。各 ASCII 文字は 1 バイトを要します。非 ASCII UCS-2 文字は、それぞれ 2 または 3 バイトになります。 UTF-8 変換の詳細については、管理の手引き、または Unicode 標準についての文書を参照してください。
Unicode データベースに接続するアプリケーションでは、グラフィック・データはすでに Unicode モードです。 DBCS データベースに接続するアプリケーションでは、グラフィック・データは、アプリケーションの DBCS コード・ページとデータベースの DBCS コード・ページとの間で変換されます。 Unicode アプリケーション自体も、 Unicode へのまたは Unicode からの必要な変換を実行する必要があります。あるいは、グラフィック・データに対しては、 WCHARTYPE CONVERT オプションを設定して wchar_t を使用する必要があります。 このオプションの詳細については、C および C++ でのグラフィック・ホスト変数の処理を参照してください。