日本語および中国語 (繁体字) の拡張 UNIX コード (EUC) に関する考慮事項

日本語および中国語 (繁体字) 用の拡張 UNIX コード (EUC) は、1 から 4 文字セットをサポートできる一連のエンコード規則を定義します。日本語 EUC (eucJP) および中国語 (繁体字) EUC (eucTW) などのいくつかのケースでは、1 文字を 2 バイトより大きいバイト数を使用してエンコードできます。このようなコード化スキームの使用については、データベース・サーバーまたはデータベース・クライアントのコード・ページとして使用されると影響があります。主な考慮事項には、以下が含まれます。

EUC コード・ページと 2 バイト・コード・ページとの変換時の、ストリングの拡張または収縮。
eucJP (日本語) または eucTW (中国語 (繁体字)) コード・ページで定義されたデータベース・サーバー内に格納されているグラフィック・データ用のコード・ページとしての、汎用文字セット 2 (UCS-2)。

これらの考慮事項を除けば、EUC を使用しても、2 バイト文字セット (DBCS) サポートとの整合性は保たれます。 2 バイトより多いバイト数を必要とする文字表現が可能なエンコード規則のサポートを反映して、2 バイト文字 に言及している箇所は、マルチバイト文字 に変更されています。日本語および中国語 (繁体字) EUC のサポートについての詳細な考慮事項は、このセクションで記載しています。この情報は、EUC データベース・サーバーまたは EUC データベース・クライアントで SQL を使用する場合に考慮して、アプリケーション開発情報と併せて使用する必要があります。

文字

各マルチバイト文字は文字と見なされますが、例外として 2 バイトのブランク文字は特殊文字 と見なされます。

トークン

マルチバイトの英小文字は大文字に変換されません。ただし、通常は大文字に変換されるトークン中の 1 バイトの英小文字は例外です。

SQL ID

2 バイトのコード・ページと EUC コード・ページとの間の変換により、2 バイト文字を 2 バイトより大きいバイト数でエンコードされるマルチバイト文字に変換できます。その結果、2 バイトのコード・ページの最大長に合う ID が、EUC コード・ページの長さを超えることがあります。このタイプの環境の ID は慎重に選択し、ID の最大長を超えないようにする必要があります。

文字ストリング

MBCS データベースでは、文字ストリングには 1 バイト文字セット (SBCS) とマルチバイト文字セット (MBCS) の文字が混合して入る場合があります。そのようなストリングを使用する場合、それらが文字ベース (データを文字単位で処理) であるか、またはバイト・ベース (データをバイト単位で処理) であるかによって、同じ操作でも結果が異なることがあります。関数または操作の説明を調べて、混合ストリングを処理する方法を確認します。

GRAPHIC ストリング

GRAPHIC ストリングは、一連の 2 バイト文字データと定義されます。日本語または中国語 (繁体字) の EUC データを GRAPHIC 列に格納できるようにするために、EUC は UCS-2 でエンコードされています。サポートされているすべてのエンコード・スキーム (例えば、PC または EBCDIC DBCS) の中で 2 バイト文字ではない文字は、GRAPHIC 列では使用できません。 2 バイト文字以外の文字を使用すると、変換中に置換文字によって置換されるという結果になることがあります。そのようなデータを検索しても、入力された値と同じ値は戻されません。

ストリング代入

ストリングの変換は、割り当ての前に行われます。 eucJP/eucTW コード・ページおよび DBCS コード・ページが関係する場合、文字ストリングは (DBCS から eucJP/eucTW へ) 長くなるか、または (eucJP/eucTW から DBCS へ) 短くなります。これにより、ストレージの割り当て時にエラーが生じ、検索割り当て時に切り捨てが生じることがあります。変換時の拡張のためにストレージ割り当てのエラーが生じる場合、SQLSTATE 22001 の代わりに SQLSTATE 22524 が戻されます。

同様に、GRAPHIC ストリングに関係した割り当てでは、その結果として UCS-2 エンコード 2 バイト文字が、対応する 2 バイト文字を持たない文字用に、PC または EBCDIC DBCS コード・ページ中の置換文字に変換されることがあります。 SQLCA の SQLWARN10 フィールドを「W」に設定すると、文字を置換文字に置換する割り当てはそのようになります。

マルチバイト文字ストリングが関係した検索割り当て中の切り捨ての場合、切り捨てのポイントがマルチバイト文字の一部になることがあります。この場合、文字のフラグメントである各バイトは、1 バイトのブランクに置換されます。このため、複数の 1 バイトのブランクが、切り捨てられた文字ストリングの末尾に現れることがあります。

