 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
|
||||||||||||
| 実験3：文字の長さを正しく計測できるかやってみる | ||||||||||||
|
SQL Server 2005では使い物にならなかった文字列処理を行う関数についても、同様の実験をしてみるとしよう。では下記のSQLを実行してみる。
select charcol, length(charcol), lengthB(charcol) from unicode_test;
すると下記のような結果が得られた。  （画像をクリックすると別ウィンドウに拡大図を表示します） このようにサロゲートペアで扱われる文字であっても、正しい文字数をカウントしている。もちろん内部的には4バイトで格納されているので、計8バイトで2文字と正しく返されているわけだ。 |
||||||||||||
| 実験4：文字を正しく切り出せるかやってみる | ||||||||||||
|
SQL Server 2005ではCLRを使った.NETのユーザ定義関数を作るほかなかったのだが、Oracle Databaseではどうだろうか。文字列の切り出しについても同様に実験してみるとしよう。 実行したSQLは下記のようなものである。
select substr(charcol, 1, 1) from unicode_test;
その結果は下記の通りだ。  （画像をクリックすると別ウィンドウに拡大図を表示します） これまた問題はない。サロゲートペアで扱う文字であっても、正しく1文字として切り出してきているのがわかる。 |
||||||||||||
| まとめ：Oracle DatabaseでJIS X 0213:2004に対応するには | ||||||||||||
|
SQL Server 2005が大変だっただけに、なんともあっけなかったのだが、Oracle Databaseでの対応方法も一応まとめておこう。
データベースのキャラクタセットを確認し、AL32UTF8などUnicodeを扱えるものにする
ただこれだけだから、アプリケーション側はテストを必要とするだろうが、コードの変更などは必要ないため問題を起こす可能性も皆無であろう。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
