次の方法で共有

照合で使用する用語

  • [アーティクル]

SQL Server 2005 の言語サポートを最大限に活用するには、このトピックで定義されている用語を理解する必要があります。

用語

  • コード ページ
  • 照合順序
  • データ型
  • グローバリゼーション
  • ロケール
  • 読み取り順
  • 並べ替え順
  • Unicode

コード ページ

コード ページは、指定したスクリプトの順序付けられた文字セットであり、それぞれの文字には数値インデックスまたはコード ポイント値が関連付けられています。Microsoft Windows コード ページは、通常は文字セットまたは charset と呼ばれています。コード ページは、各種の Windows ロケールで使用される文字セットおよびキーボード レイアウトについてサポートを提供するために使用されます。

関連トピック :クライアント コード ページの設定

トップに戻る

照合順序

照合順序は、データセット内の各文字を表すビット パターンを指定します。また、データの並べ替えおよび比較を行うための規則を決定します。SQL Server 2005 では、単一のデータベース内で異なる照合順序を使用してオブジェクトを格納することができます。つまり、SQL Server データベースの各列は、列独自の照合順序を備えることができます。非 Unicode 列の場合は、照合順序の設定によってデータのコード ページが指定され、結果として、表示可能な文字が指定されます。Unicode 列間ではデータをシームレスに移動することができます。非 Unicode 列間で移動したデータは、シームレスに移動できないため、現在のコード ページによって変換する必要があります。

Transact-SQL ステートメントの結果は、それぞれ異なる照合順序が設定されている複数のデータベースのコンテキストでステートメントが実行される場合には、データベースごとに異なります。可能であれば、組織全体で同じ照合順序を使用することをお勧めします。組織内のすべてのシステムで標準の照合順序設定を使用すれば、それぞれの文字または Unicode 表現について、照合順序を明示的に指定する必要がありません。異なる照合順序とコード ページが設定されたオブジェクトを操作する場合は、照合の優先順位のルールを考慮してクエリを作成する必要があります。詳細については、「照合順序の優先順位 (Transact-SQL)」を参照してください。

照合順序は、言語を区別するかどうか、大文字と小文字を区別するかどうか、アクセントを区別するかどうか、かなを区別するかどうか、および文字幅を区別するかどうかを特性として備えています。

