Unicode の基礎

1 つのデータベースに複数言語のデータを格納する場合、文字データとコード ページのみを使用すると、管理が困難になります。また、データベース用に必要なすべての言語固有の文字を格納できる、単一のコード ページを見つけることも困難です。さらに、さまざまなコード ページを実行するクライアントがそれぞれ読み取りや更新を行う際に、特殊な文字が正しく変換されるようにすることも困難です。さまざまな国のクライアントをサポートするデータベースでは、非 Unicode データ型ではなく常に Unicode データ型を使用する必要があります。

たとえば、次の 3 つの主要言語を扱う必要がある北米の顧客データベースについて考えてみましょう。

• メキシコ向けのスペイン語の名前と住所

• ケベック向けのフランス語の名前と住所

• カナダの他の地域と米国向けの英語の名前と住所

文字型の列とコード ページのみを使用するときは、3 つの言語すべての文字を処理できるコード ページを使用してデータベースがインストールされるようにする必要があります。また、上記の中の 1 つの言語の文字が、別の言語のコード ページを実行しているクライアントで読み取られる場合は、その文字が正しく変換されるように注意する必要があります。

インターネットの発達と共に、異なるロケールを実行する多くのクライアント コンピュータをサポートすることの重要性が高まっています。世界中のユーザーが要求するすべての文字をサポートする文字データ型のコード ページを 1 つ選択することは困難です。

国際的なデータベースの文字データを管理する最も簡単な方法は、char、varchar、text などの非 Unicode データ型を使用するのではなく、常に nchar、nvarchar、nvarchar(max) などの Unicode データ型を使用することです。

Unicode は、コード ポイントを文字にマップするための標準です。Unicode は世界中のすべての言語のすべての文字を処理できるようにデザインされているので、異なる文字のセットを扱うために他のコード ページを必要とすることがありません。SQL Server では、Unicode Standard, Version 3.2 がサポートされています。

国際的なデータベースを使用するすべてのアプリケーションで、非 Unicode データ型の変数の代わりに Unicode データ型の変数を使用すれば、システム内で文字の変換を行う必要がなくなります。クライアントには、他のすべてのクライアントと同じ文字でデータが表示されます。

SQL Server では、すべてのテキスト システム カタログ データが Unicode データ型の列に格納されます。つまり、テーブル、ビュー、ストアド プロシージャなどのデータベース オブジェクトの名前が Unicode 列に格納されます。これにより、Unicode のみを使用してアプリケーションを開発できるようになり、コード ページの変換に関するあらゆる問題を回避できます。