ストリングの比較

ストリング比較は、バイト・ベースで行われます。文字ストリングは、データベース用に定義された照合シーケンスも使用します。 GRAPHIC ストリングは照合シーケンスを使用せず、eucJP または eucTW データベースでは、UCS-2 を使用してエンコードされます。したがって、たとえ同じ文字が含まれていても、2 つの混合文字ストリングの比較と、2 つの GRAPHIC ストリングの比較とでは異なる結果になることがあります。同様に、結果の混合文字列および GRAPHIC 列のソート順序は異なることがあります。

結果データ・タイプの規則

文字ストリングの結果データ・タイプは、ストリングが拡張することがあっても影響を受けません。例えば、2 つの CHAR オペランドを結合しても CHAR のままです。ただし、文字ストリングのオペランドの 1 つを変換することで、最大拡張により長さ属性が 2 つのオペランドのうちの最大のものになる場合、結果文字ストリングの長さ属性は影響を受けます。例えば、VARCHAR(100) と VARCHAR(120) のデータ・タイプの CASE 式の結果式を考慮してみます。 VARCHAR(100) 式は (変換する必要があるかもしれない) 混合ストリングのホスト変数であり、VARCHAR(120) 式は eucJP データベース内の列であると仮定します。変換の可能性を考慮して VARCHAR(100) が 2 バイトになっているため、結果データ・タイプは VARCHAR(200) です。同じシナリオで eucJP データベースまたは eucTW データベースを使用しない場合、結果タイプは VARCHAR(120) になります。

ホスト変数長が 2 倍になっていることは、データベース・サーバーが日本語 EUC または中国語 (繁体字) EUC であるということに基づいていることに注意してください。クライアントが eucJP または eucTW であるとしても、やはりホスト変数長は 2 倍になります。これにより、同じアプリケーション・パッケージを、2 バイトまたはマルチバイトのクライアントが使用できるようになります。

ストリング変換の規則

SQL リファレンスの対応セクションにリストされている操作のタイプにより、オペランドがアプリケーションまたはデータベースのコード・ページに変換されることがあります。

日本語または中国語 (繁体字) EUC が含まれる混合コード・ページ環境でそのような操作を行うと、混合文字ストリング・オペランドの拡張または縮小が生じることがあります。したがって、結果のデータ・タイプは、可能であれば最大の拡張を収容する長さ属性を持ちます。データ・タイプの長さ属性に制約がある場合、そのデータ・タイプに許可される最大長が使用されます。例えば、最大増加率が倍である環境では、VARCHAR (200) ホスト変数は VARCHAR (400) であるかのように扱われますが、CHAR (200) ホスト変数は CHAR (255) であるかのように扱われます。変換されたストリングがデータ・タイプの最大長を超える場合、変換の実行時にランタイム・エラーが生じることがあります。例えば、CHAR (200) と CHAR (10) の和集合の結果タイプは CHAR (255) になります。 254 バイトを超えるバイト数が必要な場合、UNION の左側の値が変換されると、エラーが戻されます。

