先に述べたように、Unicodeを使えばJIS X 0213:2004に対応できるのだが、Unicodeにもバージョンがある。2文字分のコードを使って1文字を表現するサロゲートペアは、Unicodeのバージョン2.0で定義されたのだが、このときにはJIS X 0213:2004は存在していなかった。JIS X 0213:2004で追加された文字がコードにマッピングされたのは、Unicodeのバージョン3.2なのである。
このことは、データベースの対応を問う上で、非常に重要なファクターとなるのだ。
例えばMicrosoftの場合、SQL Server 2000はUnicode 2.0に対応しているが、Unicode 3.2への対応となるとSQL Server 2005でないとならない。同様にOracleの場合、Oracle9i DatabaseはUnicode 3.0に対応しているが、Unicode 3.2への対応となるとOracle Database 10gになってしまう。
Unicodeのバージョン
2.0
3.1
3.2
4.0
対応したOracleのバージョン
8.1.7 （Unicode 3.0へ対応）
9.2.0
10.1.0
10.2.0
対応したSQL Serverのバージョン
7.0／2000
なし
2005
なし
表1：SQL ServerとOracleのUnicode対応
つまり、SQL Server 2000もOracle9i Databaseも、技術的な仕様としてのサロゲートペアには対応できているのだ。
したがってサロゲートペアで表現される文字を格納できるし、何ら損なうことなく取り出すことは可能だ。しかしUnicode 3.2で定義されたJIS X 0213:2004の文字について、正しく理解して動作できるわけではない。より正確に述べれば、それらの文字については知り得ないバージョンだったために、未定義の文字コードを投入されたと認識するのである。
そのため、文字としての認識を必要とする比較演算や制約のチェックの際には、それらの文字を無視してしまうこともある。いずれにしても、Unicode 3.2以上に対応していないデータベースは、JIS X 0213:2004には対応できてないと考えなくてはならない。たまたまうまく動作したとしても、それはあくまで「たまたま」なのだ。
それでは、そのUnicode 3.2以上に対応しているはずのSQL Server 2005とOracle Database10g R2、それにMySQLはどのような結果となるのか、次回から掲載する実験によって明らかにしていきたいと思う。
