TOPサーバ構築・運用> MySQLでは?
Vista&データベース
Windows Vistaで発生するデータベーストラブル対応指南

第4回:Oracle Database 10gやMySQLで必要な対処

著者:一志 達也   2007/7/25
前のページ  1  2  3  4
MySQLでは?

   MySQLを使っている方ならご存じかも知れないが、MySQLもOracle Database同様にUTF-8で文字を保存できる。ところが、サロゲートペアを想定していないために、4バイトとなるサロゲートペア文字を格納できない。

   考えられる対策として、文字型の列ではなくバイナリ型の列に、バイナリとして格納する方法がある。しかし、あくまでバイナリデータとしてしか認識されないため、文字の長さをカウントするなどの動作に問題が生じる。つまるところ、実質的に対応できていると言い難い。

総括:Vistaへの対応は意外と手間がかかる

   巷ではJIS第3水準や第4水準の文字を判定してエラーにするとか、Vistaで入力できないように設定するといった方法も紹介されている。対処療法としては仕方ないのかもしれないが、それではせっかく入力できるようになった新しい漢字の意味がなく、根本的な解決にはなっていないと思う。

   そこで今回のような記事を執筆したのだが、SQL ServerとOracle Database、データベース業界の両雄には思いがけない違いがあることを理解いただけただろうか。Windows Vistaへの対応は、思ったより手間がかかることは周知の事実となっているが、具体的に何が原因で何をしなくてはならないのか。それを正しく理解して、今後一層の普及が予測されるVistaへの対応を進めてほしい。


列の長さは変えなくていい?

   データベースに表を作成する際、列の長さはバイトで指定する。たとえば10文字の漢字を格納する列は、1文字あたり2バイトだから20バイト、という具合に指定していただろう。サロゲートペアのように、2文字分のバイト数で1文字を表現するものが入ってくると、その計算は狂ってしまう。

   実際やってみればよくわかると思うが、文字数に対するデータベースの挙動が変わってしまうので、アプリケーション上では入力できるのにデータベースのエラーで弾かれてしまうという事態が引き起こされるのである。だからといってデータベース側のバイト数を安易に増やしてしまうと、今度は想定以上の長さの文字を入力されかねない。これはデータベースの設計者にとって非常に頭の痛い問題だ。

   さらにオラクルのユーザが知っておかないとならないポイントは、Oracle DatabaseはUnicodeで文字を格納する場合「1文字が3バイトになる」点だ。先の実験を参照してもらうといいのだが、サロゲートペアでないものは1文字あたり3バイトで答えが戻ってきている。これに対しサロゲートペアの文字は「1文字あたり4バイト」が返ってくる。これは、SQL ServerはUCS-2を使い、Oracle DatabaseはUTF-8を使うという違いからくるものだ。

   いずれにしても、JIS X 0213:2004に対応するには、列の定義を見直す必要に迫られる。

   SQL Server 2005の場合、解決策はデータの列長を広げておき、データベースのトリガーなどで文字数をカウントして制約をかけるしかない。あるいは、アプリケーション側でのハンドリングを正確に行うしかないのだ。

   これに対し、Oracle Databaseでは、文字数で列長を指定するという技が使える。これはOracle 9i Databaseから使うことのできるもので、あまり知られていないやり方ではあるのだが、Unicodeに対応するために追加された機能だというのだから使わない手はない。

create table unicode_test2(charcol varchar2(10 char));
create table unicode_test2(charcol varchar2(10 byte));

   上のSQLが10文字を格納できるように列を作成するもので、下のSQLが10バイトを格納できるように列を作成するためのものだ。このように指定すれば、サロゲートペアを含んでいても、確実に10文字まで格納してくれる。

   このように都度指定する以外にも、初期化パラメータ「NLS_LENGTH_SEMANTICS」に「CHAR」を指定し、デフォルトをバイト数から文字数へ変更する方法もある。とはいえ、筆者個人としては、文字数指定であることを明確に表現できるから、都度記入する方をお薦めしたい。

   サロゲートペアによるデータ長の問題についても、この通りOracle Databaseの方が楽に対応できるといえよう。

前のページ  1  2  3  4


一志 達也
著者プロフィール
一志 達也
SI企業において、アプリケーション開発や、データベースを中心としたインフラを担当。開発者向け、初心者向けの講座を得意とする。著書に「やさしいOracle PL/SQL入門」「Oracle10g 真剣勝負」などがある。


INDEX
第4回:Oracle Database 10gやMySQLで必要な対処
  Oracle Database 10gで必要な対処
  事前実験:キャラクタセットの確認
  実験3:文字の長さを正しく計測できるかやってみる
MySQLでは?