DB2/400 と Unicode

V5R4 で1399 という新しいCCSID がサポートされるようになりました。
IBM のホームページにある解説記事にも「従来の日本語言語コード(2924)に加えて新しいUNICODE(CCSID 1399)ベースの日本語コードがサポートされます」とあるのですが、あくまで"ベース"であり、実際のところ 1399 という CCSID はあくまで EBCDIC であって、Unicode に収録された日本語部分を抜き出してEBCDIC のコードを振ったもの、というものになります。

日本語以外もユニバーサル(Universal) に使える、といった意味でのUnicode 対応でもありませんし、コードがほぼまったく同じなので変換についての考慮点がほとんどない (文字化けやパフォーマンス等) といった意味でのUnicode 対応にもなりません。

まぁ、「Unicode 対応したい」といった場合、PC で入力できる漢字をすべて網羅したい(= 文字化けや文字欠けをなくしたい) という意味であることがほとんどではないかと思いますので、そういうニーズにはCCSID 1399 がおそらくベストの解決策になります。

Unicode の大きな特徴は、その名前の通り、世界中の文字コード(Code) をユナイト(Unite) したということです。つまり、文字コードにUnicode を採用すると、世界中の文字が使える、ということと、どんな文字を使おうと文字コード間の変換を考える必要がない、という大きく二つの利点が得られます。Java やWindows はその利点を得るために、Unicode を内部処理の文字コードとして採用する、という戦略を取ったわけです。

実際にデータベースでの使用用途を考えた場合、ある特定のフィールド/カラムについて、文字化けや文字欠けをなくしたい、または世界中のどんな文字でも入力できるようにしたい、といったニーズがあるんじゃないでしょうか。

DB2/400 の場合、世の中の多くのデータベースのようにデータベース全体で文字コードを設定しなければならない、などということはありません。フィールド/カラム単位に文字コードを設定することができます。つまり、あるカラムだけをUnicode 対応させる、ということができます。
本当にその要件が必要なフィールド/カラムについてだけ設定を検討する、ということが可能です。また、以下の例に見るように、元のデータを残したままでALTER TABLE コマンドひとつで変更することが可能です。

選択肢は大きくわけると、EBCDIC でUnicode の日本語部分の文字を網羅したもの(CCSID 1399)、UTF-8、UTF-16の 3種類かな、と思います。
今回はそのうちあまり取り上げられることのないUTF-8/UTF-16 の2つについてちょっとどんなものか見てみました。


定義する文字数はどう設定するか?

UTF-8

既存のテーブル(システム提供のサンプルファイルです。"AS/400"の頃から存在するファイルですので、当然SQL DDL によって作成されたものではありません) の、あるカラム/フィールドのデータタイプをALTER TABLE 文を使って文字フィールドをUnicode に変更してみました。

データタイプは CHARACTER のままです。CCSID 1208 は UTF-8 と呼ばれるものを指す CCSID になります。

いくつか長さを変えて全角文字をそのカラムにインサートしてみましょう。

まずは SELECT かなんかして元のデータがそのままである、ということ、そのまま 5250 などでも使用できる、ということなどを確認してみましょう。

Unicode 対応、ということで、そもそもデータベース全体の設定とか表領域そのものを作り直すとかそういった大仰なことは必要ない、ということがわかります。
もちろん、アプリケーション開発、データベース設計上はいろんなことを検討する必要はありますが、逆に言えばそれに専念できるということですね。言ってみれば、アプリケーションを作って動かす上では余計な、インフラの心配などをする必要はないということです。

次にいくつか文字を入力してみます。

文字数の変更はあえて行わなかったので 8桁のカラムなのですが、" あいう "は入りません。なのに " あい AB" は入ります。
ずっと EBCDIC に慣れてきた人には違和感があるのではないでしょうか?

入力する全角(DBCS)文字については文字数 x 3 で 0E0F 分のカウントが不要、と設定すればいいようです。
UTF-8 的には確かに正しい計算です。
" あいう "もカラムの桁数を 10桁に増やしてやると入ります。(9桁でいいわけなのですが、なんとなく ...... )

12桁に増やすと、全角 4 文字が格納できることになりますね。

SELECT してみてもきちんと表示されています。ちゃんと入力されている、ということですね。

UTF-16

UTF-16 も使用できます。

UTF-16 の場合、データタイプはCHARACTER/VARCHAR ではなく、GRAPHIC/VARGRAPHIC にする必要があります。が、もちろんALTER TABLE 文で既存のカラム/フィールドを変更することができます。CCSID は 1200 というものになります。

GRAPHIC データタイプの場合、桁数は全角であれ半角であれ文字数をそのまま設定します。

コードが"無変換"とはどういうことか?

実際にどういうコードが入力されているかを見てみましょう。

x'F0' が終わったところからが入力された文字のコードになっています。
x'3042' から x'304A' までが"あいうえお"、x'0041' から x'0063' までが"ABCabc"をそれぞれ表しています。

Windows XP で同様の文字を入力し、Unicode (Big endian) で保管してみます。

内容を見てみると、まったく同じ x'3042' - x'304A'、x'0041' - x'0063'というコードが、同じ文字を表現するのに使用されていることが確認できます。

文字が収められているフォーマットはテキストだったりデータベーステーブルだったり変化がありますが、収納されている文字の内容(コード) 自体はまったく変わりませんね。
たとえば、このテキストファイルから上の例のデータベーステーブルにデータを転送するような場合、フォーマット(テキストファイルの一行→データベーステーブルへのカラム) の変換はJDBC などでプログラムを書けばできますが、その際、文字コードの変換は直接コーディングはしませんね。たとえばJTOpen のJDBC ドライバーなどがやってくれているわけです。この時、JDBC ドライバーはPC の文字コードからEBCDIC への、またはその逆の文字コード変換を行っています。ここで対応する文字がなかったり、予期していたので別の文字に対応していたりすると、文字化けになったり文字欠けになったりするわけですね。

まったく同じコードを使うと、そもそも"変換"ということが行われないわけで、つまりはその"変換"に伴って起きる文字化け等がなくなる、ということになります。

また、変換しないわけですから、変換に使われていたCPU 時間やメモリー領域が必要なくなるわけで、そのぶんパフォーマンスがよくなる、といったことはあるかもしれませんね。

[Top Pageに戻る]

Ads by TOK2