場合によっては、変換による最大拡張を収められるようにするために、長さ属性が限界を超えることがあります。例えば、UNION で許可される列は最大 254 バイトだけです。したがって、可変長文字ストリング 128 バイト長と定義された DBCS 混合文字ストリングである、列リスト (:hv1 と呼ぶ) 内のホスト変数が含まれている UNION がある照会では、データ・タイプが VARCHAR(256) に設定され、アプリケーション内の照会が 254 バイトより大きい列を持たないように思えるとしても、結果として照会の準備においてエラーが発生します。実際のストリングが 254 バイトを超えて拡張する可能性が低い場合は、ステートメントの作成に以下を使用できます。

   SELECT CAST(:hv1 CONCAT ' AS VARCHAR(255)), C2 FROM T1
   UNION
   SELECT C1, C2 FROM T2

NULL ストリングをホスト変数と連結すると、キャストの実行前に変換が強制されます。この照会は、実行時に切り捨てエラーが生じることがありますが、DBCS で eucJP/eucTW 環境に対して作成できます。

この技法 (NULL ストリングとキャストとの連結) を使用して、SELECT DISTINCT の類似の 254 バイト限界を処理するか、または ORDER BY 節または GROUP BY 節の列を使用することができます。

グラフィック・ストリング定数

日本語または中国語 (繁体字) EUC クライアントの場合、1 バイト文字またはマルチバイト文字を含むことができます (混合文字ストリングと同様)。ストリングには 2000 バイトを超えたデータを含めることはできません。 GRAPHIC 定数では、すべての関連 PC および EBCDIC 2 バイト・コード・ページの、2 バイト文字に変換される文字だけを使用することをお勧めします。 SQL ステートメント内の GRAPHIC ストリング定数は、クライアントのコード・ページからデータベース・サーバーの 2 バイト・エンコードに変換されます。日本語または中国語 (繁体字) EUC サーバーでは、定数は UCS-2、すなわち GRAPHIC ストリングに使用される 2 バイト・エンコードに変換されます。 2 バイト・サーバーの場合、定数はクライアントのコード・ページからサーバーの DBCS コード・ページに変換されます。

関数

ユーザー定義関数の設計においては、パラメーターのデータ・タイプに日本語 EUC または中国語 (繁体字) EUC をサポートすることの影響を考慮する必要があります。関数解決の一部では、関数呼び出しに対する引数のデータ・タイプを考慮します。日本語または中国語 (繁体字) EUC クライアントが関係する混合文字ストリング引数では、引数を指定するために追加バイトが必要になることがあります。これには、拡大された長さを収めるためにデータ・タイプの変更が必要になることがあります。例えば、サーバーの VARCHAR(4000) ストリングに収まる、アプリケーションの文字ストリング (LONG VARCHAR) を表示するのに、4001 バイトが必要になることがあります。引数が LONG VARCHAR であることを許可する関数シグニチャーが含まれていない場合、関数解決は関数を見つけることができません。

関数によっては、さまざまな理由から長ストリングが許可されていないものもあります。そのような関数に LONG VARCHAR または CLOB 引数を使用しても、正常に動作しません。例えば、組み込み POSSTR 関数の 2 番目の引数として LONG VARCHAR を使用すると、関数解決が失敗します (SQLSTATE 42884)。

連結演算子がある式

連結のオペランドのいずれかが拡張する可能性があると、日本語または中国語 (繁体字) EUC データベース・サーバーを備えた環境では、連結オペランドのデータ・タイプと長さが変わる場合があります。例えば、ホスト変数からの値の長さが 2 倍になる EUC サーバーを使用する場合の、以下の例を考慮してください。

     CHAR200 CONCAT :char50

列 CHAR200 は CHAR(200) タイプです。ホスト変数 char50 は CHAR(50) と定義されています。この連結演算の結果タイプは、通常は CHAR(250) になります。ただし、eucJP または eucTW データベース・サーバーでは、ストリングが拡張して長さが 2 倍になると想定しています。このため、char50 は CHAR(100) として処理され、結果のデータ・タイプは VARCHAR(300) です。結果が VARCHAR であっても、それには末尾ブランクを含め 300 バイトのデータが常にあることに注意してください。余分の末尾ブランクが必要ない場合、ホスト変数を CHAR(50) ではなく VARCHAR(50) と定義してください。

LIKE 述部

EUC データベースに混合文字ストリングが組み入れられた LIKE 述部の場合、以下のようになります。

SBCS の半角下線文字は、1 つの SBCS 文字を表します。
非 SBCS の全角下線文字は 1 つの非 SBCS 文字を表します。
SBCS 半角または非 SBCS 全角のいずれかのパーセント記号は、ゼロ個以上の SBCS 文字または非 SBCS 文字を表します。

エスケープ文字は、1 つの SBCS または非 SBCS 文字でなければなりません。文字の列の場合、エスケープ文字は、正確に 1 バイトが含まれるバイナリー・ストリングとすることもできます。

下線文字を使用すると、LIKE 操作のコード・ページによって異なる結果が生じる場合があることに注意してください。例えば、カタカナ文字は、日本語 EUC ではマルチバイト文字 (CS2) ですが、日本語 DBCS コード・ページでは 1 バイト文字です。 pattern-expression の 1 バイトの下線で照会すると、カタカナ文字のオカレンスが日本語 DBCS サーバーから下線の位置に戻されます。ただし、日本語 EUC サーバーの同等の表の同じ行は戻されません。カタカナ文字は 2 バイトの下線にしか一致しないからです。

EUC データベースに GRAPHIC ストリングを組み入れられた LIKE 述部の場合、以下のようになります。

全角下線文字 (U+FF3F) は、1 つの Unicode 文字を表します。
全角パーセント文字 (U+FF05) は、0 以上の Unicode 文字を表します。

LENGTH 関数

この関数の処理は、EUC 環境の混合文字ストリングの場合と変わりません。戻される値は、引数のコード・ページでのストリングの長さです。バージョン 8 では、引数がホスト変数である場合、戻される値はデータベースのコード・ページでのストリングの長さです。この関数を使用して値の長さを決める場合、その長さをどのように使用するかを十分考慮する必要があります。これは、混合ストリング定数を使用する場合は、長さが文字単位ではなくてバイト単位で指定されるため、特に当てはまります。例えば、LENGTH 関数によって戻される DBCS データベースの混合ストリング列の長さは、一部の DBCS 文字がマルチバイト eucJP または eucTW 文字に変換されるため、eucJP または eucTW クライアントのその列の検索値の長さよりも短いことがあります。

SUBSTR 関数

SUBSTR 関数は、混合文字ストリングに対してバイト単位での演算を行います。そのため、結果のストリングの先頭または末尾にマルチバイト文字のフラグメントが付いていることがあります。文字のフラグメントの検出または処理は行われません。

TRANSLATE 関数

TRANSLATE 関数は、マルチバイト文字を含む混合文字ストリングをサポートします。 to-string-exp と from-string-exp の対応する文字は、同じバイト数でなければならず、末尾をマルチバイト文字の一部とすることはできません。

char-string-exp が文字ストリングである場合、pad-char-exp の結果は 1 バイト文字でなければなりません。 TRANSLATE は char-string-exp のコード・ページで実行されるため、pad-char-exp はマルチバイト文字から 1 バイト文字に変換されることがあります。

末尾がマルチバイト文字の一部である char-string-exp は、それらのバイトを変換しません。

VARGRAPHIC 関数

日本語 EUC または中国語 (繁体字) EUC のコード・ページの文字ストリング・オペランドに対する VARGRAPHIC 関数は、UCS-2 コード・ページの GRAPHIC ストリングを戻します。

1 バイト文字はまず、それが属する (eucJP または eucTW) コード・セット内の、対応する 2 バイト文字に変換されます。次いで、対応する UCS-2 表記に変換されます。 2 バイト表記がない場合、文字は、UCS-2 表記に変換される前に、そのコード・セットに定義された 2 バイトの置換文字に変換されます。
カタカナ (eucJP CS2) である eucJP の文字は実際には、一部のエンコード・スキームでは 1 バイト文字です。このように、それらの文字は UCS-2 に変換される前に、対応する eucJP の 2 バイト文字、または 2 バイトの置換文字に変換されます。
マルチバイト文字は、UCS-2 表記に変換されます。

CONNECT ステートメント

クライアントまたはサーバーに日本語または中国語 (繁体字) EUC コード・ページが含まれている環境において、アプリケーションがデータを処理する可能性がある場合に、CONNECT ステートメントを正常に処理すると、重要な情報が SQLCA で戻されます。 SQLERRD(1) フィールドは、アプリケーションのコード・ページからデータベースのコード・ページに変換するときに、混合文字ストリングの拡張が最大になります。 SQLERRD(2) フィールドは、データベースのコード・ページからアプリケーションのコード・ページに変換するときに、混合文字ストリングの拡張が最大になります。拡張が生じる場合の値は正で、縮小が生じる場合の値は負になります。値が負の場合、それは常に -1 になります。これは、縮小が発生せず、変換後にストリングの全長が必要になるという最も問題となるケースに対応するためです。正の値は最大で 2 となります。これは最も問題となるケースでは、変換後にその文字ストリングに対して 2 倍のストリング長が必要になるということです。

アプリケーション・サーバーおよびアプリケーション・クライアントのコード・ページは、SQLCA の SQLERRMC フィールドからも知ることができます。

PREPARE ステートメント

非型付きパラメーター・マーカー用に決められたデータ・タイプは、日本語または中国語 (繁体字) EUC が含まれる環境では変更されません。その結果、場合によっては型付きパラメーター・マーカーを使用して、eucJP または eucTW の混合文字ストリングに対して十分な長さを提供することが必要になることがあります。例えば、CHAR(10) 列への挿入を考慮してください。以下のステートメントを作成するとします。

   INSERT INTO T1 (CH10) VALUES (?)

結果としてパラメーター・マーカーのデータ・タイプは CHAR(10) になります。クライアントが eucJP または eucTW であった場合、挿入するストリングを表現するために 10 バイトを超えるバイト数が必要になることがありますが、DBCS コード・ページのデータベースではその同じストリングが 10 バイトを超えることはありません。この場合、作成するステートメントには、10 を超える長さの型付きパラメーター・マーカーが組み込まれている必要があります。したがって、以下のステートメントを作成するとします。

   INSERT INTO T1 (CH10) VALUES (CAST(? AS VARCHAR(20))

結果としてパラメーター・マーカーのデータ・タイプは VARCHAR(20) になります。