前回はキャラクタ・セットは基本的にAL32UTF8を選ぶべしという話をしました。今回は、前回予告した通り、AL32UTF8もいいことばかりじゃないよということについて書きたいと思います。
まず、なんだかんだで、シフトJISの半角1バイト、全角2バイトという設計は人に非常にわかりやすいということですね。ご存知の方が大半だとは思いますが、UTF-8の場合、全角は3バイトになります。半角文字は基本1バイトですが、半角カナは3バイトです。UTF-8の場合、あるデータの文字数から消費バイト数を考える時の計算が面倒です。
また、DB容量の増加という問題があります。純粋な会計システムとか生産管理システムなどですと、漢字のようなデータが占める割合が低いケースも多いかと思います。一方でBlogサイトみたいな文章中心のデータを扱うシステムですと、文字コードをUTF-8にすることによるデータベースサイズの増加が馬鹿になりません。更に言えば、最近のUnicodeはサロゲートペアといって、より多くの文字を表現できるように、よりたくさんのバイト数を使って1文字を定義することもできるようになっています。文字種によっては1文字でより多くのバイト数を使います。たとえばWindows VISTAで使えるようになったJIS2004特有の文字(例えば森鷗外の「鷗」などです。AL32UTF8採用の利点として、JIS2004対応という点もありますね。)は、UTF-8では1文字4バイトになります。
最後に、文字サイズに絡むのですが、もしテーブル名や列名などを日本語で定義したい場合、つけられる文字数の上限がシフトJISよりも下がってしまいます。Oracle Databaseの基本的なオブジェクト名の長さの上限は30バイトですので、シフトJISだと基本的に15文字まで使えますが、UTF-8ですと基本10文字までになってしまいます。もしJIS2004特有の文字を使えば、更に上限が減ります。
話は逸れますが個人的には上限を100バイトくらいにしてもらえると嬉しいのですね・・・。更に話は逸れますがオブジェクト名に日本語を使用する是非についてもいずれ思うところを書きたいと思います。
個人的には、これらのデメリットよりも、使うことによるメリットの方が大きいと考えています。もちろん個別案件では異なる選択をした方がよいケースもあるでしょうが、ここで挙げた様なデメリットがノックアウト・ファクターにならないのであれば、AL32UTF8を選択した方がいいと考えます。
次回は国際化キャラクタ・セットの選択について書きたいと思います。
