Unicode Support 内容 ０．ユニコード入門 １．DB2 CLI、ODBC、JDBCアプリケーションにおけるUnicodeサポート

DB2 UDB (PC&Unix) V7.2
Unicode Support
Unicode Support
お断り：当資料は、DB2 UDB V7.2（UNIX,PC)をベースに作成されています。
＜第１．００版＞２００１年６月
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
内容
０．ユニコード入門
0 - 1 Unicodeとは
0 - 2. UDBのUnicodeサポート
１．DB2 CLI、ODBC、JDBCアプリケーションにおけるUnicodeサポート
1 - １. クライアント・
サーバー間のデータ変換
1 - 2. DB2 CLI ユニコード・アプリケーションの作成
1 - 3. CHARデータ・タイプとGRAPHICデータ・タイプ
1 - 4. ユニコード使用時のその他の考慮事項
1 - 5. 新しい CLI 構成キーワード
1 - 6. LCASE および UCASE (ユニコード)
２．Unicodeデータベースのためのラージ・
インデックス・キー
2 - 1. ラージ・インデックス・キーの影響
2-2. ラージ・インデックス・キーの確認
2-3. ラージ・インデックス・キーのシナリオ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 1-2 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
０．ユニコード入門
この節はV7.2の新機能ではありません。
ユニコード関係の新機能や機能拡張を理解するために、UDBにおける
ユニコード・サポートを説明します。
以下の２つのトピックにより構成されます
0-1. Unicodeとは
0-2. UDBのUnicodeサポート
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：0. ユニコード入門
この節はV7.2の新機能ではありません。
UDBによるユニコードのサポートはUDB V5.2 FixPak7でなされています。 この節では、ユニコード関係の新機能や機能拡張を理解する
ために、UDBにおけるユニコード・
サポートを説明します。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 3-4 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
0 - 1 Unicodeとは (1)
ISO/IEC 10646-1 と Unicode
ISO/IEC 10646-1 は Unicodeとの併合案が取り入れられた国際規格
Unicodeは、民間団体 Unicode Consortiumが中心になってまとめた文字コードセット
ISO/IEC 10646-1と The Unicode Standard V1.1はほぼ同一の規格
日本では ISO/IEC 10646-1をJIS X 0221としてJIS規格になった
UCS（
Universal multiple-octet coded Charecter Set）
ISO 10646は4バイト(32bit)、Unicodeは2バイト(16bit)を基本とする
ISO 10646はUCS-2（
16bit）とUCS-4（
32bit）
の2種類。UCS-2をUnicodeと置き換えた
UCSはISO 10646とUnicodeの総称
サロゲート（sarrogate）
全ての文字を表現するには16bit(65,535文字)では足りなくなるため、2048個の空間
(D800-DFFF)を予約し、これを上位と下位に分けて上位＋下位の32bitで文字を表現
Unicode 2.0でサロゲート方式が導入された
ISO 10646はサロゲートと合せるため UTF-16 変換形式を制定
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：0 - 1. Unicodeとは (1)
Unicodeの成立過程
Unicodeとは、世界中のすべての文字を一意的な固定長数値（
fixed-width）
で符号化してコンピュータの処理を簡単にしようという試
みです。Unicode成立の過程には、国際標準化機構（
ISO）による国際文字コードの制定と民間団体Unicode Consortiumによる統一
コードの制定という２つの流れがありました。
Unicode ConsortiumはMicrosoft社、Apple社、IBM社、DEC社、Novell社、HP社、Sun社、AT&T社等アメリカのコンピュータ・メーカー
を中心として1991年に設立され、その目的としては、世界共通の単一文字コード（
Unicode）を内部コードに採用することによって、
OSやアプリケーション等を国ごとに異なる2バイトの文字コードに対応させる必要がなくなり、現地化（
localization）
にかかっていた膨
大なコストと時間を削減することにありました。
ISOでは ISO 2022系と互換を保つ 4バイト（32bit）方式が検討されていましたが、一方の Unicode Consortiumでは従来のコードとは
全く互換性の無い2バイト（16bit）
方式を検討していました。しかし、国際標準が２つできてしまうのは非常に具合が悪いため、両者
が歩み寄る形で、ISOの当初の案を変更して1993年に新しい標準を制定することになりました。それがISO/IEC 10646-1とThe
Unicode Standard Version 1.1です。
単にISO 10646と言うとISO/IEC 10646-1 のことを指し、正式な標準規格は、
「
ISO/IEC 10646-1:1993 Informatin Technology-Universal Multiple-Octed Coded Character Set(UCS)-Part1
:Archtecture and Basic Multilingual Plane」というものです。
（
ISO:International Organization for Standardization 国際標準化機構 ）
（
IEC:International Electrotechnical Commission
国際電気標準会議）
ISO/IEC 10646-1とUnicode 1.1（1993年）
もともと32bitのISO 10646と16bitのUnicodeというまったく構造の異なる文字コードを合わせるために、ISO/IEC 10646-1は16bitの
UCS-2と 32bitのUCS-4の2本立てにして、UCS-2をUnicodeに置き換えることを行いました。一方UnicodeもISOに合せてV1.0から
V1.1に改訂しました。この時点では UCS-4には文字が割り当てられていないため、32bitへの拡張を含むという点を除くと、ISO/IEC
10646-1とUnicode 1.1は同一規格であるといえます。
UCSとは多重言語文字セット規格(Universal multi-octet coded Character Set)のことを表しています。
日本ではISO/IEC 10646-1をJIS X 0221としてJIS規格になりました。
UCS（
Universal multiple-octet coded Character Set）
ISO/IEC 10646-1:1993とThe Unicode Standardで規定されたコードセットを総称してUCSと呼びます。ISO 10646には16bitコードセッ
トのUCS-2と、32bitコードセットのUCS-4の2種類が規定されています。ISO 10646とUnicodeには同じコード表を採用していますが、
規定には細かい違いがあります。UCSとはこれらを総称した名前です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 5-6 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
0 - 1. Unicodeとは (2)
UTF-8
８bitのASCIIと互換を保ちながらUCS-2の文字を利用できるようにした変換形式
一律２バイト → １バイト∼３バイトに変換
アルファベット、数字、制御文字などのASCII：１バイト
その他の文字：２バイト、または３バイト
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：0 - 1. Unicodeとは (2)
Unicodeの構造
Unicodeは16bit方式によるもので、256×256の桝目を持つ二次元空間（
BMP:Basic Multilingual Plane)に理論上65,535文字を割り当
てることができます。
区
0x00-0x4D
領域
Alphabet
0x4E-0x9F
0xA0-0xDF
0xE0-0xFF
Ideograph
Open
Restricted
種類
最大字数
制御文字、基本ラテン、ギリシャ文字、キリル文字数字、
19968
記号、ハングル等
CJK統合漢字
20992
将来の拡張のため保留
16384
外字、アラビア数字、CJK互換漢字等
8192
Unicodeの問題点
Unicodeの漢字は日本（JIS規格）、中国（GB規格）、韓国（KS規格）、台湾（CNS規格）を一度マージして並び替え、形の
よく似た漢字には同じ文字として同じコードが割り振られました。この結果、8万字以上あった漢字が、20,992文字に縮小
されて16bit以内に収めることができました。しかし漢字文化圏にとっては、使えない文字があったり、形が似ていると言
うだけで意味の異なる文字も同じコードに割り振られるなど、いろいろな矛盾が生じることとなりました。
256×256（16bit）の約 6万5千字のうち漢字を含めて 3万4千字分が割り当てられ、外字 6,400字分を加えると、拡張可能
な文字数は 2万字程度と言われています。しかし、ISOには10646-1制定後、この約 2万字の空きをめぐって文字追加要求
が殺到したため、16bitで全ての文字を表現することは不可能となりました。
Unicode Consortiumは、次のバージョン Unicode 2.0において、 16bit固定長単一文字面方式を放棄し、約４千字の拡張
を行うとともに、2,048個の空間をサロゲート方式（32bitで文字を表す）のために予約しました。サロゲート方式の導入
によって、Unicodeは16bit符号と32bit符号の混在する不定長コードとなりました。ISOには既に32bitのUCS-4があります
が、これはUnicodeのサロゲートとは異なるものです。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 7-8 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
解説：0 -1. Unicodeとは (3)
サロゲート（surrogates）
Unicode 2.0からサロゲートという仕組みが導入されましたが、サロゲートとは、16bitの領域（
65,535）
に2048個の空間（D800∼DFFF
）を予約し、さらにその2048個のコードを上位用1024個と下位用1024個に分けて上位＋下位の32bitコードで1文字を表します。つま
り理論上 1024×1024の実に100万を超える文字を扱うことができるようになります。現在このサロゲート領域にUNICODE 1.1で含ま
れていない漢字を割り当てる作業が進められていますが、この作業がいつ完了するかは不明です。現在 Unicode 3.0という規格を
策定中で、ここにサロゲートを使用した文字が含まれるのではないかと言われています。
一方ISO 10646では32bitのUCS-4が規定されていましたが、同じ32bitでもサロゲートとは全く異なるものなので、UTF-16というUCS
の変換形式によって、サロゲートと同等の方式が取り入れられています。
00
FF
サロゲート（32bit）
DC00
DF00
D800
D8
DF
BMP（16bit）
DB00
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：0 - 1. Unicodeとは (4)
UTF（UCS Transformation Format）
UCS-2またはUCS-4が直接使用できない環境において、UCSの文字セットを処理、伝達したい場合に使用する変換形式です。UTF
には8ビットのASCII互換の環境で使用するためのUTF-8とUCS-2の16bitコードの環境で65,535文字を超える文字を使用するため
のUTF-16などがあります。その他 E-mailで使用されるUTF-7などもあります。
UTF-8
UTF-8はバイト単位で扱われ、ASCII をベースとする既存のシステムで容易に使用できるように設計されています。 UTF-8 は、各
文字を保管するために可変のバイト数 (通常 1-3、4 の場合あり) を 使用します。変化しない ASCII 文字は単一バイトとして保管さ
れます。それ以外の 文字はすべて複数バイトを使用して保管されます。一般に UTF-8 データは、 マルチバイト・コード・ページのた
めに設計されていないコードによって、拡張 ASCII データとして扱うことができます。
UTF-8はASCIIと互換を保ちながらUCSの文字を利用できるようにした変換形式です。Unicode/UCS-2ではASCII文字にも16bitが
割り当てられているため常に上位 8bitは00（
例：
"A"は0041）となり、余計なNULLがストリングの任意の場所に現れてしまう可能性
があります。これを避けるためにUTF-8によってASCII文字は1バイトに変換されます。また、非ASCII文字は2バイトまたは3バイトの
複数バイトに変換されます。変換は以下の規則によって行われます。
UCS-2(hex) UTF-8(binary)
Description
------------- ---------------------------- ------------0001 to 007F 0xxxxxxx
ASCII
0080 to 07FF 110xxxxx 10xxxxxx
up to U+07FF
0800 to FFFF 1110xxxx 10xxxxxx 10xxxxxx other UCS-2
Unicodeの U+0001 から U+007F は、8ビット目を0にして、下7ビットをUnicodeの下7ビットにした1バイト。
Unicodeの U+0080 から U+07FF および U+0000 は、1バイト目については、8−6ビット目を110にして、下5ビットにUnicodeの11
−7ビットを埋めます。2バイト目については、8−7ビット目を10にして、下6ビットにUnicodeの6−1ビットを埋めます。 計2バイト
になります。
UnicodeのU+0800 から U+FFFF は、1バイト目については、8−5ビット目を1110にして、下4ビットにUnicodeの16−13ビットを埋
めます。2バイト目については、8−7ビット目を10にして、下6ビットにUnicodeの12−7ビットを埋めます。3バイト目については、8
−7ビット目を10にして、下6ビットにUnicodeの6−1ビットを埋めます。 計3バイトになります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 9-10 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
0 - 2. UDBのUnicodeサポート(1)
UCS-2、UTF-8をサポート
ISO/IEC 10646 UCS-2（
サロゲート無しのUnicode）
をサポート
UCS-2変換アルゴリズムにUTF-8を実装
コード・
ページ／CCSID
UTF-8はコード・
ページ1208 （CCSID 1208）
データ・タイプ：CHAR、VARCHAR、LONG VARCHAR、CLOB → 1∼3バイト/文字
Unicode/UCS-2はコード・
ページ1200 （
CCSID 13488）
データ・タイプ：GRAPHIC、VARGRAPHIC、LONG VARGRAPHIC、DBCLOB → 2バイト/文字
UCS-2データベースの作成
UTF-8、Codepage 1208で作成
(例)DB2 CREATE DATABASE UNIDB1 USING CODESET UTF-8 TERRITORY JP
データ変換
非ユニコード・
アプリケーションの場合
UTF-8データ：クライアントのCodepageに合わせてデータベース・
マネージャーが変換
UCS-2データ：
変換せず
ユニコード・
アプリケーションの場合
UTF-8データ：
SQL_C_CHARとしてバインドすれば、クライアントのCodepageに合わせてCLIコンポーネントが変換。
SQL_C_WCHARとしてバインドする事によりUCS-2に変換。
UCS-2データ：
SQL_C_WCHARとしてバインドする事により変換なし
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：0 - 2. UDBのUnicodeサポート(1)
UCS-2、UTF-8のサポート
DB2 UDBに ISO/IEC 10646 標準の UCS-2（
サロゲート無しの Unicodeと同じ）
がサポートされました。また UCS-2の可変長変換ア
ルゴリズムに UTF-8 が実装されています。
コード・ページ／CCSID
IBMでは UCS-2 コード・
ページは 1200として登録されています。コード・
ページ1200は、新しい文字が追加されても変わることなく
、常に最新バージョンの Unicode/UCS-2をサポートします。
IBMではUTF-8はCCSID 1208として登録されています。1208 は、DB2 の UCS-2/UTF-8 サポートのマルチバイト・コード・ページ
番号として使用されます。MBCSコード・ページ番号は1208 で、これはデータベースのコードページ番号であり、データベース内
の文字ストリングのコードページです。２バイトのコードページ番号（UCS-2）は1200 で、データベース内のグラフィック文字デ
ータ用のコードページです。コードページ1208（
UCS-2/UTF-8）
で作成されたデータベースでは、CHAR, VARCHAR, LONG
VARCHAR, CLOBのデータはUTF-8に保管され、GRAPHIC, VARGRAPHIC, LONG VARGRAPHIC, DBCLOBデータは
UCS-2に保管されます。単にUCS-2データベースと言う場合、このUCS-2/UTF-8（コード・ページ1208）のことを指します。
Unicode データベースは、DB2でサポートされているすべてのクライアント(シングル／マルチバイトコードページ)から接続することが
可能です。
どのUnicodeの文字が表示可能であるか、または入力可能であるかはクライアント・プログラムが稼動するOSのコードページに依
存します。通常、クライアント・プログラムから扱うことができるデータは、Unicode データベースでサポートしている文字のサブセット
になります。
例えば、ハングル語と日本語が保存されているデータをそれぞれの国のOSから表示してみると、他言語の文字はOSが用意してい
るフォントで表示できません。
ユニコード・データベースの作成
CREATE DATABASE で明示的に CODESET に "UTF-8" (大文字)を指定すると、UCS-2データベースを作成することができます。
DB2 UDB でサポートされるテリトリーについては「管理の手引き 付録：NLS サポート」を参照して下さい。
データベース作成例
言語環境がIBM-943(例えば WindowsNT)で、Unicodeのデータベースを作成する。
[C:¥]DB2 CREATE DATABASE UNIDB1 USING CODESET UTF-8 TERRITORY JP
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 11-12 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
解説：0 - 2. UDBのUnicodeサポート(2)
データ・タイプ
DB2 UDBでサポートされる全てのデータタイプは、UCS-2データベースでサポートされます。
UTF-8ではASCII文字は１バイト、非ASCII文字は2バイト又は３バイトに変換されるため、CHARデータ・タイプで定義されたフィール
ドには考慮が必要です。つまりnバイトで定義された CHARフィールドには、n/3文字からn文字が任意の場所に含まれている可能性
があります。
UTF-8による文字ストリングのコード化とグラフィック・
ストリングのUCS-2データタイプとを比較すると、必要なメモリやディスク容量
にも影響がでてきます。 ASCII文字が大部分を占めている場合、UTF-8ではほぼ１バイト/文字になるため UTF-8による保管は優
れています。しかし、非ASCII文字、特に漢字などの絵文字が大部分を占める場合、UTF-8ではほとんど 3バイト/文字となるので、
2バイト/文字の UCS-2でグラフィック文字列を扱うほうが優れています。
MBCS環境で文字ストリングに対して SQLスカラー関数 LENGTH, SUBSTR, POSSTR, MAX, MIN 等を使用する場合、長さは「バイト
数」であり「文字数」ではありません。これらの関数の説明は「
SQL解説書」を参照して下さい。
データ変換
UCS-2 データベースは、DB2 UDB でサポートされる、シングル・バイトおよびマルチ・
バイトのコード・ページからのすべての接続を
許可します。データベース・
マネージャーによって、クライアントのコード・ページと UTF-8 とのコード・
ページ文字変換は自動的に行
われます。グラフィック・ストリング・タイプのデータは、常に UCS-2 で、コード・ページ変換は行われません。
コマンド行プロセッサー (CLP) 環境は例外です。CLP からグラフィック・ストリング (UCS-2)を選択すると、CLPによって UCS-2 から
クライアントのコード・ページへ変換されて戻されます。
IBMでは UCS-2 コード・
ページは 1200として登録されています。コード・
ページ1200は、新しい文字が追加されても変わることなく
、常に最新バージョンの Unicode/UCS-2をサポートします。
IBMではUnicode2.0およびISO/IEC 10646-1で定義されているUCSの標準レパートリーが、 CCSID 13488として登録されています。
このCCSID(13488)はeuc-Japanとeuc-Taiwanデータベースのグラフィック文字列を保管するためにDB2 UDBによって内部で使用さ
れています。CCSID 13488とコード・ページ1200はどちらもUCS-2をを参照し、2バイトの空白文字を除いて同じように扱われます。コ
ード・ページ1200は CCSID 13488のスーパー・
セットなので、同じ変換テーブルが使用されます。
CP/CCSID Single Byte(SBCS)space Double Byte(DBCS)space
-------- ---------------------- ---------------------1200
N/A
U+0020
13488
N/A
U+3000
UCS-2 16進は UX'...'または GX'...'で記述します。（
...部分は４つの16進数で記述）
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：0 - 2. UDBのUnicodeサポート(3)
識別子
UCS-2データベースでは全ての識別子はマルチ・バイトのUTF-8です。（
使用可能な拡張文字に関する詳細は管理の手引きの付録
．命名規則を参照して下さい）
UCS-2リテラル
グラフィック・ストリング定数は G'..' または N'..'で記述し、このように定義された定数は、データベースマネージャーによってアプリ
ケーションコード・ページからUCS-2に変換されます。
ユニコード・データベースではCHAR型のデータとGRAPHIC型のデータを多くの場合、区別しません。グラフィック・ストリング定数は
G'...' または N'...'についても省略も可能です。 しかしLONG VARGRAPHICデータ・タイプおよびDBCLOBについては例外としてG'..が
必要です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 13-14 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
１．DB2 CLI/ODBC/JDBC AppsにおけるUnicodeサポー
ト
V7.2リリース以前は、Unicodeデータ変換が必要でした
ODBCアプリケーションデータをUnicodeからアプリケーション使用のコードページに変換する
ためには、ODBCドライバーマネージャーに依存します。DB2 ODBCドライバー(CLI)は
Full-Unicodeドライバーとして認識できなかったために、全てのデータは、一度はローカルのコ
ード・
ページに変換されていました。
ユニコード・
アプリケーションにとっては必要のないコード変換が行なわれていたため、パフォ
ーマンスが低下する事がありました。
データがローカルのコードページに変換できなかった場合にデータ代用の可能性があります。
IBM DB2 ODBCドライバーは今やフルUnicode ODBCドライバー
ODBC、JDBC、CLIアプリケーションでUnicode機能変数とUnicodeデータが使用できるように
なりました。
これにあわせJDBCドライバーもCLIユニコードAPIを使用するように変更されました。
アプリケーションとデータベース間での変換が最小限にとどめられました。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：１．DB2 CLI/ODBC/JDBC AppsにおけるUnicodeサポート
V7.2以前
ODBCアプリケーションデータをUnicodeからアプリケーション使用のコードページに変換するためには、ODBCドライバーマネージャ
ーに依存します。DB2 ODBCドライバー(CLI)はFull-Unicodeドライバーとして認識できなかったために、全てのデータは、一度はロー
カルのコード・
ページに変換されていました。
ユニコード・アプリケーションにとっては必要のないコード変換が行なわれていたため、パフォーマンスが低下する事がありました。
データがローカルのコードページに変換できなかった場合にデータ代用の可能性があります。
V7.2以降(V7.1 FixPak 2)
IBM DB2 ODBCドライバーは今やフルUnicode ODBCドライバーとして稼動できるようになりました。
ODBC、JDBC、CLIアプリケーションでUnicode機能変数とUnicodeデータが使用できるようになりました。
これにあわせJDBCドライバーもCLIユニコードAPIを使用するように変更されました。
アプリケーションとデータベース間での変換が最小限にとどめられました
このリリースの DB2 ユニバーサル・
データベースには SQLConnectW() API が含まれています。 ユニコード・ドライバーは、ドライバー・マ
ネージャーにユニコード・ドライバーとして 認識されるように、SQLConnectW をエクスポートする必要があります。 多くの ODBC アプリケ
ーション (Microsoft Access や Visual Basicなど) は SQLConnectW() を 呼び出すことに注意してください。DB2 ユニバーサル・データベ
ースの前のリリースでは、 DB2 CLI はこの API をサポートしていなかったので、ODBC ドライバー・マネージャーは これをユニコード・ドラ
イバーとして認識しませんでした。 このため、ODBC ドライバー・
マネージャーはすべてのユニコード・データをアプリケーションの ローカ
ル・コード・ページに変換していました。SQLConnectW() 関数のサポートが追加された ことで、これらのアプリケーションはユニコード・
ア
プリケーションに接続し、DB2 CLI が 必要なデータ変換をすべて行うようになりました。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 15-16 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
１-1．クライアント・サーバー間のデータ変換
データ変換の仕組み
V7.2以前
ドライバー
アプリケーション
DB2RA AS
ANSI
ANSI
UDBサーバー
CodePageが異なればコード変換
コード変換
(データ欠落の
可能性あり)
UCS-2
ANSI
コード変換
UTF-8
コード変換
UCS-2
V7.2以降
ドライバー
ANSI
アプリケーション
ANSI
UCS-2
DB2RA AS
CodePageが異なればコード変換
UDBサーバー
ANSI
コード変換
UTF-8
UTF-8
コード変換
UCS-2
UCS-2
ANSI
ANSI
UTF-8
UTF-8
UCS-2
UCS-2
コード変換
(データ欠落の
可能性あり)
コード変換
(計算式による)
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：１-1．クライアント・サーバー間のデータ変換
V7.2以前
Application Codepageとサーバー側のCodepage変換はPrivate ProtocolのDB2RAの場合は常にサーバー側でデータ変換が行なわ
れていました。
Unicode DataBaseと接続する場合いままではODBC Driver Manager側でUnicodeを使用したApplicationからApplication Codepage
へ変換する場合にPerformance劣化や変換できない文字の置換文字の置き換えによるデータの欠落(Data Loss)がありました。
V7.2以降(V7.1 FixPak 2)
Unicode CLI Applicationを使用した場合変換なしですべてのGraphicデータをUCS-2、CHARデータをUTF-8として送受信可能になり
ました。
クライアント側でDB2 CLI が 必要なデータ変換をすべて行うようになりました。
(参考)CLIトレースの出力でclient/server間のCodepageがわかります。
( Application Codepage=943, Database Codepage=1208, Char Send/Recv Codepage=1208,
Graphic Send/Recv Codepage=1200, iGraphic Codepage=941 )
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 17-18 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
1-2. DB2 CLI ユニコード・アプリケーションの作成
DB2 CLI ユニコード・アプリケーションのサポート領域には次の 2 つが
あります。
ANSI ストリング引き数の代わりにユニコード・
ストリング引き数を受け入れ可能な 関数のセッ
ト(接尾部 "W")の追加
ユニコード・
データとしてデータを記述する、新しい C およびSQL データ・ タイプの追加
(SQL_C_WCHAR およびSQL_WCHAR)
以下の場合、アプリケーションはユニコード・アプリケーションと見なさ
れる
CLIアプリケーションが SQLConnectW を呼び出す
SQL_ATTR_ANSI_APPをSQL_AA_FALSEに 設定してSQLSetConnectAttr を呼び出す
アプリケーションが上記 2 つの呼び出しのどちらも行わない場合、CHAR データはサーバーでアプリケーション・ローカル・
コード・ページに変換されます。 この場合、SQL_C_WCHAR に取り出された CHAR データがデータ損失を被る可能性があ
ることを意味しています
これにより、 CLI はユニコード・クライアントとして接続し、ユニコード・データはすべて、 CHAR データではUTF-8、
GRAPHIC データでは UCS-2 で送信されます
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：1-2. DB2 CLI ユニコード・アプリケーションの作成
DB2 CLI ユニコード・アプリケーションのサポート領域には次の 2 つがあります。
ANSI ストリング引き数の代わりにユニコード・ストリング引き数を受け入れ可能な 関数のセット(接尾部 "W")の追加
例えば、アプリケーションは SQLConnectW() を呼び出し、DSN、ユーザー ID、および パスワードをユニコード引き数として渡す
ことができます。
ユニコード・データとしてデータを記述する、新しい C およびSQL データ・ タイプの追加(SQL_C_WCHAR およびSQL_WCHAR)
2 つの新しい CLI または ODBC 定義のデータ・タイプ、SQL_C_WCHAR およびSQL_WCHAR が あります。
SQL_C_WCHAR は、C バッファーに UCS-2 データが含まれていることを指示します。 ユニコード・バッファー (SQL_C_WCHAR)
をバインドする事によりアプリケーションはユニコード文字列を取得する事が可能です。 また、データを、 SQL_C_CHAR バッファ
ーにバインドする事により、ローカル・コード・ページで取り出す(データ損失の可能性があります)事も可能です。
SQL_WCHAR は、特定の列またはパラメーター・
マーカーにユニコード・
データが含まれて いることを指示します。
以下の場合、アプリケーションはユニコード・アプリケーションと 見なされる
CLIアプリケーションが SQLConnectW を呼び出す
SQL_ATTR_ANSI_APPをSQL_AA_FALSEに 設定してSQLSetConnectAttr を呼び出す
注意)クライアントでDB2CODEPAGEインスタンス変数を (db2set を使用して)コード・
ページ 1208(UTF-8) に 設定する事も可能です。 こ
の場合でも、アプリケーションはすべての CHAR データを UTF-8で受け取り、データの損失も起こりません。 これは、UTF-8 がローカル
・コード・ページになっているためです。 CHAR入力データもすべてUTF-8であることを確認する必要もあります。 つまり、アプリケーショ
ンでプラットフォームのローカル・コード・ページとユニコードの変換を意識する必要があります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 19-20 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
解説：1-2. DB2 CLI ユニコード・アプリケーションの作成
ユニコード関数
ユニコード・アプリケーションを作成するためにユニコード関数がサポートされました。 以下は、ユニコード (W) および ANSI (A) の両方を
サポートする ODBC API 関数のリストです (ユニコードの関数名には W が付きます。 例えばSQLConnectであれば、相当するユニコード
関数はSQLConnectWとなります。 )。 ユニコード関数の引数はANSI関数と同じです。
SQLBrowseConnect
SQLColAttribute
SQLColAttributes
SQLColumnPrivileges
SQLColumns
SQLConnect
SQLDataSources
SQLDescribeCol
SQLDriverConnect
SQLDrivers
SQLError
SQLExecDirect
SQLForeignKeys
SQLGetConnectAttr
SQLGetConnectOption
SQLGetCursorName
SQLGetDescField
SQLGetDescRec
SQLGetDiagField
SQLGetDiagRec
SQLGetInfo
SQLGetStmtAttr
SQLNativeSQL
SQLPrepare
SQLPrimaryKeys
SQLProcedureColumns
SQLProcedures
SQLSetConnectAttr
SQLSetConnectOption
SQLSetCursorName
SQLSetDescField
SQLSetStmtAttr
SQLSpecialColumns
SQLStatistics
SQLTablePrivileges
SQLTables
常にストリング長引き数を返す、または取得するユニコード関数は、文字数の カウントとして渡されます。サーバー・
データに対して長さ
の情報を返す関数では、 表示サイズは文字の数で示されます。長さ (データの転送サイズ) がストリングまたは ストリング以外のデータ
を参照するときは、長さはオクテット長で示されます。たとえば、SQLGetInfoW は長さをバイト・カウントとして取りますが、
SQLExecDirectW は 文字数のカウントを使用します。CLI は結果セットを、アプリケーションのバインドに 応じてユニコードまたは ANSI
で返します。アプリケーションが SQL_C_CHAR にバインドする 場合、ドライバーは SQL_WCHAR データをSQL_CHAR に変換します。ドラ
イバー・マネージャーは、 ANSI ドライバーについては SQL_C_WCHAR を SQL_C_CHAR にマップしますが、ユニコード・ ドライバーについ
てはマッピングを行いません。
ODBC は、SQL_C_WCHAR データがすべてネイティブ・エンディアン形式であると想定します。CLI は、SQL_C_WCHAR について必要な
バイト反転を実行します。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：1-2. DB2 CLI ユニコード・アプリケーションの作成
CLI Unicode 関数は、引き数に 文字ストリングへのポインターか、SQLPOINTER を使用できます。 引き数ストリングは UCS2 形式です
。 これらの関数は、W 接尾部のある関数として実装されます。
Unicode 関数のプロトタイプは、sqlcli1.h (ODBCの場合はsqlucode.h)にあります。
CLIのユニコード・アプリケーションを作成するためには、 sqlcli1.h を使用し、UNICODE 定義を指定してコンパイルする必要があります。
ODBCのユニコード・
アプリケーションを作成するためには、 sqlucode.hを使用し、同様にUNICODE 定義を指定してコンパイルする必要
があります。
アプリケーションは、ユニコード・アプリケーションまたは ANSI アプリケーション としてコンパイルできるように記述されます。 UNICODE
定義をオンにすると、アプリケーションは ユニコード・
アプリケーションとしてコンパイルされます。この場合、 W のない関数呼び出しは、
アプリケーションがUnicode定義をオンにしてコンパイルされた場合、 W のついた対応する関数にマップされます。
Unicode 関数と SQL_C_WCHAR をODBCで必要とする場合には ODBC 3.5 以降のドライバー・
マネージャーを使用してください。
SQLConnectWのプロトタイプ
SQLRETURN SQL_API SQLConnectW(
SQLHDBC
hdbc,
SQLWCHAR
*szDSN,
SQLSMALLINT
cbDSN,
SQLWCHAR
*szUID,
SQLSMALLINT
cbUID,
SQLWCHAR
*szAuthStr,
SQLSMALLINT
cbAuthStr);
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 21-22 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
１-3．CHARデータ・タイプとGRAPHICデータ・タイプ
CHARタイプ・データとGRAPHICタイプ・
データ
ユニコード・
データベースの場合、以下が同等のデータ・タイプと見なされます
CHAR および GRAPHIC
VARCHAR および VARGRAPHIC
LONG VARCHAR および LONG VARGRAPHIC
CLOB および DBCLOB
この事はストリングの割り当て/比較/データ変換においてCHARデータ・タイプとGRAPHICデ
ータ・タイプでは互換性がある事を意味しています
ユニコード・
データベースに接続するとき、CLI アプリケーションはCHARデータをGRAPHICデ
ータとして、また、GRAPHICデータをCHARデータとして受け取る事が可能です
グラフィック・リテラルは G 接頭部で文字リテラルと区別されます。
たとえば:
SELECT * FROM mytable WHERE mychar = 'utf-8 data' AND mygraphic = G'ucs-2 data'
注: G 接頭部はユニコード・
データベースには不要です。 ただしLONG VARGRAPHICデータ・タイプおよびDBCLOBにつ
いては例外としてG 接頭部が必要です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：1-3. CHARデータ・タイプとGRAPHICデータ・タイプ
ユニコード・データベースの場合、以下が同等のデータ・タイプと見なされます
この事はストリングの割り当て/比較/データ変換においてCHARデータ・タイプとGRAPHICデータ・タイプでは互換性がある事を意味
しています
例えば、”INTEGER データ・タイプをGRAPHICデータ・タイプへキャストする”、”CHARデータ・タイプとGRAPHICデータ・タイプを比較
する”、”CHARデータ・タイプとGRAPHICデータ・タイプを結合子により結合する”
等が可能になります。
非ユニコード・
データベースでは、これらの事はサポートされません。
ユニコード・データベースについては、GRAPHIC/VARGRAPHIC および CHAR/VARCHARリテラル間の キャストは不要です。また、G 接
頭部は GRAPHIC/VARGRAPHIC リテラルの 前には必要ありません。少なくとも 1 つの引き数がリテラルの場合、暗黙的変換が 行わ
れます。これにより、リテラルは G 接頭部を持っていても持っていなくても、 SQLPrepareW() または SQLExecDirect() を使用するステー
トメント内で使用することが できます。LONG VARGRAPHIC およびDBCLOB のリテラルには G 接頭部が必要です。
非ユニコード・
データベースでは
H:>db2 "values('AAA'||G'ＡＡＡ')"
SQL0440N 互換引き数を持つ "||"
という名前の関数が、関数パスで見つかりませんでした。 SQLSTATE=42884
ユニコード・
データベースでは
H:>db2 "values('AAA'||G'ＡＡＡ')"
1
-----------AAAＡＡＡ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 23-24 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
1-4. ユニコード使用時のその他の考慮事項
CHAR 列のデータはユニコード文字につき 1 バイトから 3 バイト
GRAPHIC列のデータはユニコード１文字に対して2バイトですが、CHAR 列のデータはユニコ
ード文字につき 1 バイトから 3 バイトを使用します。 列の定義やSQL 制限はバイト数で行な
われますので、注意が必要です。
UCS-2 のバイト順序は、プラットフォーム間で異なる場合があります。
UCS-2はネイティブ・エンディアンとして表現されます。
GRAPHICデータ・タイプの操作に影響するcli.ini ファイル・キーワードな
しで試してみることをお勧めします
GRAPHIC=1,2 または 3, Patch2=7 のような、 一連の cli.ini ファイル・
キーワード
クライアント側にユニコード・
コード・ページ変換テーブル・コンポーネン
トの導入が必要になります
ユニコード・
データベースを使用する場合に必要です。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：1-4. ユニコード使用時のその他の考慮事項
CHAR 列のデータはユニコード文字につき 1 バイトから 3 バイト
GRAPHIC列のデータはユニコード１文字に対して2バイトですが、CHAR 列のデータはユニコード文字につき 1 バイトから 3 バイトを
使用します。 列の定義やSQL 制限はバイト数で行なわれますので、注意が必要です。
UCS-2のバイト順序は、プラットフォーム間で異なる場合があります。
Windows環境に代表されるIntelマシーンではエンディアン(バイトの逆転)が起こります。ODBCはSQL_C_WCHARデータが全てネイテ
ィブ・エンディアン形式である事を想定します。 CLIはSQL_C_WCHARについて必要なバイト反転を行います。 デバッグの時やCLIト
レースを見る時には注意が必要です。
古いキーワード/パッチ値
ユニコード・アプリケーションがサポートされる以前、単一バイト文字データを 操作するために書かれたアプリケーションは、
GRAPHIC=1,2 または 3, Patch2=7 のような、 一連の cli ini ファイル・
キーワードによって 2 バイト漢字データを操作することができ
ました。このような回避策は、文字データとして漢字データを 表示し、報告されるデータの長さにも影響します。 これらのキーワード
はユニコード・
アプリケーションには不要になったばかりでなく、 使用すると深刻な副次作用を招くおそれがあります。あるアプリケー
ションがユニコード・ アプリケーションかどうかがわからない場合は、漢字データの処理に影響する キーワードなしで試してみること
をお勧めします。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 25-26 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
１-5．新しい CLI 構成キーワード
新しい CLI 構成キーワード
ユニコード・
アプリケーションがデータベースに接続するときに余分なオーバーヘッドを 避ける
ために、次の 3 つのキーワードが追加されました。
これらのキーワードはCLI/ODBC 設定ノートブックで設定することはできません。 このキーワ
ードを使用するためには、db2cli.ini ファイルを直接編集する必要があります。
1. DisableUnicode
ユニコードのサポートを使用可能/使用不可にします。
2. ConnectCodepage
余分な接続オーバーヘッドを避けるために、データ・ソースに接続するときに 使用する特定のコード・
ページを指定します
。
3. UnicodeServer
データ・ソースがユニコード・サーバーであることを指示します。 ConnectCodepage=1208 の 設定と同じです。
DB2 (OS/390 版)バージョン7またはそれ以降に接続するときの余分な接続オーバーヘッドを避けるためにこのキーワード
を設定します。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：１-5．新しい CLI 構成キーワード
1. DisableUnicode
キーワードの説明:
ユニコードのサポートを使用不可にします。
db2cli.ini キーワード構文
DisableUnicode = 0 | 1
デフォルト設定
0 (false)
DB2 CLI/ODBC 設定タブ:
このキーワードは CLI/ODBC 設定ノートブックで設定することはできません。 このキーワードを使用するためには、db2cli.ini フ
ァイルを直接編集する必要があります。
使用上の注意:
ユニコード・サポートを使用可能にして、ユニコード・アプリケーションから呼び出すと、CLI はコード・
ページ変換による不要なデ
ータ損失のないように、 最適なクライアント・コード・ページを使用してデータベースに接続しようとします。 これにより、コード・ペ
ージ交換のために接続時間が増加するか、またはこのサポートが 追加される前には行われたことのないクライアントでのコー
ド・ページ変換が行われる 可能性があります。
このキーワードを True に設定すると、すべてのユニコード・
データが、 サーバーに送信される前にアプリケーションのローカル・
コード・ページに変換されます。 これにより、ローカル・コード・ページでは表示できないデータが失われることがあります。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 27-28 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
解説：１-5．新しい CLI 構成キーワード
2. ConnectCodepage
キーワードの説明:
余分な接続オーバーヘッドを避けるために、データ・ソースに接続するときに 使用する特定のコード・ページを指定します。
db2cli.ini キーワード構文
ConnectCodepage = 0 | 1 <有効な db2 コード・ページ>
デフォルト設定
0
DB2 CLI/ODBC 設定タブ:
このキーワードは CLI/ODBC 設定ノートブックで設定することはできません。 このキーワードを使用するためには、db2cli.ini フ
ァイルを直接編集する必要があります。
使用上の注意:
非ユニコード・アプリケーションは常に、アプリケーションのローカル・コー・ページ、 または DB2Codepage 環境設定を使用して
データベースに接続します。デフォルトでは、CLI は 常にユニコード・
アプリケーションが UTF-8または UCS-2 コード・
ページを
使用して ユニコード・
データベースに接続するように、またはデータベースのコード・
ページを 使用して非ユニコード・
データベー
スに接続するようにします。これにより、コード・
ページ 変換による不要なデータ損失を避けることができます。
このキーワードを使用すると、 ユーザーは接続時の余分なオーバーヘッドを避けるために、ユニコード・データベースへの 接続
時にデータベースのコー・
ページを指定することができます。
値 1 を 指定すると、SQLDriverConnect() は出力接続ストリングに正しい値を返します。 これにより値を以降の
SQLDriverConnect() 呼び出しで使用することができます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：１-5．新しい CLI 構成キーワード
3. UnicodeServer
キーワードの説明:
データ・ソースがユニコード・サーバーであることを指示します。
ConnectCodepage=1208 の 設定と同じです。
db2cli.ini キーワード構文
UnicodeServer = 0 | 1
デフォルト設定
0
DB2 CLI/ODBC 設定タブ:
このキーワードは CLI/ODBC 設定ノートブックで設定することはできません。 このキーワードを使用するためには、db2cli.ini フ
ァイルを直接編集する必要があります。
使用上の注意:
このキーワードは ConnectCodepage=1208 と同じもので、便宜上追加されたものです。 DB2 (OS/390 版) バージョン7またはそ
れ以降に接続するときの余分な接続オーバーヘッドを 避けるためにこのキーワードを設定してください。DB2 (Windows 版)、
DB2 (Unix 版)、 または DB2 (OS/2 版) については、余分な処理が必要にならないため、このキーワードを 設定する必要はあり
ません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 29-30 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
1-6. LCASE および UCASE (ユニコード)
LCASE および UCASE (ユニコード)
ユニコード・
データベースでは、ユニコード文字のレパートリー全体が、 これらの文字のユニコ
ード・
プロパティーに基づく英大文字 (または小文字) です。ASCII文字の横倍角バージョンは
、ローマ数字と同様、正しく大文字小文字変換を行うようになりました。
CHARタイプとGRAPHICタイプで同様の変換が行なわれます
日本語は変換されません
ユニコード・データベースでは、文字または漢字ストリングを受け入れる
スカラー関数はすべて、変換がサポートされるストリング・
タイプを受け
入れます。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：1-6. LCASE および UCASE (ユニコード)
LCASE およびUCASE 関数がユニコード対応になりました。 この変更はバージョン 7.1 のフィックスパック 1 から有効になりました。
引数が１つのTRANSLATE関数もUCASE同様に機能します。
ユニコード・データベースでは、文字または漢字ストリングを受け入れる スカラー関数はすべて、変換がサポートされるストリング・タイプ
を受け入れます。
UCASEの例
COL2
---------A
a
Ａ
ａ
あ
ぁ
ァ
ア
ⅰ
Ⅰ
UCASE
---------A
A
Ａ
Ａ
あ
ぁ
ァ
ア
Ⅰ
Ⅰ
LCASEの例
COL2
---------A
a
Ａ
ａ
あ
ぁ
ァ
ア
ⅰ
Ⅰ
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 31-32 )
LCASE
---------a
a
ａ
ａ
あ
ぁ
ァ
ア
ⅰ
ⅰ
DB2 UDB (PC&Unix) V7.2
Unicode Support
２．Unicodeデータベースのためのラージ・インデックス・キ
ー
V7.2以前、変数の索引キー部分の最大長は255バイト
索引キー内の実際の可変長列の長さを１バイトで格納
VARCHARおよびVARGRAPHICデータ・タイプはオーバー・
ヘッドを含み255バイトまでであれ
ば索引の一部となる事が可能
V7.2では255 バイトよりも長い列を索引キーの一部として指定可能
索引キー内の実際の可変長列の長さを２バイトで格納する事により制限を撤廃
db2set DB2_INDEX_2BYTEVARLEN=ON (省略時はOFF)
プライマリー・
キー、外部キー、およびユニーク・
キーについても同様に制限を撤廃
VARCHARおよびVARGRAPHICデータ・タイプはオーバー・
ヘッドを含み1024バイトまでであれ
ば索引の一部となる事が可能
索引についてのそれ以外の制限は変更なし
引き続き、以下のような制限があります
索引キーの最大長 (すべてのオーバーヘッドを含む)
1024バイト
索引キーの列の最大数
16
固有 (UNIQUE) 制約の列の結合後の最大長 (固有索引によってサポートされる) 1024バイト
固有 (UNIQUE) 制約の列の最大数 (固有索引によってサポートされる)
16
外部キーで参照される列の結合後の最大長
1024バイト
外部キーで参照される列の最大数
16
列の長さ属性が制限内であってもLOB 列、DATALINK列を索引の一部として使用は不可
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
キー
解説：Unicodeデータベースのためのラージ・インデックス・
V7.2以前
V7.2以前では"変数の索引キー部分の最大長は255バイト"という制限がありました。 これは索引内の実際の長さをあらわすため
に１バイトを使用していたからです。 これはシステム・カタログ内の定義ではなく内部的に使用されているコントロール・ブロックの
定義です。
V7.2以降(V7.1 FixPak 2)
索引内の実際の長さをあらわすために2バイトを使用することにより、この制限は撤廃されました。 プライマリー・キー、外部キー、
およびユニーク・
キーについても同様に255バイトの制限を越えて拡張できます。
2バイト長索引を使用するためには新しいレジストリー変数DB2_INDEX_2BYTEVARLENをONに設定します。省略時はOFFです。
db2set DB2_INDEX_2BYTEVARLEN=ON
db2start
db2 connect to db_name
db2 CREATE INDEX .............
索引に関しての他の制限に変更はありません。 特に"索引キーの最大長 (すべてのオーバーヘッドを含む)：1024バイト"が引き続き制
限となるため、索引キー部分の最大長も実質1024バイトとなります。 VARCHARに関してのオーバーヘッドは長さフィールド4バイトおよ
びNullableであればNullフラグ1バイトです。
この制限撤廃により、実際に制限が緩和されたのは最大長制限付き可変長データ・タイプであるVARCHARおよびVARGRAPHICです。
LOB 列、DATALINK 列は制限値以内であっても索引の一部となる事はできません。 LONG VARCHARは最大制限長を指定できないた
め、やはり索引の一部となる事はできません。
2バイト長索引を使用するために既存の索引を変換する事はできません。 索引をドロップして、DB2_INDEX_2BYTEVARLEN レジストリ
ー変数をオンに設定し、 索引を 再作成する必要があります。
表題では"Unicodeデータベースのための．．．"となっていますが、Unicodeデータベースでなく他のコード・
ページで作成されたデータベ
ースであっても使用可能です。 コード・
ページによる相違はありません。
将来的にはDB2_INDEX_2BYTEVARLENのレジストリーはなくなり、全ての索引は2バイト長索引になる事が計画されています。 バージョ
ン内での整合を取るためにV7ではレジストリー変数で制御しています。
レジストリー変数の値に関係なく、255 バイトの外部キー制限はなくなります。 ただし、 外部キーに対応する 1 次キーの真理条件では
、制限が強制されます。 つまり、対応する 1 次キーの長さの制限内でしか、データを表に挿入することはできません。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 33-34 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
2-1. ラージ・インデックス・キーの影響
影響をうけるSQLステートメント
CREATE TABLE
可変キー部分を持つプライマリー・
キー、外部キー、およびユニーク・
キーは、 255 バイトよりも大きなサイズにすることが
可能
CREATE INDEX
可変キー部分を持つすべての索引 (ユニーク・
キーおよび組み込み列を含む) は、 255 バイトより大きなサイズにすること
が可能
ALTER TABLE
可変キー部分を持つ プライマリー・
キー、外部キー、およびユニーク・
キーは、 255 バイトよりも大きなサイズにすることが
可能
可変キー部分を持つすべての索引 (ユニーク索引および組み込み列を含む) は、 255 バイトより大きなサイズにすることが
可能
定義された、 1次および固有キーを含む索引の一部である可変長列の長さを 255バイトを超える長さに変更することが可
能
索引作成後のDB2_INDEX_2BYTEVARLENの変更の影響
DB2_INDEX_2BYTEVARLEN=OFFで作成した索引
DB2_INDEX_2BYTEVARLEN=ONにしてもALTER TABLEで255バイトを超える索引にする事はできない
DB2_INDEX_2BYTEVARLEN=ONで作成した索引
DB2_INDEX_2BYTEVARLEN=OFFにしてもALTER TABLEで255バイトを超える索引にする事が可能
==> 索引を作成したときのDB2_INDEX_2BYTEVARLENの値による
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：2-1. ラージ・インデックス・キーの影響
レジストリー変数を変更すると、複数の SQL ステートメントが影響を受けます。 影響をうけるステートメントは上記のとおり、CREATE
TABLE / CREATE INDEX / ALTER TABLEです。 いずれも255バイトをこえるキーまたは索引が作成可能になります。 ALTER TABLEで
は、索引に含まれる可変長列を255バイトを超える長さに変更できるようになります。
組み込み列とはInclude列とも呼ばれ、ユニーク索引にふくまれるユニーク性の検査を受けない列の事です。 この組み込み列に関しても
255バイトをこえる長さの可変長列を指定、または255バイトをこえる長さへの変更ができるようになっています。 この場合でも、組み込
み列を含むユニーク索引の最大長は1024バイトとなります。
索引作成後のDB2_INDEX_2BYTEVARLENの変更の影響
==> 索引を作成したときのDB2_INDEX_2BYTEVARLENの値により決まっています。
DB2_INDEX_2BYTEVARLENを変更した場合にはdb2stop/db2startで反映させます。
DB2_INDEX_2BYTEVARLEN=OFFに戻しても、255バイトを超える可変長列を含む索引はそのまま使用が可能です。
索引は作成された時のDB2_INDEX_2BYTEVARLENレジストリ変数により1バイト長索引/2バイト長索引の属性が決まります。
DB2_INDEX_2BYTEVARLEN=ONで作成した索引は2バイト長索引となり、DB2_INDEX_2BYTEVARLEN=OFF(省略時値)で作成した索
引は1バイト長索引となります。 作成後にDB2_INDEX_2BYTEVARLENレジストリー変数を変えたとしても、作成された索引の属性は
変る事はありませんし、振る舞いが変わる事もありません。 2バイト長索引-> 1バイト長索引または1バイト長索引->21バイト長索
引に変換したい場合は索引をドロップした後、索引の再作成をする事によりDB2_INDEX_2BYTEVARLENレジストリー変数で指定さ
れる属性の索引が作成されます。
例えば、索引に含まれる可変長列をALTER TABLEで255バイトを超える長さにする事を考えた場合、
DB2_INDEX_2BYTEVARLEN=ONにして作成、そのままALTER TABLEで255バイトを超える長さにする
=> もちろん OK
DB2_INDEX_2BYTEVARLEN=ONにして作成、DB2_INDEX_2BYTEVARLEN=OFFにした後ALTER TABLEで255バイトを超える長
さにする
=> OK
DB2_INDEX_2BYTEVARLEN=OFFにして作成、DB2_INDEX_2BYTEVARLEN=ONにした後ALTER TABLEで255バイトを超える長
さにする
=> NG
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 35-36 )
DB2 UDB (PC&Unix) V7.2
Unicode Support
2-2. ラージ・インデックス・キーの確認
2バイト長索引の確認
1バイト長索引/2バイト長索引の情報は該当テーブルのPacked Descriptorおよび索引のルー
ト・ページにあります
db2catによる確認
db2catは表のPacked Descriptorの内容をダンプしフォーマットする問題判別用のツールです
db2cat -d dbname -s schema -n tabname -o output_file
出力ファイルで該当の索引のための"INDEX DESCRIPTION"を探す
その項目の中に"2 Byte Varlength
:Yes"があれば2バイト長索引
"2 Byte Varlength"の項目がなければ1バイト長索引
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：2-2. ラージ・インデックス・キーの確認
1バイト長索引/2バイト長索引の情報は該当テーブルのPacked Descriptor(SYSIBM.SYSTABLES PACKED_DESC)および索引のルート
・ページにあります。
2バイト長索引の確認
db2catによる確認
db2catは表のPacked Descriptorの内容をダンプしフォーマットする問題判別用のツールです。 このツールにより該当の索引が
1バイト長索引/2バイト長索引のどちらであるかを確認できます。
db2cat -d dbname -s schema -n tabname -o output_file
出力ファイルで該当の索引のための"INDEX DESCRIPTION"を探し、その項目の中に"2 Byte Varlength
バイト長索引です。 1バイト長索引の場合は"2 Byte Varlength"の項目自体がありません。
前略
INDEX NAME : TMEP5IDX1
COLUMN NAME : +COL2
Index name offset
: 284
Index column names offset : 293
Length of column names
:5
Iid
:1
(中略)
Unique
: Yes
Primary Key
: No
System Defined Key
: No
Used as a unique constraint: No
2 Byte Varlength
: Yes
No. of keys
:1
No. of Unique keys
:1
Keypart 1
keyptid
: 1
order
:0
codepage
: 943
description of keypart
type , length
: VARCHAR , 1000
nullable
:1
後略
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 37-38 )
:Yes"があれば2
DB2 UDB (PC&Unix) V7.2
Unicode Support
解説：2-3. ラージ・インデックス・キーのシナリオ
使用例 (255バイトを超えるVARCHAR列の索引を作成)
$ db2 create table lindextst1 (var1 varchar(1000), var2 varchar(1000), var3 varchar(1050), varg1 vargraphic(300))"
DB20000I SQL コマンドが正常に終了しました。
$ db2 "create index var1tst1 on lindextst1 (var1)"
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQL
省略時では255バイトを超えるVARCHAR列を
ステートメントとして処理されました。 SQL
索引にする事ができない
処理中に、そのコマンドが返されました。
SQL20075 "VAR1" の長さが 255 バイトを超えているため、索引または 索引拡張子
"VAR1TST1" を作成または更新することはできません。 SQLSTATE=54008
$ db2 connect reset
DB20000I SQL コマンドが正常に終了しました。
$ db2set DB2_INDEX_2BYTEVARLEN=ON
$ db2stop
SQL1064N DB2STOP の処理が正常に終了しました。
$ db2 terminate
DB20000I TERMINATE コマンドが正常に終了しました。
$ db2start
SQL1063N DB2START の処理が正常に終了しました。
$
DB2_INDEX_2BYTEVARLEN=ONにする事により、
$ db2 connect to samplex
255バイトを超えるVARCHAR列、VARGRAPHIC列、
を索引にする事が可能
データベース接続情報
データベース・サーバー
= DB2/6000 7.2.0
SQL 権限 ID
= UDBV7
ローカル・データベース別名 = SAMPLEX
$ db2 "create index var1tst1 on lindextst1 (var1)"
DB20000I SQL コマンドが正常に終了しました。
$ db2 "create index var1tst2 on lindextst1 (varg1)"
DB20000I SQL コマンドが正常に終了しました。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
解説：2-3. ラージ・インデックス・キーのシナリオ
使用例 (ALTER TABLEにより 索引に含まれるVARCHAR列を255バイトを超える長さに変更)
$ db2 "create table indextst1 (var1 varchar(100), varg1 vargraphic(50))"
DB20000I SQL コマンドが正常に終了しました。
$ db2 "create index var1test1 on indextst1 (var1)"
省略時では索引に含まれるVARCHAR列を255バイトを
DB20000I SQL コマンドが正常に終了しました。
$ db2 "alter table indextst1 alter var1 set data type varchar(500)"
超える長さにALTERする事ができない
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQL
ステートメントとして処理されました。 SQL
処理中に、そのコマンドが返されました。
SQL20075 "0" の長さが 255 バイトを超えているため、索引または 索引拡張子
"VAR1TEST1" を作成または更新することはできません。 SQLSTATE=54008
DB2_INDEX_2BYTEVARLEN=ON に変更
$ db2 "alter table indextst1 alter var1 set data type varchar(500)"
DB21034E コマンドが、有効なコマンド行プロセッサー・コマンドでないため、SQL
ステートメントとして処理されました。 SQL
処理中に、そのコマンドが返されました。
SQL20075 "0" の長さが 255 バイトを超えているため、索引または 索引拡張子
"VAR1TEST1" を作成または更新することはできません。 SQLSTATE=54008
$ db2 "create table indextst2 (var1 varchar(100), varg1 vargraphic(50))"
DB20000I SQL コマンドが正常に終了しました。
$ db2 "create index var1test2 on indextst2 (var1)"
DB20000I SQL コマンドが正常に終了しました。
$ db2 "alter table indextst2 alter var1 set data type varchar(500)"
DB20000I SQL コマンドが正常に終了しました。
$ db2 "create table indextst3 (var1 varchar(100), varg1 vargraphic(50))"
DB20000I SQL コマンドが正常に終了しました。
$ db2 "create index var1test3 on indextst3 (var1)"
DB20000I SQL コマンドが正常に終了しました。
DB2_INDEX_2BYTEVARLEN=OFF に変更
$ db2 "alter table indextst3 alter var1 set data type varchar(500)"
DB20000I SQL コマンドが正常に終了しました。
(C)日本IBMｼｽﾃﾑｽﾞ･ｴﾝｼﾞﾆｱﾘﾝｸﾞ(株) ﾃﾞｰﾀｼｽﾃﾑ部
( 39-40 )
DB2_INDEX_2BYTEVARLEN=ONにしても、
DB2_INDEX_2BYTEVARLEN=OFFの環境
で作成した索引に含まれるVARCHAR列は
255バイトを超える長さにALTERする事が
できない
DB2_INDEX_2BYTEVARLEN=ONの環境
で作成した索引に含まれるVARCHAR列は
255バイトを超える長さにALTERする事が可能
DB2_INDEX_2BYTEVARLEN=OFFにしても、
DB2_INDEX_2BYTEVARLEN=ONの環境
で作成した索引に含まれるVARCHAR列は
255バイトを超える長さにALTERする事が可能