SQL Server 2005 照合順序は以下のようにグループ化されます。

  • Windows 照合順序
    Windows 照合順序は、関連する Windows ロケールに基づいて文字データを格納するための規則を定義します。Windows 照合順序では、非 Unicode データの比較が、Unicode データと同じアルゴリズムを使用して実装されます。基本の Windows 照合順序規則は、非 Unicode 文字データの格納に使用されるコード ページだけでなく、辞書順の並べ替えが適用される場合にどの文字または言語が使用されるのかを指定します。Unicode 順の並べ替えと非 Unicode 順の並べ替えは、いずれも、特定のバージョンの Windows の文字列比較と互換性があります。これによって、SQL Server 内のデータ型全般にわたる一貫性が保証されると同時に、開発者は、SQL Server で使用されるのと同じ規則を使用して、つまり、Microsoft Win32 API の CompareStringW 関数を呼び出して自分のアプリケーション内で文字列を並べ替えることが可能になります。詳細については、「セットアップでの照合順序の設定」を参照してください。

  • バイナリ照合順序
    バイナリ照合順序では、ロケールおよびデータ型によって定義されるコード値のシーケンスに基づいてデータを並べ替えます。SQL Server のバイナリ照合順序は、使用する言語ロケールおよび ANSI コード ページを定義し、バイナリ並べ替え順を実施します。バイナリ照合順序は比較的単純なので、アプリケーションのパフォーマンス向上に役立ちます。非 Unicode データ型の場合は、ANSI コード ページで定義されているコード ポイントに基づいてデータが比較されます。Unicode データ型の場合は、Unicode コード ポイントに基づいてデータが比較されます。Unicode データ型のバイナリ照合順序では、データを並べ替える際にロケールが考慮されません。たとえば、Unicode データに対して Latin_1_General_BIN と Japanese_BIN を使用した場合、並べ替え結果はどちらも同じになります。

    SQL Server の以前のバイナリ照合では、Unicode データに対して不完全なコード ポイント間比較を行っていました。つまり、最初の文字を WCHAR として比較し、その後、バイト単位でデータを比較していました。旧バージョンとの互換性を維持するため、既存のバイナリ照合順序セマンティクスは変更されません。

    SQL Server 最新リリースのバイナリ照合順序には、純粋なコード ポイント比較照合順序セットが新しく追加されました。この新しいバイナリ照合順序へ移行すると、完全なコード ポイント比較を利用でき、新しいアプリケーションの開発にこの新しいバイナリ照合順序を活用できるようになります。新しいコード ポイント照合順序セマンティクスを実装する照合順序名は、新しい BIN2 サフィックスによって識別されます。さらに、BIN2 に対応する新しい比較フラグが新規バイナリ並べ替え用に追加されます。詳細については、「バイナリ照合順序の使用」を参照してください。

  • SQL Server 照合順序
    SQL Server 照合順序では、以前のバージョンの SQL Server と互換性のある並べ替え順が使用されます。SQL Server で定義される非 Unicode データ (char データ型、varchar データ型など) の場合、SQL Server 照合順序では、従来の SQL Server 並べ替え順に基づいて並べ替えが行われます。非 Unicode データについては、辞書順での並べ替え規則は Windows オペレーティング システムによって提供されるどの並べ替えルーチンとも互換性はありませんが、Unicode データの並べ替えは、特定のバージョンの Windows 並べ替え規則と互換性があります。SQL Server 照合順序では非 Unicode データと Unicode データで別々の比較規則を使用するため、基本となるデータ型によっては、同一データの比較で異なる結果が得られる場合があります。詳細については、「SQL 照合順序の使用」を参照してください。

    ms143726.note(ja-jp,SQL.90).gifメモ :
    SQL Server のインスタンスをアップグレードするときに、SQL Server の既存インスタンスとの互換性のために SQL Server 照合順序を指定することができます。SQL Server のインスタンスの既定照合順序がセットアップ時に定義されるため、次のような場合は、照合順序の設定を注意深く指定することが重要です。
    • アプリケーション コードが以前の SQL Server 照合順序の動作になんらかの方法で依存している場合。
    • SQL Server Version 6.5、または SQL Server Version 7.0 の既存のインスタンスで SQL Server 2005 レプリケーション機能を使用する予定がある場合。
    • 複数の言語に対応する文字データを格納する必要がある場合。

