 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| Microsoft SQL Server 2005で必要な対処 | ||||||||||
|
SQL Serverは早くからUnicodeに対応してきたデータベースの1つであり、SQL Server 2000ではUnicode 2.0に対応しているのでサロゲートペアを格納することができる。ただし前回も紹介したように「格納できる」のと「正しく扱える」のとでは意味合いが異なる。正しく扱えるのはUnicode 3.2をサポートしたSQL Server 2005からで、もちろんJIS X 0213:2004にも対応できる。 ところが対応できるというだけで、何もしなくて良いというのではない。これから何をしなければならないかを明らかにしていこう。 以前からSQL Serverを使ってきた方ならば承知していると思うが、SQL Serverには文字列を格納するためのデータ型が大きく2種類用意されている。1つはchar/varchar/textなど、先頭に「n」が付かないデータ型。もう1つはnchar/nvarchar/ntextなど、先頭に「n」が付いているデータ型である（注1）。
※注1：
SQL Serverのデータ型であるtextとntextは、将来のバージョンで削除される予定であるとされている。
実は、この「n」が付いている／いないが、今回の話題では極めて重要になる。なぜなら「n」が付いている方はUnicodeをサポートしているのだが、付いていない方はサポートをしていない。言い方を変えれば、「Unicodeを格納したいならば、先頭に『n』が付いているデータ型を使わなければならない」ということだ。 この「n」が付いたデータ型を使うことについては、もう1つ補足説明が必要になる。マイクロソフトのサポートオンラインでも文書化されているように、SQL ServerでUnicodeの文字列を扱うには、文字列の前に「Nプレフィックス」をつけなくてはならない（注2）。それがInsert文やUpdate文で格納するデータをあらわす場所やSelect文のWhere句で条件とする文字列をあらわすところでも、文字列の先頭に大文字のNを記す必要があるのだ。
※注2：
Microsoftサポートオンライン「SQL ServerでUnicode文字列定数を処理するときは、すべてのUnicode文字列の前にNプレフィックスを付ける必要がある」
http://support.microsoft.com/kb/239530/ja 具体的な表記方法は、実験の中で扱っているSQLを参考にしてもらうといいだろう。 実験の前に、もう少しだけややこしいことを言うと、SQL ServerのUnicodeは「UCS-2」というエンコードを使っているため、UTF-8を使っているアプリケーションでは注意が必要だ。それについては省略するが、PHPでアプリケーションを作成する際にはこの辺も影響が出るので気をつけてほしい（注3）。
※注3：
ASP.NETであればIISがブラウザと送受信する際に、UCS-2とUTF-8の変換を行ってくれるのだが、PHPやJavaだとそうもいかない。SQL Serverを使う場合はUCS-2への変換が必要。
|
||||||||||
 |
||||||||||
|
マイクロソフトの参考情報 マイクロソフトは、JIS X 0213:2004に関する問題に関する状況を鑑みてか、比較的頻繁にガイドラインなどをリリースしている。その中でも最近発表されたものが、やはりよくまとまっているので参考情報として紹介しておく。特に後者には、JIS X 0213:2004で追加された文字や実験用のスクリプトも含まれるので、SQL Serverユーザは特に参考になるであろう。
参考情報
SQL Server 2005のインターナショナル機能 http://go.microsoft.com/?linkid=6743837 SQL Server 2005におけるJIS2004対応に関するガイドライン http://go.microsoft.com/?linkid=7003958 |
||||||||||
|
|
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
