次の方法で共有


照合順序と Unicode のサポート

適用対象: SQL Server Azure SQL データベース Azure SQL Managed Instance Azure Synapse Analytics Analytics Platform System (PDW) Microsoft Fabric の SQL 分析エンドポイント Microsoft Fabric のウェアハウス

SQL Server の照合順序により、並べ替え規則、大文字と小文字の区別、およびアクセントの区別のプロパティをデータで利用できるようになります。 charvarchar などの文字データ型に使用する照合順序は、そのデータ型で表すことのできるコード ページおよび対応する文字を指定します。

SQL Server の新しいインスタンスをインストールしているか、データベース バックアップを復元しているか、サーバーをクライアント データベースに接続しているかに関係なく、操作するデータのロケールの要件、並べ替え順序、および大文字と小文字の区別とアクセントの区別について理解することが重要です。 SQL Server のインスタンスで使用可能な照合順序の一覧については、「sys.fn_helpcollations (Transact-SQL)」を参照してください。

サーバー、データベース、列、または式の照合順序を選択すると、特定の特性がデータに割り当てられます。 これらの特性は、データベースのさまざまな操作の結果に影響を与えます。 たとえば、ORDER BY を使用してクエリを構築する場合、結果セットの並べ替え順序は、データベースに適用される照合順序、またはクエリの式レベルで COLLATE 句に指定される照合順序に依存します。

SQL Server の照合順序サポートを最大限に利用するには、この記事で定義されている用語と、それらがデータの特性にどのように関連しているかを理解する必要があります。

照合順序の用語

照合順序

照合順序では、データセット内の各文字を表すビット パターンが指定されます。 また、照合順序はデータの並べ替えおよび比較を行うための規則を決定します。 SQL Server では、単一のデータベース内で異なる照合順序を持つオブジェクトを格納できます。 非 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) 大文字と小文字を区別します。 このオプションを選択すると、大文字より先に小文字が並べ替えられます。 このオプションを選択しないと、照合順序で大文字と小文字が区別されません。 つまり、大文字と小文字は、並べ替えを行う際に SQL Server によって同じものと見なされます。 大文字と小文字を区別しないことを明示的に選択するには、_CI と指定します。
アクセントを区別する (_AS) アクセントのある文字とアクセントのない文字を区別します。 たとえば、"a" と "ấ" は等しくありません。 このオプションを選択しないと、照合順序でアクセントが区別されません。 つまり、アクセントのある文字とアクセントのない文字は、並べ替えを行う際に SQL Server によって同じものと見なされます。 アクセントを区別しないことを明示的に選択するには、_AI と指定します。
かなを区別する (_KS) 次の 2 種類の日本語かな文字を区別します。ひらがなとカタカナ。 このオプションを選択しないと、照合順序でかなが区別されません。 つまり、ひらがなとカタカナは、並べ替えを行う際に SQL Server によって同じものと見なされます。 かなを区別しないように指定する唯一の方法は、このオプションを省略することです。
文字幅を区別する (_WS) 全角文字と半角文字を区別します。 このオプションを選択しないと、同じ文字の全角表現と半角表現は、並べ替えを行うときに SQL Server によって同じものと見なされます。 文字幅を区別しないように指定する唯一の方法は、このオプションを省略することです。
バリエーションの選択を区別する (_VSS) SQL Server 2017 (14.x)で導入された日本語の照合順序 、Japanese_Bushu_Kakusu_140Japanese_XJIS_140 で、多様な表意文字のバリエーションセレクターを区別します。 バリエーションのシーケンスは、基本文字とバリエーションセレクターで構成されます。 この _VSS オプションを選択しない場合、照合順序で異体字の選択が区別されず、比較において異体字の選択が考慮されることはありません。 つまり、SQL Server では、並べ替えが同じになるように、バリエーションの選択が異なる同じ基本文字に基づいて構築された文字が考慮されています。 詳細については、「Unicode 表意文字のバリエーション データベース」を参照してください。

