 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 何が問題？何が起こる？なぜ起こる？ | ||||||||||
|
では、なにが問題なのだろうか。それは文字のハンドリングの差によって、データベースから正しい結果を得られなくなることである。 業務システムの対処も様々ではあるが、特に問題を生じるのは文字を格納するデータベースである。ここでは企業ユーザの多い「Microsoft SQL Server」「Oracle Database」「MySQL」を対象に、データベースで発生する問題と対処方法を解説していこう。 業務システムで問題となるのは、JIS X 0213:2004で追加された文字を従来の文字コードでは扱えないことであり、Vistaからそうした文字を入力された場合の備えができていないことである。冒頭にも述べたように、何の備えもできていないとすると、文字を正しく格納できなかったり文字列処理で予期しない結果が返ってきたりする。 具体的な現象は後ほど実験を交えて紹介するが、アプリケーションやデータベースでShift-JISを扱うようにしている場合は、間違いなくこの問題に遭遇する。この理由を簡単に説明できないから、話がややこしくなるのだが、とりあえず次のことさえ知っていればいい。
JIS X 0213:2004に対応するために追加された文字は、従来のShift-JISには入っていないがUnicodeに入っている
これを念頭においてほしい。 |
||||||||||
| もう1つの問題：サロゲートペア | ||||||||||
|
クライアントPCで使っているOSがVistaだと、これまでのOSには存在してなかった文字が入力されるかもしれないから、アプリケーションもデータベースもUnicodeで統一すればいいという話なのだろうか。それなら簡単じゃないかと思ってもいいのだが、実はもう1つ知っておくべき問題がある。 Unicodeそのものは、日本の漢字に限らずハングルなど世界中の文字を統一された文字コードで扱おうとしていた文字コードである。しかし16ビット（2バイト）で表現できる65,536種類では、到底足りないということが後になってわかった。そこで編み出されたのが、2文字分の32ビットを使って1文字を表現する方法で「サロゲートペア（補助文字）」と呼ばれている。 ここまでの内容を理解していれば想像に難くないと思うが、JIS X 0213:2004に対応するために追加された文字の一部は、サロゲートペアを使って表現されている。したがって、データベースもアプリケーションも、サロゲートペアに対応しなければならない。 ところが、サロゲートペアに対応するのは簡単ではないので、いよいよ大問題となる。 なぜなら、本来2文字分の領域を使って1文字をあらわすのだから、格納文字数が変わってくる可能性があるからだ。あるいは、文字の長さをカウントする関数の結果や、文字列の切り出しを行う関数の結果も変わってくる可能性もある。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
