まあ、本当にメモ的なものになってしまいますが、データベース自体の文字コードの違いによる テーブル定義のカラムレングス（column length)の注意点を書いておきます。
[例]たとえば、codebaseが、euc-jpの場合のテーブルAがあったとします。定義はこんな感じです。 create table TEST.A ( cola char(100), colb varchar(100), colc int )
- colaは、全角ですと、50文字入ります。
- colaは、半角ですと、100文字入ります。
- colcは、数値のみ入ります。
[例]上記条件をベースした、データベースの文字コードが、UTF-8の場合のテーブル定義は以下のようになります。 create table TEST.A ( cola char(150), colb varchar(150), colc int )
- colaは、全角ですと、50文字入ります。
- colaは、半角ですと、100文字入ります。
- colcは、数値のみ入ります。
キャラクタ形式のカラムは、データベースの文字コードがUTF-8の場合は、euc-jpの時のカラムの大きさを、1.5倍にしたものを 作成してください。ただし、数値データに関してはこれには該当しません、そのままでいいんです。
データベースを、euc-jpからutf-8に切り替える場合等は注意してください。たとえば、euc-jpのカラムlengthと、utf-8の時のカラムlengthが同じ大きさの場合は、 桁落ちする可能性が高くなります。
ついでに。。。 DB2には、GRAPHICという列TYPEがあります。これもまた、データベースのコードページに違いによって特性が変わります。
- EUC-JP,SJIS環境における、GRAPHIC 属性 ○全角のみ受け付ける（半角はNG） ○"abcdeあいう"ではエラーになります。 ○"あいうえおかきく"では正常です。
- UNICODE環境における、GRAPHIC属性 ○全半角混在の文字を受け付ける ○文字数でのカウント：例えば、GRAPHIC(8）の場合は、8文字入るという意味です。 ○ "abcdeあいう"で、8文字です。 ○"あいうえおかきく"でも8文字です。
UTF-8の環境下では、個人的には、GRAPHIC属性をお勧めしたいのですが、phpとかのアプリケーションですと、文字コードの変換が化けちゃうので、 あまり採用されないのです。。残念。db2のphpライブラリが改善することを期待。。
