 |
|||||||||||||||||||
|
|||||||||||||||||||
| 前のページ 1 2 3 | |||||||||||||||||||
|
|||||||||||||||||||
| サロゲートペアは2.0からでも… | |||||||||||||||||||
|
先に述べたように、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になってしまう。
表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はどのような結果となるのか、次回から掲載する実験によって明らかにしていきたいと思う。 |
|||||||||||||||||||
| サロゲートペア実験方法 | |||||||||||||||||||
|
実験は次の5点について行うことにする。データベースの設定などを変更すれば回避できる場合は、そうしなかった場合と比較するために、両方についてのテストを行う。
表1：サロゲートペアのテスト項目 このような実験と結果について、次回はまずMicrosoft SQL Server 2005で必要な対処について詳しく解説を行っていく。 |
|||||||||||||||||||
|
前のページ 1 2 3 |
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
|
|
|||||||||||||||||||
|
|||||||||||||||||||
-
-
連載