SQL Server 2005 が SQL Server 2005 インスタンスの以下のレベルでの照合順序の設定をサポートしている場合

  • サーバーレベルの照合順序
    SQL Server インスタンスの既定照合順序はセットアップ時に設定されます。インスタンスの既定の照合順序は、システム データベース (master、model、tempdb、msdb、distribution) の既定の照合順序にもなります。列またはデータベース以外のオブジェクトに照合順序を指定した場合、オブジェクトを削除してから再び作成する以外の方法で照合順序を変更することはできません。SQL Server インスタンスの既定の照合順序を変更する代わりに、新規データベースまたはデータベース列の作成時に照合順序を指定することができます。

    SQL Server インスタンスについてサーバーの照合順序を照会するには、次の Transact-SQL SERVERPROPERTY 関数を使用します。

    SELECT CONVERT (varchar, SERVERPROPERTY('collation'))

    使用可能なすべての照合順序についてサーバーに照会するには、次の fn_helpcollations() 組み込み関数を使用します。

    SELECT * from ::fn_helpcollations()

  • データベースレベルの照合順序
    データベースの作成時には、CREATE DATABASE ステートメントの COLLATE 句を使用して、データベースの既定照合順序を指定することができます。データベースの作成時に照合順序を指定しない場合、そのデータベースには、model データベースの既定の照合順序が設定されます。model データベースの既定の照合順序は、SQL Server インスタンスの既定の照合順序と同じです。

    ユーザー データベースの照合順序は、次のような ALTER DATABASE ステートメントを使って変更できます。

    ALTER DATABASE myDB COLLATE Greek_CS_AI

    データベースの現在の照合順序は、次のようなステートメントを使用して取得できます。

    SELECT CONVERT (varchar, DATABASEPROPERTYEX('database_name','collation'))
    ms143726.note(ja-jp,SQL.90).gifメモ :
    データベース レベルの照合順序を変更しても、ユーザー、テーブル、列の各レベルの照合順序には影響しません。

  • 列レベルの照合順序
    テーブルを作成するときは、CREATE TABLE ステートメントの COLLATE 句を使用して、個々の文字列型列の照合順序を指定することができます。テーブルの作成時に照合順序を指定しない場合、その列には、データベースの既定の照合順序が設定されます。

    列の照合順序は、次のような ALTER TABLE ステートメントを使って変更できます。

    ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR(10) COLLATE Greek_CS_AI

  • 式レベルの照合順序
    式レベルの照合順序は、ステートメントの実行時に設定され、結果セットが返される方法に影響を及ぼします。この照合順序では、ORDER BY 句が言語固有のものとなるような結果の並べ替えが可能になっています。式レベルの照合順序を実装するには、次のような COLLATE 句を使用します。

    SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI

トップに戻る

データ型

データ型とは、値の範囲、値に関して実行可能な操作、およびコンピュータのメモリでの値の格納方法を指定する定義のことです。データ型を定義すると、SQL Server では、予測可能な方法でデータを操作することが可能になります。非 Unicode 文字データ型は、char、varchar、および text です。Unicode データ型は、nchar、nvarchar、および ntext の Unicode 文字表現を使用します。複数の言語を反映する文字データを格納する場合は特に、アプリケーションで Unicode データ型を使用することをお勧めします。

関連トピック :データ型 (データベース エンジン)、データ型 (Transact-SQL)、Integration Services のデータ型

トップに戻る

グローバリゼーション

グローバリゼーションは、複数の言語およびロケールを考慮した機能およびコード デザインによってソフトウェア アプリケーションを開発するプロセスです。グローバル化されたアプリケーションのデザインでは、データの入力、処理、表示、および出力について複数のロケールおよび Unicode 対応言語を提供します。

関連トピック :SQL Server の国際化に関する注意点

トップに戻る

ロケール

ロケールは、言語の名前や ID、言語の記述に使用されるスクリプト、文化的慣習など、場所またはカルチャに関連付けられる情報のセットです。SQL Server 2005 は、Windows XP でサポートされている 135 個のすべてのロケールに対応しています。ロケールには、5 種類の中国語ロケール (中華人民共和国香港特別行政区、中華人民共和国マカオ特別行政区、中華人民共和国、シンガポール、台湾)、13 種類の英語ロケール (オーストラリア、ベリーズ、カナダ、カリブ、アイルランド、ジャマイカ、ニュージーランド、フィリピン、南アフリカ、トリニダード、英国、米国、ジンバブエ)、および 6 種類のフランス語ロケール (ベルギー、カナダ、フランス、ルクセンブルグ、モナコ、およびスイス) があります。

次の表では、Windows でサポートされている 4 つの一般的なロケール間の相違点をいくつか示します。

ロケール 英語 (米国) フランス語 (フランス) 日本語 アラブ首長国連邦

国または地域

米国

フランス

日本

アラブ首長国連邦

言語

英語

フランス語

日本語

アラビア語

記述されるスクリプト

ラテン語

ラテン語

かな、漢字

アラビア語

読み取り順

左から右

左から右

左から右

右から左

Windows 定義コード ページ

1252

1252

932

1256

時刻形式

1:00 pm

13:00

13:00

1:00 p

カレンダー

グレゴリオ暦

グレゴリオ暦

グレゴリオ暦 (ローカライズ済み)

グレゴリオ暦 (ローカライズ済み)

