各マルチバイト文字は文字 と見なされますが、 例外として 2 バイトのブランク文字は特殊文字 と見なされます。
マルチバイトの英小文字は大文字に変換されません。 ただし、通常大文字に変換されるトークン中の 1 バイトの英小文字は例外です。
2 バイトのコード・ページと EUC コード・ページとの間の変換により、 2 バイト文字を 2 バイトより大きいバイト数でエンコードされるマルチバイト文字に変換できます。 その結果、2 バイトのコード・ページの最大長に合う識別子が、 EUC コード・ページの長さを超えることがあります。 このタイプの環境の識別子は慎重に選択し、識別子の最大長を超えないようにする必要があります。
MBCS データベースでは、文字ストリングには 1 バイト文字セット (SBCS) と マルチバイト文字セット (MBCS) の文字が混合して含まれる場合があります。 そのようなストリングを使用する場合、 それらが文字ベース (データを文字単位で処理) であるか、 またはバイト・ベース (データをバイト単位で処理) であるかによって 同じ操作でも結果が異なることがあります。 関数または操作の説明を調べて、混合ストリングを処理する方法を決めてください。
漢字ストリングは、一連の 2 バイト文字データとして定義されます。 日本語または中国語 (繁体字) の EUC データを漢字列に記憶できるようにするために、 EUC は UCS-2 でエンコードされています。 サポートされているすべてのエンコード・スキーム (たとえば、 PC または EBCDIC DBCS) の中で 2 バイト文字ではない文字は、漢字列では使用できません。 2 バイト文字以外の文字を使用すると、 その結果変換中に代用文字によって置換されることがあります。 そのようなデータを検索しても、入力された値と同じ値は戻されません。 ホスト変数で漢字データを扱う方法の詳細については、 アプリケーション開発の手引き のプログラム言語の節を参照してください。
ストリングの変換は、割り当ての前に行われます。 eucJP/eucTW コード・ページおよび DBCS コード・ページが含まれている場合、 文字ストリングは (DBCS から eucJP/eucTW へ) 長くなるか、 または (eucJP/eucTW から DBCS へ) 短くなります。 これにより、記憶域の割り当て時にエラーが生じ、 検索割り当て時に切り捨てが生じることがあります。 変換時の拡張のために記憶域割り当てのエラーが生じる場合、 SQLSTATE 22001 の代わりに SQLSTATE 22524 が返されます。
同様に、漢字ストリングを割り当てると、 その結果 UCS-2 エンコード 2 バイト文字が、対応する 2 バイト文字を持たない文字用に、 PC または EBCDIC DBCS コード・ページ中の代用文字に変換されることがあります。 SQLCA の SQLWARN10 フィールドを 'W' に設定すると、 文字を代用文字に置換する割り当てはこのようになります。
マルチバイト文字ストリングを含む検索割り当ての過程における切り捨ての場合、 切り捨てのポイントはマルチバイト文字の一部になることがあります。 この場合、文字の一部である各バイトは、1 バイトのブランクに置換されます。 このため、複数の 1 バイトのブランクが、 切り捨てられた文字ストリングの終わりに現れることがあります。
ストリングの比較は、バイト・ベースで行われます。 文字ストリングは、データベース用に定義された照合順序も使用します。 漢字ストリングは照合順序を使用せず、eucJP または eucTW データベースでは、 UCS-2 を使用してエンコードされます。 このように、たとえ同じ文字が含まれていても、2 つの混合文字ストリングの比較と、 2 つの漢字ストリングの比較とでは異なる結果になることがあります。 同様に、その結果生じる混合文字列および漢字列の分類順序は異なることがあります。
文字ストリングの結果データ・タイプは、ストリングが拡張しても影響を受けません。 たとえば、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 を含む混合コード・ページ環境でそのような操作を行うと、 混合文字ストリング・オペランドが長くなったり短くなったりすることがあります。 そのため、結果のデータ・タイプは可能なら、最大の拡張を収容する長さ属性を持ちます。 データ・タイプの長さ属性に制約がある場合、 そのデータ・タイプに許された最大長が使用されます。 たとえば、最大拡張が 2 倍の環境では、VARCHAR(200) ホスト変数は VARCHAR(400) として、 CHAR(200) ホスト変数は CHAR(254) として処理されます。 変換されたストリングがデータ・タイプの最大長を超える場合、 変換の実行時に実行時エラーが生じることがあります。 たとえば、CHAR(200) と CHAR(10) を結合すると、 結果データ・タイプは CHAR(254) になります。 254 文字より多い文字が必要な場合、結合した左側の値が変換されると、エラーが生じます。
場合によっては、変換のための最大増加分の余裕が取られるために、 長さ属性が限界を超えることがあります。 たとえば、結合に許可される列は 254 バイトまでです。 したがって、 可変長文字ストリング 128 バイト長として定義された DBCS 混合文字ストリングであるホスト変数が 列リスト (:hv1 と呼ぶ) に含まれている結合を使用して照会を行うと、 アプリケーション内での照会が 254 バイトより大きい列を持っていないように思えたとしても、 データ・タイプが VARCHAR(256) に設定され、 照会の準備をしているときにエラーが発生してしまいます。 実際のストリングが 254 バイトを超えて拡張する可能性が低い場合は、 ステートメントの作成に以下のものを使用できます。
SELECT CAST(:hv1 CONCAT ' AS VARCHAR(254)), C2 FROM T1 UNION SELECT C1, C2 FROM T2
ヌル値ストリングをホスト変数に連結すると、 キャストが実行される前に変換が行われます。 この照会は、実行時に切り捨てエラーが生じることがありますが、 DBCS で eucJP/eucTW 環境に対して行うことができます。
この技法 (ヌル値ストリングとキャストとの連結) を使用して、 SELECT DISTINCT の同じ 254 バイト限界を処理するか、 または ORDER BY または GROUP BY 文節の列を使用することができます。
日本語または中国語 (繁体字) EUC クライアントの場合、 1 バイト文字またはマルチバイト文字を入れることができます (混合文字ストリングと同様)。 ストリングに 2 000 文字より多くの文字を含めることはできません。 漢字定数では、 すべての関連 PC および EBCDIC 2 バイト・コード・ページの 2 バイト文字に変換される文字だけを 使用することをお勧めします。 SQL ステートメント中の漢字ストリング定数は、 クライアント・コード・ページからデータベース・サーバーの 2 バイト・エンコードに変換されます。 日本語または繁体字中国語 EUC サーバーでは、定数は UCS-2、 すなわち漢字ストリングに使用される 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) と定義してください。
EUC データベースに混合文字ストリングを含む LIKE 述部の場合、
エスケープ文字は、1 バイト文字または 2 バイト文字でなければなりません。
下線文字を使用すると、 LIKE 操作のコード・ページによって異なる結果が生じる場合があることに注意してください。 たとえば、カタカナ文字は、日本語 EUC ではマルチバイト文字 (CS2) ですが、 日本語 DBCS コード・ページでは 1 バイト文字です。 pattern-expression の 1 バイトの下線で照会すると、 カタカナ文字のオカレンスが日本語 DBCS サーバーから下線の位置に戻されます。 しかし、日本語 EUC サーバーの同じ表の同じ行は戻されません。 カタカナ文字は 2 バイトの下線にしか一致しないからです。
EUC データベースに漢字ストリングを含む LIKE 述部の場合、