異体字セレクターを区別する (_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 でエンコードされたデータを SQL Server に格納できるようにします。 このオプションを選択しなかった場合、SQL Server では、適用可能なデータ型に対して既定の非 Unicode エンコード形式が使用されます。 詳細については、この記事の「UTF-8 サポート」セクションを参照してください。

1 バイナリまたはバイナリ コード ポイントが選択されている場合、大文字と小文字を区別する (_CS)、アクセントを区別する (_AS)、かなを区別する (_KS)、文字幅を区別する (_WS) オプションは使用できません。

照合順序オプションの例

各照合順序は、大文字小文字、アクセント、文字幅、かなの区別を定義する一連のサフィックスとして組み合わせられます。 次の例で、サフィックスのさまざまな組み合わせに対応する並べ替え順の動作を説明します。

Windows 照合順序サフィックス 並べ替え順の説明
_BIN1 バイナリ並べ替え
_BIN21、2 バイナリコード ポイント並べ替え順
_CI_AI2 大文字小文字を区別しない、アクセントを区別しない、かなを区別しない、文字幅を区別しない
_CI_AI_KS2 大文字小文字を区別しない、アクセントを区別しない、かなを区別する、文字幅を区別しない
_CI_AI_KS_WS2 大文字小文字を区別しない、アクセントを区別しない、かなを区別する、文字幅を区別する
_CI_AI_WS2 大文字小文字を区別しない、アクセントを区別しない、かなを区別しない、文字幅を区別する
_CI_AS2 大文字小文字を区別しない、アクセントを区別する、かなを区別しない、文字幅を区別しない
_CI_AS_KS2 大文字小文字を区別しない、アクセントを区別する、かなを区別する、文字幅を区別しない
_CI_AS_KS_WS2 大文字小文字を区別しない、アクセントを区別する、かなを区別する、文字幅を区別する
_CI_AS_WS2 大文字小文字を区別しない、アクセントを区別する、かなを区別しない、文字幅を区別する
_CS_AI2 大文字小文字を区別する、アクセントを区別しない、かなを区別しない、文字幅を区別しない
_CS_AI_KS2 大文字小文字を区別する、アクセントを区別しない、かなを区別する、文字幅を区別しない
_CS_AI_KS_WS2 大文字小文字を区別する、アクセントを区別しない、かなを区別する、文字幅を区別する
_CS_AI_WS2 大文字小文字を区別する、アクセントを区別しない、かなを区別しない、文字幅を区別する
_CS_AS2 大文字小文字を区別する、アクセントを区別する、かなを区別しない、文字幅を区別しない
_CS_AS_KS2 大文字小文字を区別する、アクセントを区別する、かなを区別する、文字幅を区別しない
_CS_AS_KS_WS2 大文字小文字を区別する、アクセントを区別する、かなを区別する、文字幅を区別する
_CS_AS_WS2 大文字小文字を区別する、アクセントを区別する、かなを区別しない、文字幅を区別する

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 データに対して Latin1_General_BINJapanese_BIN を使用した場合、並べ替え結果はどちらも同じになります。 詳細については、「Windows 照合順序名 (Transact-SQL)」を参照してください。

SQL Server には、次の 2 種類のバイナリ照合順序があります。

  • 以前の BIN 照合順序では、Unicode データに対して不完全なコード ポイント間比較が行われていました。 以前のこのようなバイナリ照合順序では、最初の文字が WCHAR として比較された後、続いてバイト単位の比較が行われていました。 BIN 照合順序では、最初の文字のみがコード ポイントに従って並べ替えられ、残りの文字はバイト値に従って並べ替えられます。

  • 新しい BIN2 照合順序では、純粋なコード ポイント比較が実装されます。 BIN2 照合順序では、すべての文字がコード ポイントに従って並べ替えられます。 Intel プラットフォームはリトル エンディアン アーキテクチャであるため、Unicode コード文字は常にバイト スワップして格納されます。

SQL Server 照合順序

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

たとえば、SQL 照合順序 SQL_Latin1_General_CP1_CI_AS を使用している場合、ハイフン (-) は b の前に来る区切り文字として並べ替えられるため、Unicode 以外の文字列 'a-c' は文字列 'ab' よりも小さくなります。 ただし、これらの文字列を Unicode に変換し、同じ比較を実行すると、Unicode の並べ替え規則ではハイフンを無視する単語の並べ替えが使用されるため、Unicode 文字列 N'a-c'N'ab' より大きいと見なされます。

詳細については、「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 に変更できます。

注意

SQL Server の英語インスタンスをアップグレードするときに、SQL Server の既存インスタンスとの互換性のために SQL Server 照合順序 (SQL_*) を指定することができます。 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
マケドニア語 (北マケドニア) 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 サーバー レベルでは利用できません
トルコ語 (Türkiye) 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 の照合順序

Azure SQL Database で論理サーバーの照合順序を変更または設定することはできませんが、データとカタログの両方に対して各データベースの照合順序を構成できます。 カタログの照合順序は、オブジェクト識別子などのシステム メタデータの照合順序を決定します。 Azure portal でデータベースを作成するとき、T-SQL で CREATE DATABASE を使用するとき、PowerShell で New-AzSqlDatabase を使用するときに、両方の照合順序を個別に指定できます。

Azure SQL Managed Instance の照合順序

Azure SQL Managed Instance のサーバーレベルの照合順序は、インスタンスの作成時に指定できますが、後で変更することはできません。

詳細については、「 サーバーの照合順序の設定または変更」を参照してください。

データベースレベルの照合順序

データベースを作成または変更するときに、CREATE DATABASE または ALTER DATABASE ステートメントの COLLATE 句を使用して、データベースの既定の照合順序を指定できます。 照合順序が指定されない場合、データベースにはサーバーの照合順序が割り当てられます。

サーバーの照合順序を変更する以外に、システム データベースの照合順序を変更する方法はありません。

  • SQL Server および Azure SQL Managed Instance では、データベースの照合順序は、データベース内のすべてのメタデータで使用され、データベース内で使用されるすべての文字列型の列、一時オブジェクト、変数名、およびその他のすべての文字列の既定値になります。
  • Azure SQL Database にはサーバーの照合順序がないため、各データベースにはデータの照合順序とカタログの照合順序があります。 CATALOG_COLLATION は、データベース内のすべてのメタデータで使用され、データベース内で使用されるすべての文字列型の列、一時オブジェクト、変数名、およびその他のすべての文字列の既定値になります。 CATALOG_COLLATION は作成時に設定され、変更できません。

ユーザー データベースの照合順序を変更する場合は、データベースのクエリが一時テーブルにアクセスするときに照合順序が競合する可能性があります。 一時テーブルは常に 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;    

ロケール

ロケールは、場所またはカルチャに関連付けられる一連の情報です。 その情報には、言語の名前や ID、言語の記述に使用される文字表記、文化的慣習などが含まれる場合があります。 照合順序は、1 つ以上のロケールに関連付けることができます。 詳細については、「 Microsoft によって割り当てられているロケール ID」を参照してください。

コード ページ

コード ページは、特定の文字表記の順序付けられた文字のセットです。コード ページでは、数値インデックス (コード ポイント値) が各文字に関連付けられます。 Windows コード ページは、通常は "文字セット" または charset と呼ばれています。 コード ページは、各種の Windows システム ロケールで使用される文字セットおよびキーボード レイアウトをサポートするために使用されます。

並べ替え順序

並べ替え順序は、データ値の並べ替え方法を指定します。 その順序により、データ比較の結果が影響を受けます。 データは、照合順序を使用して並べ替えられ、インデックスを使用して最適化することができます。

Unicode のサポート

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

Unicode の基礎

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

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

  • メキシコ向けのスペイン語の名前と住所
  • ケベック向けのフランス語の名前と住所
  • カナダの他の地域と米国向けの英語の名前と住所

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

注意

クライアントが使用するコード ページは、オペレーティング システム (OS) の設定によって決まります。 Windows オペレーティング システムでクライアント コード ページを設定するには、コントロール パネルの [地域と言語のオプション] を使用します。

世界中のユーザーが要求するすべての文字をサポートする文字データ型のコード ページを 1 つ選択することは困難です。 国をまたぐデータベースで文字データを管理する最も簡単な方法は、Unicode をサポートするデータ型を常に使用することです。

Unicode データ型

複数の言語を反映する文字データを SQL Server (SQL Server 2005 (9.x) 以降) に格納する場合は、非 Unicode データ型 (charvarchartext) ではなく、Unicode データ型 (ncharnvarcharntext) を使用してください。

注意

Unicode データ型の場合、データベース エンジン では、UCS-2 を使うと最大 65,536 文字を表すことができ、補助文字を使った場合は Unicode の全範囲 (1,114,112 文字) を表すことができます。 補助文字の有効化について詳しくは、「補助文字」をご覧ください。

代わりに、SQL Server 2019 (15.x) 以降では、UTF 8 対応の照合順序 (_UTF8) を使用した場合に、以前の非 Unicode データ型 (charvarchar) が UTF-8 エンコードを使用した Unicode データ型になります。 SQL Server 2019 (15.x) では、UCS-2 エンコードまたは UTF-16 エンコードを引き続き使用する、以前の既存の Unicode データ型 (ncharnvarcharntext) の動作は変わりません。 詳しくは、「UTF-8 と UTF-16 でのストレージの相違点」をご覧ください。

Unicode の注意点

非 Unicode データ型には、多くの制限が関連付けられています。 これは、Unicode に対応していないコンピューターではコード ページの使用が 1 つに制限されているためです。 Unicode コードを使用すると、必要なコード ページ変換が少なくなるので、パフォーマンスの向上が期待できます。 Unicode 照合順序は、サーバー レベルではサポートされないため、データベース、列、式の各レベルで個別に選択する必要があります。

データをサーバーからクライアントに移動するとき、古いクライアント ドライバーでサーバー照合順序が認識されないことがあります。 これは、データを Unicode サーバーから非 Unicode クライアントに移動する場合に発生する可能性があります。 最善の対処方法は、クライアント オペレーティング システムをアップグレードして、基になるシステムの照合順序を更新することです。 クライアントにデータベース クライアント ソフトウェアがインストールされている場合は、データベース クライアント ソフトウェアにサービスの更新プログラムを適用する方法もあります。

ヒント

また、サーバー上のデータに異なる照合順序を使用してみることもできます。 クライアントのコード ページにマップする照合順序を選択します。

一部の Unicode 文字の検索と並べ替えの機能を向上させるために SQL Server (SQL Server 2012 (11.x) 以降) で使用可能な UTF-16 照合順序を使用するには (Windows 照合順序のみ)、補助文字 (_SC) の照合順序の 1 つ、またはバージョン 140 の照合順序の 1 つを選択できます。

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 つの主要タイプのいずれかになります。

  • 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 では、BMP 範囲 (000000 – 00FFFF) の Unicode データを格納するために、ncharnvarchar などのデータ型が提供されています。これらは、データベース エンジンでは UCS-2 を使ってエンコードされます。

SQL Server 2012 (11.x) では、完全な Unicode 文字範囲 (000000 – 10FFFF) を表すために、ncharnvarcharsql_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 文字範囲を表すこともできます。

注意

SQL Server 2017 (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 照合順序を使用できます。

注意

GB18030 でエンコードされた文字を含む文字列が正しく表示されるように、SQL Server Management Studio などのクライアント ツールでは確実に Dengxian フォントを使用します。

複雑な文字表記のサポート

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_SCLATIN1_GENERAL_100_CI_AS_SC_UTF8 に変更します。

UTF-8 は、SQL Server 2012 (11.x) で導入された補助文字をサポートする Windows 照合順序にのみ使用できます。 nchar および nvarchar データ型では、UCS-2 または UTF-16 エンコードのみが許可され、変更されていません。

Azure SQL Database と Azure SQL Managed Instance は、データベースおよび列レベルでも UTF-8 をサポートしていますが、SQL 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 対応のラテン語の照合順序を使用する場合、CHAR(10) 列に 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 に変換する前に、予想される列定義のバイトサイズを事前に把握し、それに応じて新しいデータ型のサイズを調整する必要があります。 DATALENGTH 関数と COLLATE ステートメントを使用して、既存のデータベースでの UTF-8 変換操作に必要なデータ長の適正な要件を決定するには、Data Samples GitHub の Transact-SQL スクリプトまたは SQL Notebook を参照してください。

既存のテーブル内の列の照合順序とデータ型を変更するには、「列の照合順序の設定または変更」で説明されているいずれかの方法を使用します。

データベースの照合順序を変更して、新しいオブジェクトが既定でデータベースの照合順序を継承できるようにするか、またはサーバーの照合順序を変更して、新しいデータベースが既定でシステムの照合順序を継承できるようにするには、この記事の「関連タスク」セクションを参照してください。

タスク [アーティクル]
SQL Server のインスタンスの照合順序を設定または変更する方法について説明します。 サーバーの照合順序を変更しても、既存のデータベースの照合順序は変更されません。 サーバーの照合順序の設定または変更
ユーザー データベースの照合順序を設定または変更する方法について説明します。 データベースの照合順序を変更しても、既存のテーブル列の照合順序は変更されません。 データベースの照合順序の設定または変更
データベース内の列の照合順序を設定または変更する方法について説明します 列の照合順序の設定または変更
サーバー、データベース、または列のレベルでの照合順序の情報を取得する方法について説明します 照合順序情報の表示
Transact-SQL ステートメントを、ある言語から別の言語に容易に移行したり、複数の言語を簡単にサポートしたりできるように記述する方法について説明します 国際化に対応した Transact-SQL ステートメントの記述
エラー メッセージの言語と、日付、時刻、通貨データを使用および表示する際の設定を変更する方法について説明します セッション言語の設定

詳細については、次の関連コンテンツを参照してください。

関連項目