照合順序と Unicode のサポート
適用対象:
SQL Server Analytics Platform System (PDW) Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics (すべてのサポートされているバージョン)
SQL Server の照合順序により、並べ替え規則、大文字と小文字の区別、およびアクセントの区別のプロパティをデータで利用できるようになります。 char や varchar などの文字データ型に使用する照合順序は、そのデータ型で表すことのできるコード ページおよび対応する文字を指定します。
SQL Server の新しいインスタンスをインストールする場合、データベース バックアップを復元する場合、またはサーバーをクライアント データベースに接続する場合でも、使用しているデータのロケール要件、並べ替え順序、大文字と小文字とアクセントの区別を理解することが重要です。 SQL Server のインスタンスで使用できる照合順序を一覧表示するには、「sys.fn_helpcollations (Transact-SQL)」を参照してください。
サーバー、データベース、列、または式の照合順序を選択すると、特定の特性がデータに割り当てられます。 これらの特性は、データベースのさまざまな操作の結果に影響を与えます。 たとえば、ORDER BY を使用してクエリを構築する場合、結果セットの並べ替え順序は、データベースに適用される照合順序、またはクエリの式レベルで COLLATE 句に指定される照合順序に依存します。
SQL Server で照合順序のサポートを最適に使用するには、このトピックで定義されている用語と、それがデータの特性とどのように関連付けられているかについて理解する必要があります。
照合順序の用語
照合順序
照合順序では、データセット内の各文字を表すビット パターンが指定されます。 また、照合順序はデータの並べ替えおよび比較を行うための規則を決定します。 SQL Serverでは、照合順序が異なるオブジェクトを 1 つのデータベースに格納できます。 非 Unicode 列の場合は、照合順序の設定によってデータのコード ページと表示可能な文字が指定されます。 非 Unicode 列の間でデータを移動する場合は、移動元のコード ページから移動先のコード ページに変換する必要があります。
Transact-SQLステートメントの結果は、照合順序の設定が異なる異なるデータベースのコンテキストでステートメントが実行される場合に異なる場合があります。 可能であれば、組織全体で同じ照合順序を使用します。 これにより、すべての文字または Unicode 表現で照合順序を指定する必要がなくなります。 異なる照合順序とコード ページが設定されたオブジェクトを操作する場合は、照合の優先順位の規則を考慮してクエリを作成します。 詳細については、「 照合順序の優先順位 (Transact-SQL)」を参照してください。
照合順序に関連するオプションは、大文字と小文字の区別、アクセントの区別、かなの区別、および文字幅の区別、バリエーションの選択の区別です。 SQL Server 2019 (15.x) では、UTF-8 エンコードの追加オプションが導入されています。
これらのオプションは、照合順序の名前に付加することによって指定できます。 たとえば、Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 という照合順序では、大文字と小文字、アクセント、かな、文字幅、UTF-8 エンコードが区別されます。 また、Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS という照合順序では、大文字小文字とアクセントが区別されず、かな、文字幅、異体字セレクターが区別され、非 Unicode エンコードが使用されます。
次の表では、これらのさまざまなオプションに関連付けられている動作を説明します。
| オプション | 説明 |
|---|---|
| 大文字と小文字を区別する (_CS) | 大文字と小文字を区別します。 このオプションを選択すると、大文字より先に小文字が並べ替えられます。 このオプションを選択しないと、照合順序で大文字と小文字が区別されません。 つまり、大文字と小文字は、並べ替えを行う際に同じものと見なされます。 大文字と小文字を区別しないことを明示的に選択するには、_CI と指定します。 |
| アクセントを区別する (_AS) | アクセントのある文字とアクセントのない文字を区別します。 たとえば、"a" と "ấ" は等しくありません。 このオプションを選択しないと、照合順序でアクセントが区別されません。 つまり、アクセントのある文字とアクセントのない文字は、並べ替えを行う際に同じものと見なされます。 アクセントを区別しないことを明示的に選択するには、_AI と指定します。 |
| かなを区別する (_KS) | 次の 2 種類の日本語かな文字を区別します。ひらがなとカタカナ。 このオプションを選択しないと、照合順序でかなが区別されません。 つまり、ひらがなとカタカナは、並べ替えを行う際に同じものと見なされます。 かなを区別しないように指定する唯一の方法は、このオプションを省略することです。 |
| 文字幅を区別する (_WS) | 全角文字と半角文字を区別します。 このオプションを選択しない場合、SQL Server では、同じ文字の全角表現と半角表現が並べ替え目的で同一と見なされます。 文字幅を区別しないように指定する唯一の方法は、このオプションを省略することです。 |
| バリエーションの選択を区別する (_VSS) | SQL Server 2017 (14.x) で導入された日本語の照合順序 Japanese_Bushu_Kakusu_140 と Japanese_XJIS_140 のさまざまな表文字バリエーション セレクターを区別します。 バリエーションのシーケンスは、基本文字と追加のバリエーションの選択で構成されます。 このオプション_VSS選択されていない場合、照合順序はバリエーション セレクターを区別しません。また、比較ではバリエーション セレクターは考慮されません。 つまり、SQL Server異なるバリエーション セレクターを持つ同じ基本文字上に構築された文字は、並べ替え目的で同一と見なされます。 詳細については、「Unicode 表意文字のバリエーション データベース」を参照してください。 フルテキスト検索インデックスでは_VSSセレクターを区別する (_VSS) 照合順序はサポートされていません。 全文検索インデックスでは、アクセントを区別する (_AS)、かなを区別する (_KS)、文字幅を区別する (_WS) オプションのみがサポートされます。 SQL Server XML および CLR エンジンでは、(_VSS) バリエーション セレクターはサポートされていません。 |
| バイナリ (_BIN)1 | 各文字に定義されているビット パターンSQL Serverテーブル内のデータを並べ替え、比較します。 バイナリ並べ替え順では、大文字と小文字が区別され、アクセントが区別されます。 また、バイナリは最速の並べ替え順です。 詳細については、この記事の「バイナリ照合順序」セクションを参照してください。 |
| バイナリ コード ポイント (_BIN2)1 | Unicode データの Unicode コード ポイントに基SQL Serverテーブル内のデータを並べ替え、比較します。 非 Unicode データの場合、バイナリ コード ポイントではバイナリ並べ替えと同一の比較が使用されます。 バイナリ コード ポイントの並べ替え順序を使用する利点は、並べ替えされたデータとデータを比較するアプリケーションでは、データのSQL Serverです。 このため、バイナリ コード ポイント並べ替え順を使用すると、アプリケーション開発が簡略化され、パフォーマンスを向上させることができます。 詳細については、この記事の「バイナリ照合順序」セクションを参照してください。 |
| UTF-8 (_UTF8) | UTF-8 でエンコードされたデータを 2 つのデータ に格納SQL Server。 このオプションが選択されていない場合、SQL Serverデータ型に既定の非 Unicode エンコード形式が使用されます。 詳細については、この記事の「UTF-8 サポート」セクションを参照してください。 |
1 バイナリまたはバイナリ コード ポイントが選択されている場合、大文字と小文字を区別する (_CS)、アクセントを区別する (_AS)、かなを区別する (_KS)、および幅を区別する (_WS) オプションは使用できません。
照合順序オプションの例
各照合順序は、大文字小文字、アクセント、文字幅、かなの区別を定義する一連のサフィックスとして組み合わせられます。 次の例で、サフィックスのさまざまな組み合わせに対応する並べ替え順の動作を説明します。
| Windows 照合順序サフィックス | 並べ替え順の説明 |
|---|---|
| _BIN 1 | バイナリ並べ替え |
| _BIN2 1、2 | バイナリコード ポイント並べ替え順 |
| _CI_AI 2 | 大文字小文字を区別しない、アクセントを区別しない、かなを区別しない、文字幅を区別しない |
| _CI_AI_KS 2 | 大文字小文字を区別しない、アクセントを区別しない、かなを区別する、文字幅を区別しない |
| _CI_AI_KS_WS 2 | 大文字小文字を区別しない、アクセントを区別しない、かなを区別する、文字幅を区別する |
| _CI_AI_WS 2 | 大文字小文字を区別しない、アクセントを区別しない、かなを区別しない、文字幅を区別する |
| _CI_AS 2 | 大文字小文字を区別しない、アクセントを区別する、かなを区別しない、文字幅を区別しない |
| _CI_AS_KS 2 | 大文字小文字を区別しない、アクセントを区別する、かなを区別する、文字幅を区別しない |
| _CI_AS_KS_WS 2 | 大文字小文字を区別しない、アクセントを区別する、かなを区別する、文字幅を区別する |
| _CI_AS_WS 2 | 大文字小文字を区別しない、アクセントを区別する、かなを区別しない、文字幅を区別する |
| _CS_AI 2 | 大文字小文字を区別する、アクセントを区別しない、かなを区別しない、文字幅を区別しない |
| _CS_AI_KS 2 | 大文字小文字を区別する、アクセントを区別しない、かなを区別する、文字幅を区別しない |
| _CS_AI_KS_WS 2 | 大文字小文字を区別する、アクセントを区別しない、かなを区別する、文字幅を区別する |
| _CS_AI_WS 2 | 大文字小文字を区別する、アクセントを区別しない、かなを区別しない、文字幅を区別する |
| _CS_AS 2 | 大文字小文字を区別する、アクセントを区別する、かなを区別しない、文字幅を区別しない |
| _CS_AS_KS 2 | 大文字小文字を区別する、アクセントを区別する、かなを区別する、文字幅を区別しない |
| _CS_AS_KS_WS 2 | 大文字小文字を区別する、アクセントを区別する、かなを区別する、文字幅を区別する |
| _CS_AS_WS 2 | 大文字小文字を区別する、アクセントを区別する、かなを区別しない、文字幅を区別する |
1 バイナリまたはバイナリ コード ポイントが選択されている場合、大文字と小文字を区別する (_CS)、アクセントを区別する (_AS)、かなを区別する (_KS)、および幅を区別する (_WS) オプションは使用できません。
2 UTF-8 オプション (_UTF8) を追加すると、UTF-8 を使用して Unicode データをエンコードできます。 詳細については、この記事の「UTF-8 サポート」セクションを参照してください。
照合順序セット
SQL Serverは、次の照合順序セットをサポートしています。
Windows 照合順序
Windows 照合順序では、関連する Windows システム ロケールに基づく文字データを格納するための規則が定義されています。 Windows 照合順序では、非 Unicode データの比較を、Unicode データと同じアルゴリズムを使用して実装できます。 基本の Windows 照合順序規則では、辞書順の並べ替えが適用される場合に使用されるアルファベットまたは言語が指定されています。 また、規則では非 Unicode 文字データの格納に使用されるコード ページも指定されています。 Unicode 順の並べ替えと非 Unicode 順の並べ替えは、いずれも、特定のバージョンの Windows の文字列比較と互換性があります。 これにより、SQL Server 内のデータ型間の一貫性が提供され、開発者は SQL Server で使用されるのと同じ規則を使用して、アプリケーション内の文字列を並べ替えできます。 詳細については、「Windows 照合順序名 (Transact-SQL)」を参照してください。
バイナリ照合順序
バイナリ照合順序では、ロケールおよびデータ型によって定義されるコーディングされた値の順序に基づいてデータを並べ替えます。 大文字と小文字が区別されます。 のバイナリ照合順序SQL Serverロケールと、使用される ANSI コード ページを定義します。 また、バイナリ並べ替え順を実施します。 これらは比較的単純なので、バイナリ照合順序はアプリケーションのパフォーマンスを向上させるために役立ちます。 非 Unicode データ型の場合は、ANSI コード ページで定義されているコード ポイントに基づいてデータが比較されます。 Unicode データ型の場合は、Unicode コード ポイントに基づいてデータが比較されます。 Unicode データ型のバイナリ照合順序では、データを並べ替える際にロケールが考慮されません。 たとえば、Unicode データに対して Latin_1_General_BIN と Japanese_BIN を使用した場合、並べ替え結果はどちらも同じになります。 詳細については、「Windows 照合順序名 (Transact-SQL)」を参照してください。
バイナリ照合順序には、次の 2 種類SQL Server。
以前の BIN 照合順序では、Unicode データに対して不完全なコード ポイント間比較が行われていました。 以前のこのようなバイナリ照合順序では、最初の文字が WCHAR として比較された後、続いてバイト単位の比較が行われていました。 BIN 照合順序では、最初の文字のみがコード ポイントに従って並べ替えられ、残りの文字はバイト値に従って並べ替えられます。
新しい BIN2 照合順序では、純粋なコード ポイント比較が実装されます。 BIN2 照合順序では、すべての文字がコード ポイントに従って並べ替えられます。 Intel プラットフォームはリトル エンディアン アーキテクチャであるため、Unicode コード文字は常にバイト スワップして格納されます。
SQL Server 照合順序
SQL Server照合順序 (SQL_*) を使用すると、以前のバージョンの照合順序と並べ替え順序SQL Server。 非 Unicode データについては、辞書順での並べ替え規則は Windows オペレーティング システムによって提供されるどの並べ替えルーチンとも互換性はありません。 ただし、Unicode データの並べ替えは、特定のバージョンの Windows 並べ替え規則と互換性があります。 照合SQL Server Unicode 以外のデータと Unicode 以外のデータに対して異なる比較規則を使用します。このため、基になるデータ型に応じて、同じデータの比較に対して異なる結果が表示されます。 詳細については、「SQL Server 照合順序名 (Transact-SQL)」を参照してください。
セットアップSQL Server、既定のインストール照合順序の設定は、オペレーティング システム (OS) のロケールによって決まります。 サーバーレベルの照合順序は、セットアップ中に変更するか、インストール前に OS ロケールを変更することで変更できます。 下位互換性のため、既定の照合順序は、特定のロケール別に関連付けられている中で最も古いバージョンに設定されます。 そのため、これが常に推奨される照合順序になるとは限りません。 これらの機能を完全に活用SQL Server照合順序を使用する既定のインストール設定Windows変更します。 たとえば、OS のロケールが "英語 (米国)" (コード ページ 1252) の場合、セットアップ中、既定の照合順序は SQL_Latin1_General_CP1_CI_AS になります。これは Windows 照合順序でそれに最も近い Latin1_General_100_CI_AS_SC に変更できます。
Note
SQL Server の英語のインスタンスをアップグレードするときに、SQL Server 照合順序 (SQL_*) を指定して、SQL Server の既存のインスタンスとの互換性を確保できます。 SQL Server のインスタンスの既定の照合順序はセットアップ時に定義されます。このため、次の条件に該当する場合は、照合順序の設定を慎重に指定してください。
- アプリケーション コードは、以前の照合順序の動作SQL Server異なります。
- 複数の言語に対応する文字データを格納する必要がある場合。
照合順序レベル
照合順序の設定は、 のインスタンスの次のレベルでサポートSQL Server。
サーバーレベルの照合順序
既定のサーバー照合順序は、SQL Server中に決定され、システム データベースとすべてのユーザー データベースの既定の照合順序になります。
次の表は、オペレーティング システム (OS) ロケールによって決定される既定の照合順序指定をまとめたものです。Windows と SQL 言語コード識別子 (LCID) が含まれています。
| Windows ロケール | Windows LCID | SQL LCID | 既定の照合順序 |
|---|---|---|---|
| アフリカーンス語 (南アフリカ) | 0x0436 | 0x0409 | Latin1_General_CI_AS |
| アルバニア語 (アルバニア) | 0x041c | 0x041c | Albanian_CI_AS |
| アルザス語 (フランス) | 0x0484 | 0x0409 | Latin1_General_CI_AS |
| アムハラ語 (エチオピア) | 0x045e | 0x0409 | Latin1_General_CI_AS |
| アラビア語 (アルジェリア) | 0x1401 | 0x0401 | Arabic_CI_AS |
| アラビア語 (バーレーン) | 0x3c01 | 0x0401 | Arabic_CI_AS |
| アラビア語 (エジプト) | 0x0c01 | 0x0401 | Arabic_CI_AS |
| アラビア語 (イラク) | 0x0801 | 0x0401 | Arabic_CI_AS |
| アラビア語 (ヨルダン) | 0x2c01 | 0x0401 | Arabic_CI_AS |
| アラビア語 (クウェート) | 0x3401 | 0x0401 | Arabic_CI_AS |
| アラビア語 (レバノン) | 0x3001 | 0x0401 | Arabic_CI_AS |
| アラビア語 (リビア) | 0x1001 | 0x0401 | Arabic_CI_AS |
| アラビア語 (モロッコ) | 0x1801 | 0x0401 | Arabic_CI_AS |
| アラビア語 (オマーン) | 0x2001 | 0x0401 | Arabic_CI_AS |
| アラビア語 (カタール) | 0x4001 | 0x0401 | Arabic_CI_AS |
| アラビア語 (サウジアラビア) | 0x0401 | 0x0401 | Arabic_CI_AS |
| アラビア語 (シリア) | 0x2801 | 0x0401 | Arabic_CI_AS |
| アラビア語 (チュニジア) | 0x1c01 | 0x0401 | Arabic_CI_AS |
| アラビア語 (U.A.E.) | 0x3801 | 0x0401 | Arabic_CI_AS |
| アラビア語 (イエメン) | 0x2401 | 0x0401 | Arabic_CI_AS |
| アルメニア語 (アルメニア) | 0x042b | 0x0419 | Latin1_General_CI_AS |
| アッサム語 (インド) | 0x044d | 0x044d | サーバー レベルでは利用できません |
| アゼルバイジャン語 (アゼルバイジャン、キリル) | 0x082c | 0x082c | 非推奨。サーバー レベルでは利用できません |
| アゼルバイジャン語 (アゼルバイジャン、ラテン) | 0x042c | 0x042c | 非推奨。サーバー レベルでは利用できません |
| バシキール語 (ロシア) | 0x046d | 0x046d | Latin1_General_CI_AI |
| バスク語 (バスク) | 0x042d | 0x0409 | Latin1_General_CI_AS |
| ベラルーシ語 (ベラルーシ) | 0x0423 | 0x0419 | Cyrillic_General_CI_AS |
| ベンガル語 (バングラデシュ) | 0x0845 | 0x0445 | サーバー レベルでは利用できません |
| ベンガル語 (インド) | 0x0445 | 0x0439 | サーバー レベルでは利用できません |
| ボスニア語 (ボスニア・ヘルツェゴビナ、キリル文字) | 0x201a | 0x201a | Latin1_General_CI_AI |
| ボスニア語 (ボスニア・ヘルツェゴビナ、ラテン文字) | 0x141a | 0x141a | Latin1_General_CI_AI |
| ブルトン語 (フランス) | 0x047e | 0x047e | Latin1_General_CI_AI |
| ブルガリア語 (ブルガリア) | 0x0402 | 0x0419 | Cyrillic_General_CI_AS |
| カタルニア語 (カタルニア) | 0x0403 | 0x0409 | Latin1_General_CI_AS |
| 中国語 (中華人民共和国香港特別行政区) | 0x0c04 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| 中国語 (中華人民共和国マカオ特別行政区) | 0x1404 | 0x1404 | Latin1_General_CI_AI |
| 中国語 (マカオ) | 0x21404 | 0x21404 | Latin1_General_CI_AI |
| 中国語 (中華人民共和国) | 0x0804 | 0x0804 | Chinese_PRC_CI_AS |
| 中国語 (中華人民共和国) | 0x20804 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| 中国語 (シンガポール) | 0x1004 | 0x0804 | Chinese_PRC_CI_AS |
| 中国語 (シンガポール) | 0x21004 | 0x20804 | Chinese_PRC_Stroke_CI_AS |
| 中国語 (台湾) | 0x30404 | 0x30404 | Chinese_Taiwan_Bopomofo_CI_AS |
| 中国語 (台湾) | 0x0404 | 0x0404 | Chinese_Taiwan_Stroke_CI_AS |
| コルシカ語 (フランス) | 0x0483 | 0x0483 | Latin1_General_CI_AI |
| クロアチア語 (ボスニア・ヘルツェゴビナ、ラテン文字) | 0x101a | 0x041a | Croatian_CI_AS |
| クロアチア語 (クロアチア) | 0x041a | 0x041a | Croatian_CI_AS |
| チェコ語 (チェコ共和国) | 0x0405 | 0x0405 | Czech_CI_AS |
| デンマーク語 (デンマーク) | 0x0406 | 0x0406 | Danish_Norwegian_CI_AS |
| ダリー語 (アフガニスタン) | 0x048c | 0x048c | Latin1_General_CI_AI |
| ディベヒ語 (モルディブ) | 0x0465 | 0x0465 | サーバー レベルでは利用できません |
| オランダ語 (ベルギー) | 0x0813 | 0x0409 | Latin1_General_CI_AS |
| オランダ語 (オランダ) | 0x0413 | 0x0409 | Latin1_General_CI_AS |
| 英語 (オーストラリア) | 0x0c09 | 0x0409 | Latin1_General_CI_AS |
| 英語 (ベリーズ) | 0x2809 | 0x0409 | Latin1_General_CI_AS |
| 英語 (カナダ) | 0x1009 | 0x0409 | Latin1_General_CI_AS |
| 英語 (カリブ) | 0x2409 | 0x0409 | Latin1_General_CI_AS |
| 英語 (インド) | 0x4009 | 0x0409 | Latin1_General_CI_AS |
| 英語 (アイルランド) | 0x1809 | 0x0409 | Latin1_General_CI_AS |
| 英語 (ジャマイカ) | 0x2009 | 0x0409 | Latin1_General_CI_AS |
| 英語 (マレーシア) | 0x4409 | 0x0409 | Latin1_General_CI_AS |
| 英語 (ニュージーランド) | 0x1409 | 0x0409 | Latin1_General_CI_AS |
| 英語 (フィリピン) | 0x3409 | 0x0409 | Latin1_General_CI_AS |
| 英語 (シンガポール) | 0x4809 | 0x0409 | Latin1_General_CI_AS |
| 英語 (南アフリカ) | 0x1c09 | 0x0409 | Latin1_General_CI_AS |
| 英語 (トリニダード・トバゴ) | 0x2c09 | 0x0409 | Latin1_General_CI_AS |
| 英語 (イギリス) | 0x0809 | 0x0409 | Latin1_General_CI_AS |
| 英語 (米国) | 0x0409 | 0x0409 | SQL_Latin1_General_CP1_CI_AS |
| 英語 (ジンバブエ) | 0x3009 | 0x0409 | Latin1_General_CI_AS |
| エストニア語 (エストニア) | 0x0425 | 0x0425 | Estonian_CI_AS |
| フェロー語 (フェロー諸島) | 0x0438 | 0x0409 | Latin1_General_CI_AS |
| フィリピノ語 (フィリピン) | 0x0464 | 0x0409 | Latin1_General_CI_AS |
| フィンランド語 (フィンランド) | 0x040b | 0x040b | Finnish_Swedish_CI_AS |
| フランス語 (ベルギー) | 0x080c | 0x040c | French_CI_AS |
| フランス語 (カナダ) | 0x0c0c | 0x040c | French_CI_AS |
| フランス語 (フランス) | 0x040c | 0x040c | French_CI_AS |
| フランス語 (ルクセンブルク) | 0x140c | 0x040c | French_CI_AS |
| フランス語 (モナコ) | 0x180c | 0x040c | French_CI_AS |
| フランス語 (スイス) | 0x100c | 0x040c | French_CI_AS |
| フリジア語 (オランダ) | 0x0462 | 0x0462 | Latin1_General_CI_AI |
| ガリシア語 | 0x0456 | 0x0409 | Latin1_General_CI_AS |
| グルジア語 (グルジア) | 0x10437 | 0x10437 | Georgian_Modern_Sort_CI_AS |
| グルジア語 (グルジア) | 0x0437 | 0x0419 | Latin1_General_CI_AS |
| ドイツ語 - 電話帳ソート (DIN) | 0x10407 | 0x10407 | German_PhoneBook_CI_AS |
| ドイツ語 (オーストリア) | 0x0c07 | 0x0409 | Latin1_General_CI_AS |
| ドイツ語 (ドイツ) | 0x0407 | 0x0409 | Latin1_General_CI_AS |
| ドイツ語 (リヒテンシュタイン) | 0x1407 | 0x0409 | Latin1_General_CI_AS |
| ドイツ語 (ルクセンブルク) | 0x1007 | 0x0409 | Latin1_General_CI_AS |
| ドイツ語 (スイス) | 0x0807 | 0x0409 | Latin1_General_CI_AS |
| ギリシャ語 (ギリシャ) | 0x0408 | 0x0408 | Greek_CI_AS |
| グリーンランド語 (グリーンランド) | 0x046f | 0x0406 | Danish_Norwegian_CI_AS |
| グジャラート語 (インド) | 0x0447 | 0x0439 | サーバー レベルでは利用できません |
| ハウサ語 (ナイジェリア、ラテン文字) | 0x0468 | 0x0409 | Latin1_General_CI_AS |
| ヘブライ語 (イスラエル) | 0x040d | 0x040d | Hebrew_CI_AS |
| ヒンディー語 (インド) | 0x0439 | 0x0439 | サーバー レベルでは利用できません |
| ハンガリー語 (ハンガリー) | 0x040e | 0x040e | Hungarian_CI_AS |
| ハンガリー語 (技術的な並べ替え) | 0x1040e | 0x1040e | Hungarian_Technical_CI_AS |
| アイスランド語 (アイスランド) | 0x040f | 0x040f | Icelandic_CI_AS |
| イボ語 (ナイジェリア) | 0x0470 | 0x0409 | Latin1_General_CI_AS |
| インドネシア語 (インドネシア) | 0x0421 | 0x0409 | Latin1_General_CI_AS |
| イヌクティトット語 (カナダ、ラテン文字) | 0x085d | 0x0409 | Latin1_General_CI_AS |
| イヌクティトット語 (音節文字) カナダ | 0x045d | 0x045d | Latin1_General_CI_AI |
| アイルランド語 (アイルランド) | 0x083c | 0x0409 | Latin1_General_CI_AS |
| イタリア語 (イタリア) | 0x0410 | 0x0409 | Latin1_General_CI_AS |
| イタリア語 (スイス) | 0x0810 | 0x0409 | Latin1_General_CI_AS |
| 日本語 (日本 XJIS) | 0x0411 | 0x0411 | Japanese_CI_AS |
| 日本語 (日本) | 0x040411 | 0x40411 | Latin1_General_CI_AI |
| カンナダ語 (インド) | 0x044b | 0x0439 | サーバー レベルでは利用できません |
| カザフ語 (カザフスタン) | 0x043f | 0x043f | Kazakh_90_CI_AS |
| クメール語 (カンボジア) | 0x0453 | 0x0453 | サーバー レベルでは利用できません |
| キチェ語 (グアテマラ) | 0x0486 | 0x0c0a | Modern_Spanish_CI_AS |
| キニヤルワンダ語 (ルワンダ) | 0x0487 | 0x0409 | Latin1_General_CI_AS |
| コーンクニー語 (インド) | 0x0457 | 0x0439 | サーバー レベルでは利用できません |
| 韓国語 (韓国語辞書並べ替え) | 0x0412 | 0x0412 | Korean_Wansung_CI_AS |
| キルギス語 (キルギスタン共和国) | 0x0440 | 0x0419 | Cyrillic_General_CI_AS |
| ラオス語 (ラオス人民民主共和国) | 0x0454 | 0x0454 | サーバー レベルでは利用できません |
| ラトビア語 (ラトビア) | 0x0426 | 0x0426 | Latvian_CI_AS |
| リトアニア語 (リトアニア) | 0x0427 | 0x0427 | Lithuanian_CI_AS |
| 下ソルブ語 (ドイツ) | 0x082e | 0x0409 | Latin1_General_CI_AS |
| ルクセンブルク語 (ルクセンブルク) | 0x046e | 0x0409 | Latin1_General_CI_AS |
| マケドニア語 (北マケドニア、FYROM) | 0x042f | 0x042f | Macedonian_FYROM_90_CI_AS |
| マレー語 (ブルネイ・ダルサラーム国) | 0x083e | 0x0409 | Latin1_General_CI_AS |
| マレー語 (マレーシア) | 0x043e | 0x0409 | Latin1_General_CI_AS |
| マラヤーラム語 (インド) | 0x044c | 0x0439 | サーバー レベルでは利用できません |
| マルタ語 (マルタ) | 0x043a | 0x043a | Latin1_General_CI_AI |
| マオリ語 (ニュージーランド) | 0x0481 | 0x0481 | Latin1_General_CI_AI |
| マプ語 (チリ) | 0x047a | 0x047a | Latin1_General_CI_AI |
| マラーティー語 (インド) | 0x044e | 0x0439 | サーバー レベルでは利用できません |
| モホーク語 (カナダ) | 0x047c | 0x047c | Latin1_General_CI_AI |
| モンゴル語 (モンゴル) | 0x0450 | 0x0419 | Cyrillic_General_CI_AS |
| モンゴル語 (PRC) | 0x0850 | 0x0419 | Cyrillic_General_CI_AS |
| ネパール語 (ネパール) | 0x0461 | 0x0461 | サーバー レベルでは利用できません |
| ノルウェー語 (ブークモール、ノルウェー) | 0x0414 | 0x0414 | Latin1_General_CI_AI |
| ノルウェー語 (ニーノシュク、ノルウェー) | 0x0814 | 0x0414 | Latin1_General_CI_AI |
| オクシタン語 (フランス) | 0x0482 | 0x040c | French_CI_AS |
| オディア語 (インド) | 0x0448 | 0x0439 | サーバー レベルでは利用できません |
| パシュトゥー語 (アフガニスタン) | 0x0463 | 0x0463 | サーバー レベルでは利用できません |
| ペルシア語 (イラン) | 0x0429 | 0x0429 | Latin1_General_CI_AI |
| ポーランド語 (ポーランド) | 0x0415 | 0x0415 | Polish_CI_AS |
| ポルトガル語 (ブラジル) | 0x0416 | 0x0409 | Latin1_General_CI_AS |
| ポルトガル語 (ポルトガル) | 0x0816 | 0x0409 | Latin1_General_CI_AS |
| パンジャーブ語 (インド) | 0x0446 | 0x0439 | サーバー レベルでは利用できません |
| ケチュア語 (ボリビア) | 0x046b | 0x0409 | Latin1_General_CI_AS |
| ケチュア語 (エクアドル) | 0x086b | 0x0409 | Latin1_General_CI_AS |
| ケチュア語 (ペルー) | 0x0c6b | 0x0409 | Latin1_General_CI_AS |
| ルーマニア語 (ルーマニア) | 0x0418 | 0x0418 | Romanian_CI_AS |
| ロマンシュ語 (スイス) | 0x0417 | 0x0417 | Latin1_General_CI_AI |
| ロシア語 (ロシア) | 0x0419 | 0x0419 | Cyrillic_General_CI_AS |
| サハ語 (ロシア) | 0x0485 | 0x0485 | Latin1_General_CI_AI |
| サーミ語 (イナリ、フィンランド) | 0x243b | 0x083b | Latin1_General_CI_AI |
| サーミ語 (ルレ、ノルウェー) | 0x103b | 0x043b | Latin1_General_CI_AI |
| サーミ語 (ルレ、スウェーデン) | 0x143b | 0x083b | Latin1_General_CI_AI |
| サーミ語 (北、フィンランド) | 0x0c3b | 0x083b | Latin1_General_CI_AI |
| サーミ語 (北、ノルウェー) | 0x043b | 0x043b | Latin1_General_CI_AI |
| サーミ語 (北、スウェーデン) | 0x083b | 0x083b | Latin1_General_CI_AI |
| サーミ語 (スコルト、フィンランド) | 0x203b | 0x083b | Latin1_General_CI_AI |
| サーミ語 (南、ノルウェー) | 0x183b | 0x043b | Latin1_General_CI_AI |
| サーミ語 (南、スウェーデン) | 0x1c3b | 0x083b | Latin1_General_CI_AI |
| サンスクリット語 (インド) | 0x044f | 0x0439 | サーバー レベルでは利用できません |
| セルビア語 (ボスニア・ヘルツェゴビナ、キリル文字) | 0x1c1a | 0x0c1a | Latin1_General_CI_AI |
| セルビア語 (ボスニア・ヘルツェゴビナ、ラテン文字) | 0x181a | 0x081a | Latin1_General_CI_AI |
| セルビア語 (セルビア、キリル文字) | 0x0c1a | 0x0c1a | Latin1_General_CI_AI |
| セルビア語 (セルビア、ラテン文字) | 0x081a | 0x081a | Latin1_General_CI_AI |
| セソト サ レボア語/北ソト語 (南アフリカ) | 0x046c | 0x0409 | Latin1_General_CI_AS |
| セツワナ語/ツワナ語 (南アフリカ) | 0x0432 | 0x0409 | Latin1_General_CI_AS |
| シンハラ語 (スリランカ) | 0x045b | 0x0439 | サーバー レベルでは利用できません |
| スロバキア語 (スロバキア) | 0x041b | 0x041b | Slovak_CI_AS |
| スロベニア語 (スロベニア) | 0x0424 | 0x0424 | Slovenian_CI_AS |
| スペイン語 (アルゼンチン) | 0x2c0a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (ボリビア) | 0x400a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (チリ) | 0x340a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (コロンビア) | 0x240a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (コスタリカ) | 0x140a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (ドミニカ共和国) | 0x1c0a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (エクアドル) | 0x300a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (エルサルバドル) | 0x440a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (グアテマラ) | 0x100a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (ホンジュラス) | 0x480a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (メキシコ) | 0x080a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (ニカラグア) | 0x4c0a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (パナマ) | 0x180a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (パラグアイ) | 0x3c0a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (ペルー) | 0x280a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (プエルトリコ) | 0x500a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (スペイン) | 0x0c0a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (スペイン、トラディショナル ソート) | 0x040a | 0x040a | Traditional_Spanish_CI_AS |
| スペイン語 (米国) | 0x540a | 0x0409 | Latin1_General_CI_AS |
| スペイン語 (ウルグアイ) | 0x380a | 0x0c0a | Modern_Spanish_CI_AS |
| スペイン語 (ベネズエラ) | 0x200a | 0x0c0a | Modern_Spanish_CI_AS |
| スワヒリ語 (ケニア) | 0x0441 | 0x0409 | Latin1_General_CI_AS |
| スウェーデン語 (フィンランド) | 0x081d | 0x040b | Finnish_Swedish_CI_AS |
| スウェーデン語 (スウェーデン) | 0x041d | 0x040b | Finnish_Swedish_CI_AS |
| シリア語 (シリア) | 0x045a | 0x045a | サーバー レベルでは利用できません |
| タジク語 (タジキスタン) | 0x0428 | 0x0419 | Cyrillic_General_CI_AS |
| タマジット語 (アルジェリア、ラテン文字) | 0x085f | 0x085f | Latin1_General_CI_AI |
| タミール語 (インド) | 0x0449 | 0x0439 | サーバー レベルでは利用できません |
| タタール語 (ロシア) | 0x0444 | 0x0444 | Cyrillic_General_CI_AS |
| テルグ語 (インド) | 0x044a | 0x0439 | サーバー レベルでは利用できません |
| タイ語 (タイ) | 0x041e | 0x041e | Thai_CI_AS |
| チベット語 (PRC) | 0x0451 | 0x0451 | サーバー レベルでは利用できません |
| トルコ語 (トルコ) | 0x041f | 0x041f | Turkish_CI_AS |
| トルクメン語 (トルクメニスタン) | 0x0442 | 0x0442 | Latin1_General_CI_AI |
| ウイグル語 (PRC) | 0x0480 | 0x0480 | Latin1_General_CI_AI |
| ウクライナ語 (ウクライナ) | 0x0422 | 0x0422 | Ukrainian_CI_AS |
| 上ソルブ語 (ドイツ) | 0x042e | 0x042e | Latin1_General_CI_AI |
| ウルドゥー語 (パキスタン) | 0x0420 | 0x0420 | Latin1_General_CI_AI |
| ウズベク語 (ウズベキスタン、キリル文字) | 0x0843 | 0x0419 | Cyrillic_General_CI_AS |
| ウズベク語 (ウズベキスタン、ラテン文字) | 0x0443 | 0x0443 | Uzbek_Latin_90_CI_AS |
| ベトナム語 (ベトナム) | 0x042a | 0x042a | Vietnamese_CI_AS |
| ウェールズ語 (イギリス) | 0x0452 | 0x0452 | Latin1_General_CI_AI |
| ウォロフ語 (セネガル) | 0x0488 | 0x040c | French_CI_AS |
| コサ語 (南アフリカ) | 0x0434 | 0x0409 | Latin1_General_CI_AS |
| イ語 (PRC) | 0x0478 | 0x0409 | Latin1_General_CI_AS |
| ヨルバ語 (ナイジェリア) | 0x046a | 0x0409 | Latin1_General_CI_AS |
| ズールー語 (南アフリカ) | 0x0435 | 0x0409 | Latin1_General_CI_AS |
サーバーに照合順序を割り当てた後は、照合順序を簡単には変更できません。変更するには、すべてのデータベース オブジェクトとデータをエクスポートし、master データベースを再構築してから、すべてのデータベース オブジェクトとデータをインポートする必要があります。 SQL Server のインスタンスの既定の照合順序を変更する代わりに、新しいデータベースまたはデータベース列を作成するときに、目的の照合順序を指定できます。
SQL Server のインスタンスのサーバー照合順序を照会するには、関数を使用 SERVERPROPERTY します。
SELECT CONVERT(nvarchar(128), SERVERPROPERTY('collation'));
使用可能なすべての照合順序についてサーバーに照会するには、次の fn_helpcollations() 組み込み関数を使用します。
SELECT * FROM sys.fn_helpcollations();
Azure SQL Database ではインスタンス レベルの照合順序を変更または設定することはできません。 SQL Managed Instance と SQL Server の詳細については、「サーバーの照合順序の設定または変更」を参照してください。
データベースレベルの照合順序
データベースを作成または変更するときに、CREATE DATABASE または ALTER DATABASE ステートメントの COLLATE 句を使用して、データベースの既定の照合順序を指定できます。 照合順序が指定されない場合、データベースにはサーバーの照合順序が割り当てられます。
サーバーの照合順序を変更する以外に、システム データベースの照合順序を変更する方法はありません。
データベースの照合順序は、データベース内のすべてのメタデータで使用され、データベース内で使用されるすべての文字列型の列、一時オブジェクト、変数名、およびその他のすべての文字列の既定値になります。 ユーザー データベースの照合順序を変更する場合は、データベースのクエリが一時テーブルにアクセスするときに照合順序が競合する可能性があります。 一時テーブルは常に tempdb システム データベースに格納され、このデータベースではインスタンスの照合順序が使用されます。 ユーザー データベースと tempdb の文字データを比較するクエリは、文字データの評価で照合順序が競合すると、失敗します。 この問題は、クエリで COLLATE 句を指定することにより解決できます。 詳細については、「COLLATE (Transact-SQL)」を参照してください。
ユーザー データベースの照合順序は、次のような ALTER DATABASE ステートメントを使用して変更できます。
ALTER DATABASE myDB COLLATE Greek_CS_AI;
重要
データベース レベルの照合順序を変更しても、列レベルの照合順序や式レベルの照合順序には影響しません。
データベースの現在の照合順序は、次のようなステートメントを使用して取得できます。
SELECT CONVERT (nvarchar(128), DATABASEPROPERTYEX('database_name', 'collation'));
列レベルの照合順序
テーブルを作成または変更するときに、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;
Locale
ロケールは、場所またはカルチャに関連付けられる一連の情報です。 その情報には、言語の名前や ID、言語の記述に使用される文字表記、文化的慣習などが含まれる場合があります。 照合順序は、1 つ以上のロケールに関連付けることができます。 詳細については、「 Microsoft によって割り当てられているロケール ID」を参照してください。
コード ページ
コード ページは、特定の文字表記の順序付けられた文字のセットです。コード ページでは、数値インデックス (コード ポイント値) が各文字に関連付けられます。 Windows コード ページは、通常は "文字セット" または charset と呼ばれています。 コード ページは、各種の Windows システム ロケールで使用される文字セットおよびキーボード レイアウトをサポートするために使用されます。
並べ替え順序
並べ替え順序は、データ値の並べ替え方法を指定します。 その順序により、データ比較の結果が影響を受けます。 データは、照合順序を使用して並べ替えられ、インデックスを使用して最適化することができます。
Unicode のサポート
Unicode は、コード ポイントを文字にマップするための標準です。 Unicode は世界中のすべての言語のすべての文字を処理できるようにデザインされているので、異なる文字のセットを扱うために異なるコード ページは必要ありません。
Unicode の基礎
1 つのデータベースに複数言語のデータを格納する場合、文字データとコード ページのみを使用すると、管理が困難になります。 また、データベース用に必要なすべての言語固有の文字を格納できる、単一のコード ページを見つけることも困難です。 さらに、さまざまなコード ページを実行するさまざまなクライアントによって読み取りや更新が行われるときに、特殊な文字が正しく翻訳されるようにすることも困難です。 さまざまな国のクライアントをサポートするデータベースでは、非 Unicode データ型ではなく常に Unicode データ型を使用する必要があります。
たとえば、次の 3 つの主要言語を扱う必要がある北米の顧客データベースについて考えてみましょう。
- メキシコ向けのスペイン語の名前と住所
- ケベック向けのフランス語の名前と住所
- カナダの他の地域と米国向けの英語の名前と住所
文字型の列とコード ページのみを使用するときは、3 つの言語すべての文字を処理できるコード ページを使用してデータベースが確実にインストールされるようにする必要があります。 また、上記の中のいずれかの言語の文字が、別の言語のコード ページを実行しているクライアントで読み取られる場合は、その文字が正しく変換されるように注意する必要があります。
Note
クライアントが使用するコード ページは、オペレーティング システム (OS) の設定によって決まります。 Windows オペレーティング システムでクライアント コード ページを設定するには、コントロール パネルの [地域と言語のオプション] を使用します。
世界中のユーザーが要求するすべての文字をサポートする文字データ型のコード ページを 1 つ選択することは困難です。 国をまたぐデータベースで文字データを管理する最も簡単な方法は、Unicode をサポートするデータ型を常に使用することです。
Unicode データ型
複数の言語を反映する文字データを SQL Server (SQL Server 2005 (9.x) 以降) に格納する場合は、Unicode 以外のデータ型 (char、varchar、text) ではなく Unicode データ型 (nchar、nvarchar、ntext) を使用します。
Note
For Unicode data types, the Database Engine can represent up to 65,536 characters using UCS-2, or the full Unicode range (1,114,112 characters) if supplementary characters are used. 補助文字の有効化について詳しくは、「補助文字」をご覧ください。
または、SQL Server 2019 (15.x) から、UTF-8 対応照合順序 (_UTF8) が使用されている場合、以前は Unicode 以外のデータ型 (char および varchar) が UTF-8 エンコードを使用して Unicode データ型になります。 SQL Server 2019 (15.x) では、UCS-2 または UTF-16 エンコードを引き続き使用する、以前の既存の Unicode データ型 (nchar、nvarchar、ntext) の動作は変更されません。 詳しくは、「UTF-8 と UTF-16 でのストレージの相違点」をご覧ください。
Unicode の注意点
非 Unicode データ型には、多くの制限が関連付けられています。 これは、Unicode に対応していないコンピューターではコード ページの使用が 1 つに制限されているためです。 Unicode コードを使用すると、必要なコード ページ変換が少なくなるので、パフォーマンスの向上が期待できます。 Unicode 照合順序は、サーバー レベルではサポートされないため、データベース、列、式の各レベルで個別に選択する必要があります。
データをサーバーからクライアントに移動するとき、古いクライアント ドライバーでサーバー照合順序が認識されないことがあります。 これは、データを Unicode サーバーから非 Unicode クライアントに移動する場合に発生する可能性があります。 最善の対処方法は、クライアント オペレーティング システムをアップグレードして、基になるシステムの照合順序を更新することです。 クライアントにデータベース クライアント ソフトウェアがインストールされている場合は、データベース クライアント ソフトウェアにサービスの更新プログラムを適用する方法もあります。
ヒント
また、サーバー上のデータに異なる照合順序を使用してみることもできます。 クライアントのコード ページにマップする照合順序を選択します。
SQL Server (SQL Server 2012 (11.x) 以降) で使用できる UTF-16 照合順序を使用して、一部の Unicode 文字 (Windows 照合順序のみ) の検索と並べ替えを改善するには、補助文字 (_SC) の照合順序のいずれかを選択するか、バージョン 140 の照合順序のいずれかを選択します。
SQL Server 2019 (15.x) で使用できる UTF-8 照合順序を使用し、一部の Unicode 文字 (Windows 照合順序のみ) の検索と並べ替えを改善するには、UTF-8 エンコード対応の照合順序 (_UTF8) を選択する必要があります。
UTF8 フラグは、以下に適用できます。
- 補助文字 (_SC) またはバリエーション セレクターを区別する (_VSS) 認識を既にサポートしている言語照合順序
- BIN2 バイナリ照合順序
UTF8 フラグは、以下には適用できません。
- 補助文字 (_SC) またはバリエーション セレクターを区別する (_VSS) 認識をサポートしない言語照合順序
- BIN バイナリ照合順序
- SQL_* 照合順序
Unicode または非 Unicode データ型の使用に関連する問題点を評価するには、使用環境におけるパフォーマンスの違いを測定するためのシナリオをテストする必要があります。 組織内のシステムで使用する照合順序を標準化し、可能であれば Unicode サーバーおよびクライアントを配置するようにしてください。
多くの場合、SQL Server他のサーバーまたはクライアントと対話し、組織はアプリケーションとサーバー インスタンスの間で複数のデータ アクセス標準を使用する可能性があります。 SQL Serverクライアントは、次の 2 つの主な種類の 1 つになります。
- OLE DB および Open Database Connectivity (ODBC) バージョン 3.7 以降を使用する Unicode クライアント。
- DB ライブラリおよび ODBC バージョン 3.6 以前を使用する非 Unicode クライアント。
以下の表では、Unicode 型サーバーと非 Unicode 型サーバーの各種の組み合わせにおける多言語データの使用に関する情報を示します。
| サーバー | Client | 利点または制限事項 |
|---|---|---|
| Unicode | Unicode | このシナリオでは、システム全体で Unicode データが使用されるため、最高のパフォーマンスが実現され、取得されるデータが破損から保護されます。 これは、ActiveX Data Objects (ADO)、OLE DB、および ODBC バージョン 3.7 以降の場合に該当します。 |
| Unicode | 非 Unicode | このシナリオでは、特に、新しいオペレーティング システムを実行しているサーバーと、以前のバージョンの SQL Server または以前のオペレーティング システムを実行しているクライアントの間の接続では、クライアント コンピューターにデータを移動するときに制限やエラーが発生する可能性があります。 サーバー上の Unicode データは、非 Unicode クライアント上の対応するコード ページにマップしてデータを変換しようと試みます。 |
| 非 Unicode | Unicode | これは、多言語データの使用に理想的な構成とはいえません。 Unicode データを非 Unicode サーバーに書き込むことはできません。 サーバーのコード ページ内に存在しないサーバーにデータを送信すると、問題が発生する可能性があります。 |
| 非 Unicode | 非 Unicode | これは、多言語データに関して非常に制限的なシナリオです。 使用できるコード ページは 1 つだけです。 |
補助文字
Unicode Consortium では、各文字に一意のコード ポイント (000000 – 10FFFF の範囲の値) が割り当てられています。 最もよく使われる文字のコード ポイント値は 000000 – 00FFFF の範囲で (65,536 文字)、これはメモリおよびディスク上の 8 ビットまたは 16 ビット ワードに適合します。 この範囲は、通常、基本多言語面 (BMP) として指定されます。
ただし、Unicode Consortium では、さらに 16 個の文字の "面" が確立されており、それぞれ BMP と同じサイズです。 この定義により、Unicode では、000000 – 10FFFF までのコード ポイントで 1,114,112 個の文字 (つまり、216 * 17 文字) を表すことができます。 コード ポイント値が 00FFFF より大きい文字では、2 から 4 個の連続する 8 ビット ワード (UTF-8)、または 2 個の連続する 16 ビット ワード (UTF-16) が必要です。 BMP を越えて存在するこれらの文字は "補助文字" と呼ばれ、追加の連続する 8 ビット ワードまたは 16 ビット ワードは "サロゲート ペア" と呼ばれます。 補助文字、サロゲート、およびサロゲート ペアについて詳しくは、Unicode 標準をご覧ください。
SQL Serverは、UNICODE データを BMP 範囲 (0000000 – 00FFFF) に格納する nchar や nvarchar などのデータ型を提供します。これは、データベース エンジン が UCS-2 を使用してエンコードします。
SQL Server 2012 年 (11.x) には、完全な Unicode 文字範囲 (0000000 – 10FFFF) を表す nchar、nvarchar、および sql_variant データ型で使用できる補助文字 (_SC) 照合順序の新しいファミリが導入されました。 次に例を示します。Latin1_General_100_CI_AS_SC や、日本語の照合順序を使用する場合は Japanese_Bushu_Kakusu_100_CI_AS_SC を使用できます。
SQL Server 2019 (15.x) では、新しい UTF-8 対応照合順序 (_UTF8) を使用して、補助文字のサポートが char データ型と varchar データ型に拡張されています。 これらのデータ型では、完全な Unicode 文字範囲を表すこともできます。
Note
2017 SQL Server (14.x) から、すべての新しい照合順序で補助文字が自動的にサポートされます。
補助文字を使用する場合は、以下の点に注意してください。
補助文字は、90 以上の照合順序バージョンで、並べ替えと比較の操作に使用できます。
すべてのバージョン 100 の照合順序で、補助文字の言語的な並べ替えがサポートされています。
補助文字は、データベース オブジェクトの名前など、メタデータ内で使用することはできません。
SC フラグは、以下に適用できます。
- バージョン 90 照合順序
- バージョン 100 照合順序
SC フラグは、以下に適用できます。
- バージョン 80 バージョンなしの Windows 照合順序
- BIN または BIN2 バイナリ照合順序
- SQL* 照合順序
- バージョン 140 照合順序 (これらでは、補助文字が既にサポートされているので、SC フラグは必要ありません)
次の表では、一部の文字列関数と文字列演算子で、補助文字が SC 照合順序ありで使用される場合と、補助文字対応 (SCA) 照合順序なしで使用される場合の動作を比較しています。
| 文字列関数または演算子 | SCA 照合順序あり | SCA 照合順序なし |
|---|---|---|
| CHARINDEX LEN PATINDEX |
UTF-16 サロゲート ペアは、1 つのコード ポイントとしてカウントされます。 | UTF-16 サロゲート ペアは、2 つのコード ポイントとしてカウントされます。 |
| LEFT REPLACE REVERSE RIGHT SUBSTRING STUFF |
これらの関数は、各サロゲート ペアを 1 つのコード ポイントとして処理し、期待どおりに動作します。 | これらの関数では、サロゲート ペアが分割され、予期しない結果が生じることがあります。 |
| NCHAR | 0 – 0x10FFFF の範囲の指定した Unicode コード ポイント値に対応する文字が返されます。 指定した値が 0 – 0xFFFF の範囲内にある場合、1 つの文字が返されます。 値が大きい場合、対応するサロゲート ペアが返されます。 | 0 xFFFF よりも高い値の場合は、対応するサロゲートの代わりに NULL が返されます。 |
| UNICODE | 0 – 0x10FFFF の範囲の UTF-16 コード ポイントが返されます。 | 0 – 0xFFFF の範囲の UCS-2 コード ポイントが返されます。 |
| 1 文字に一致するワイルドカード ワイルドカード - 一致しない文字列 |
補助文字は、すべてのワイルドカード操作でサポートされています。 | 補助文字は、これらのワイルドカード操作でサポートされていません。 その他のワイルドカード演算子がサポートされます。 |
GB18030 サポート
GB18030 は中華人民共和国が単独で中国語の文字のエンコードに使用している標準規格です。 GB18030 文字の長さは 1 バイト、2 バイト、4 バイトのいずれかです。 SQL Server では、クライアント側アプリケーションからサーバーに入力するときに、GB18030 でエンコードされた文字を認識し、それらを Unicode 文字としてネイティブに変換して格納することで、GB18030 エンコード文字をサポートします。 それらがサーバーに格納されると、それ以降の操作では Unicode 文字として処理されます。
任意の中国語の照合順序を使用できますが、最新の 100 バージョンの使用をお勧めします。 すべてのバージョン 100 の照合順序は、GB18030 文字の言語的な並べ替えをサポートしています。 データに補助文字 (サロゲートペア) が含まれている場合は、SQL Server で使用できる SC 照合順序を使用して、検索と並べ替えを向上させることができます。
Note
SQL Server Management Studio などのクライアントツールで、Dengxian フォントを使用して、GB18030 でエンコードされた文字を含む文字列を正しく表示していることを確認します。
複雑な文字表記のサポート
SQL Server は、複雑なスクリプトの入力、格納、変更、および表示をサポートできます。 複雑な文字表記には、次の種類があります。
- アラビア語テキストと英語テキストの組み合わせなど、右から左に記述されるテキストと左から右に記述されるテキストの両方の組み合わせを含む文字表記。
- アラビア語、インド諸語、タイ語の文字など、位置によって、または別の種類の文字と組み合わせた場合に、文字が変形する文字表記。
- タイ語など、単語間に区切りがないため、単語を識別するための内部辞書を必要とする言語。
SQL Server と対話するデータベースアプリケーションでは、複雑なスクリプトをサポートするコントロールを使用する必要があります。 マネージド コードで作成される標準の Windows フォーム コントロールは、複雑な文字表記を使用できます。
SQL Server 2017 (14. x) に追加された日本語の照合順序
SQL Server 2017 (14. x) 以降では、新しい日本語の照合順序ファミリがサポートされており、さまざまなオプション (_CS、_AS、_KS、_WS、_VSS) の順列に加え、_BIN と _BIN2 も含まれています。
これらの照合順序を一覧表示するには、SQL Server データベース エンジンに対してクエリを実行します。
SELECT name, description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;
すべての新しい照合順序には補助文字の組み込みサポートがあるので、どの新しい 140 照合順序にも SC フラグはありません (または必要ありません)。
これらの照合順序はデータベース エンジン インデックス、メモリ最適化テーブル、列ストア インデックス、ネイティブ コンパイル モジュールでサポートされています。
UTF-8 のサポート
SQL Server 2019 (15. x) では、広く使用されている utf-8 文字エンコードをインポートまたはエクスポートエンコーディングとして完全にサポートし、文字列データに対してデータベースレベルまたは列レベルの照合順序を使用できます。 UTF-8 は、char および varchar データ型で許可されており、UTF8 サフィックスを持つようにオブジェクトの照合順序を作成するか変更すると有効になります。 たとえば、LATIN1_GENERAL_100_CI_AS_SC を LATIN1_GENERAL_100_CI_AS_SC_UTF8 に変更します。
utf-8 は、SQL Server 2012 (2.x) で導入された補助文字をサポートする Windows 照合順序でのみ使用できます。 nchar および nvarchar データ型では、UCS-2 または UTF-16 エンコードのみが許可され、変更されていません。
Azure SQL Database と Azure SQL Managed Instance は、データベースおよび列レベルでも UTF-8 をサポートしていますが、Managed Instance はこれがサーバー レベルでもサポートされています。
UTF-8 と UTF-16 でのストレージの相違点
Unicode Consortium では、各文字に一意のコード ポイント (000000 – 10FFFF の範囲の値) が割り当てられています。 SQL Server 2019 (15. x) では、完全な範囲を表すために utf-8 エンコードと utf-16 エンコーディングの両方を使用できます。
- UTF-8 エンコードでは、ASCII 範囲 (000000 – 00007F) の文字には 1 バイト、コード ポイント 000080 – 0007FF には 2 バイト、コード ポイント 000800 – 00FFFF には 3 バイト、コード ポイント 0010000 – 0010FFFF には 4 バイトが、それぞれ必要です。
- UTF-16 エンコードでは、コード ポイント 000000 – 00FFFF には 2 バイト、コード ポイント 0010000 – 0010FFFF には 4 バイトが必要です。
次の表では、各文字範囲およびエンコード種類に対するエンコード ストレージ バイトの一覧を示します。
| コードの範囲 (16 進) | コードの範囲 (10 進) | UTF-8 でのストレージ バイト数 1 | UTF-16 でのストレージ バイト数 1 |
|---|---|---|---|
| 000000 – 00007F | 0 – 127 | 1 | 2 |
| 000080 – 00009F 0000A0 – 0003FF 000400 – 0007FF |
128 – 159 160 – 1,023 1,024 – 2,047 |
2 | 2 |
| 000800 – 003FFF 004000 – 00FFFF |
2,048 – 16,383 16,384 – 65,535 |
3 | 2 |
| 010000 – 03FFFF2 040000 – 10FFFF2 |
65,536 – 262,1432 262,144 – 1,114,1112 |
4 | 4 |
1 "ストレージ バイト数" は、データ型のディスク上でのストレージ サイズではなく、エンコード済みのバイト長を示します。 ディスク上のストレージ サイズについて詳しくは、「nchar および nvarchar」と「char および varchar」をご覧ください。
2補助文字のコード ポイント範囲。
ヒント
CHAR(n) および VARCHAR(n)、またはNCHAR(n) および NVARCHAR(n) では、n は文字数を定義すると考えるのが一般的です。 これは、CHAR (10) 列の例では、0 – 127 の範囲の 10 個の ASCII 文字を Latin1_General_100_CI_AI などの照合順序を使用して格納できるためで、この範囲内の各文字が 1 バイトのみを使用するためです。
ただし、CHAR(n) および VARCHAR(n) では、n によって "バイト" での文字列のサイズ (0 – 8,000) が定義され、NCHAR(n) および NVARCHAR(n) では n によって "バイトペア" での文字列のサイズ (0 – 4,000) が定義されます。 n は、格納できる文字数を定義しません。
見たように、使われている文字セットによっては、適切な Unicode エンコードとデータ型を選択することで、ストレージを大幅に節約したり、現在のストレージの占有領域を増やしたりする可能性があります。 たとえば、 Latin1_General_100_CI_AI_SC_UTF8など、utf-8 が有効なラテン語の照合順序を使用する場合、列に は10バイトが格納され、0 ~ 127 の範囲で10個の ASCII 文字を保持できます。 ただし、128 – 2047 の範囲では 5 文字のみ、2048 – 65535 の範囲では 3 文字のみ保持できます。 これに対して、NCHAR(10) 列には 10 バイトペア (20 バイト) が格納されるため、0 – 65535 の範囲に 10 文字を保持できます。
データベースまたは列に UTF-8 または UTF-16 のどちらのエンコードを使うかを選択する前に、格納される文字列データの分布を考慮してください。
- 主に 0 – 127 の ASCII 範囲の場合は (英語など)、各文字に UTF-8 では 1 バイト、UTF-16 では 2 バイトが必要です。 UTF-8 を使う方がストレージに関してメリットがあります。 0 – 127 の範囲の ASCII 文字の既存の列データ型を、UTF-8 対応の照合順序を使って
NCHAR(10)からCHAR(10)に変更すると、必要なストレージが 50% 削減されます。 このように減るのは、NCHAR(10)を保存するには 20 バイト必要であるのに対し、CHAR(10)では同じ Unicode 文字列表現に 10 バイトしか必要ないためです。 - ASCII の範囲の上の、ほぼすべてのラテン語系スクリプト、およびギリシャ語、キリル語、コプト語、アルメニア語、ヘブライ語、アラビア語、シリア語、Tāna、N’Ko では、UTF-8 および UTF-16 のどちらでも、1 文字あたり 2 バイトが必要です。 これらの場合は、対応するデータ型で大きなストレージの違いはありません (たとえば、char または nchar を使う場合)。
- 主に東アジア言語のスクリプト (韓国語、中国語、日本語) の場合は、各文字に UTF-8 では 3 バイト、UTF-16 では 2 バイトが必要です。 UTF-16 を使う方がストレージに関してメリットがあります。
- 010000 – 10FFFF の範囲の文字には、UTF-8 と UTF-16 のどちらでも 4 バイト必要です。 これらの場合は、対応するデータ型でストレージの違いはありません (たとえば、char または nchar を使う場合)。
その他の考慮事項については、「国際化に対応した Transact-SQL ステートメントの記述」をご覧ください。
UTF-8 への変換
CHAR(n) と VARCHAR(n)、または NCHAR(n) と NVARCHAR(n) では、n によって、格納できる文字数ではなく、バイト ストレージのサイズが決定するため、データの切り捨てを回避するために、変換が必要なデータ型のサイズを決定することが重要です。
たとえば、日本語の文字を 180 バイト格納する NVARCHAR (100) として定義された列について考えてみましょう。 この例では現在、列データは、1 文字あたり 2 バイトを使用する UCS-2 または UTF-16 を使用してエンコードされています。 列の型を VARCHAR (200) に変換しても、データの切り捨てを防ぐことはできません。新しいデータ型で格納できるのは 200 バイトだけですが、日本語の文字は、UTF-8 でエンコードされている場合には 3 バイト必要となるからです。 そのため、データの切り捨てによるデータの損失を回避するために、列を VARCHAR(270) として定義する必要があります。
したがって、既存のデータを UTF-8 に変換する前に、予想される列定義のバイトサイズを事前に把握し、それに応じて新しいデータ型のサイズを調整する必要があります。 SQL スクリプトまたは SQL Notebook を参照してください。データサンプル GitHubでは、 DATALENGTH関数とCOLLATEステートメントを使用して、既存のデータベースの utf-8 変換操作に必要なデータ長の要件を決定します。
既存のテーブル内の列の照合順序とデータ型を変更するには、「列の照合順序の設定または変更」で説明されているいずれかの方法を使用します。
データベースの照合順序を変更して、新しいオブジェクトが既定でデータベースの照合順序を継承できるようにするか、またはサーバーの照合順序を変更して、新しいデータベースが既定でシステムの照合順序を継承できるようにするには、この記事の「関連タスク」セクションを参照してください。
関連タスク
| タスク | トピック |
|---|---|
| SQL Server のインスタンスの照合順序を設定または変更する方法について説明します。 サーバーの照合順序を変更しても、既存のデータベースの照合順序は変更されないことに注意してください。 | サーバーの照合順序の設定または変更 |
| ユーザー データベースの照合順序を設定または変更する方法について説明します。 データベースの照合順序を変更しても、既存のテーブル列の照合順序は変更されないことに注意してください。 | データベースの照合順序の設定または変更 |
| データベース内の列の照合順序を設定または変更する方法について説明します | 列の照合順序の設定または変更 |
| サーバー、データベース、または列のレベルでの照合順序の情報を取得する方法について説明します | 照合順序情報の表示 |
| Transact-SQL ステートメントを、ある言語から別の言語に容易に移行したり、複数の言語を簡単にサポートしたりできるように記述する方法について説明します | 国際化に対応した Transact-SQL ステートメントの記述 |
| エラー メッセージの言語と、日付、時刻、通貨データを使用および表示する際の設定を変更する方法について説明します | セッション言語の設定 |
関連コンテンツ
詳細については、次の関連コンテンツを参照してください。
- SQL Server ベスト プラクティス照合順序の変更
- Unicode 文字形式を使用したデータのインポートまたはエクスポート (SQL Server)
- 国際化に対応した Transact-SQL ステートメントの記述
- SQL Server ベスト プラクティス Unicode への移行 (今後は維持されません)
- Unicode コンソーシアム
- Unicode 標準
- OLE DB Driver for SQL Server の UTF-8 のサポート
- SQL Server 照合順序名 (Transact-SQL)
- Windows 照合順序名 (Transact-SQL)
- SQL Server 用の UTF-8 サポートの概要
- COLLATE (Transact-SQL)
- 照合順序の優先順位
関連項目
包含データベースの照合順序
フルテキスト インデックス作成時の言語の選択
sys.fn_helpcollations (Transact-SQL)
1 バイト文字セットとマルチバイト文字セット