既定の用紙サイズ

米国レター サイズ

A4

A4

A4

小数点記号

.

,

.

,

リスト区切り文字

,

;

,

;

1000 単位の区切り文字

,

スペース

,

,

トップに戻る

読み取り順

読み取り順は、順序付けられたテキストの並びの全体的な方向であり、入力した文字の順序ではなく語句の順序に関するものです。たとえば、キーボード言語としてアラビア語を使用すると、新しい文字が常に右から左へと並べられます。ラテン語がキーボード言語である場合、新しい文字は左から右へと並べられます。

トップに戻る

並べ替え順

並べ替え順は、データ値の格納方法を指定し、データ比較の結果に影響を及ぼします。データの並べ替えは、照合順序によって実施され、インデックスを使用して最適化することができます。

関連トピック :Windows 照合順序並べ替えスタイル、インデックス

トップに戻る

Unicode

Unicode は、1 バイトではなく 2 バイトで言語の各文字を表現して、1 つの Unicode 文字セットを使って世界中のほとんどすべての言語を表現することを可能にします。Unicode は、非営利コンピュータ業界組織である Unicode Consortium によって開発されたものであり、この組織が Unicode の保守および推進を行っています。詳細については、Unicode コンソーシアムの Web サイトを参照してください。

複数の言語を反映する文字データを格納する場合は、非 Unicode データ型 (char、varchar、および text) ではなく、Unicode データ型 (nchar、nvarchar、および ntext) を常に使用してください。コード ページによる変換が少なくなるので、Unicode の使用によって大幅なパフォーマンスの向上が期待できます。非 Unicode 型コンピュータではコード ページの使用が 1 つに制限されているため、非 Unicode データ型に関連付けられる多くの制限があります。Unicode または非 Unicode データ型の使用に関連する問題点を完全に評価するには、特定の環境におけるパフォーマンスの違いを測定するためのシナリオをテストする必要があります。最低でも、サイトの照合順序を標準化し、可能な場合は Unicode サーバーおよびクライアントを配備してください。

ほとんどの場合、SQL Server インスタンスは、他のサーバーまたはクライアントとの対話処理を実行します。また、インスタンスでは、複数のデータ アクセス標準を使用できます。SQL Server クライアントは以下の 2 つの主要タイプのいずれかになります。

  • OLE DB および Open Database Connectivity (ODBC) Versions 3.7 以降を使用する Unicode クライアント
  • DB ライブラリおよび ODBC Version 3.6 以前を使用する非 Unicode クライアント

以下の表は、Unicode 型サーバーと非 Unicode 型サーバーの各種組み合わせにおける多言語データの使用に関する考慮事項を示しています。

サーバー クライアント 利点または制限事項

Unicode

Unicode

システム全体で Unicode データが使用されるため、理想的な構成となります。このシナリオでは、最高のパフォーマンスが実現され、取得されるデータが破損から保護されます。これは、Microsoft ActiveX Data Objects (ADO)、OLE DB、および ODBC Version 3.7 以降の場合に該当します。

Unicode

非 Unicode

このシナリオでは、データの格納で問題が発生する可能性はありませんが、データをクライアント コンピュータに移動するときに制約が生じることがあります。最低でも、非 Unicode クライアント上でコード ページを使用して Unicode データを変換する必要があります。

非 Unicode

Unicode

これは、多言語データの使用に理想的な構成とは言えません。Unicode データを非 Unicode サーバーに書き込むことはできません。サーバーのコード ページ内に存在しないサーバーにデータを送信すると、問題が発生する可能性があります。

非 Unicode

非 Unicode

これは、多言語データに関して非常に制限的なシナリオです。コード ページの使用は 1 つに制限されます。理想的な構成は、Unicode サーバーと Unicode クライアントの組み合わせです。

関連項目 : 「Unicode の基礎」

トップに戻る

参照

関連項目

照合順序オプションおよびインターナショナル サポート

ヘルプおよび情報

SQL Server 2005 の参考資料の入手