web-dev-qa-db-ja.com

SQL Serverのデフォルトの文字エンコード

デフォルトでは、Microsoft SQL Serverのデータベースに設定されている文字エンコーディングは何ですか？

SQL Serverで現在の文字エンコードを確認するにはどうすればよいですか？

sql-servercharacter-encodingcollation
55
david99world

新しく作成されたデータベースのデフォルトの照合順序を知る必要がある場合：

SELECT SERVERPROPERTY('Collation')

これは、実行しているSQL Serverインスタンスのサーバー照合です。

43
ThomasMcLeod

エンコーディング

ほとんどの場合、SQL ServerはUnicodeデータ（つまり、XMLおよびNで始まるデータ）をUCS-2/UTF-16に保存します（ストレージは同じで、UTF-16は単に補助文字を正しく処理します）。これは構成できません：使用するオプションはありません uTF-8または UTF-32 （UPDATEセクションを参照re：SQL Server 2019以降のUTF-8）。組み込み関数が補助文字を適切に処理できるかどうか、およびそれらが適切にソートおよび比較されるかどうかは、使用される照合によって決まります。古い照合— SQL_で始まる名前（例SQL_Latin1_General_CP1_CI_AS）xor名前にバージョン番号なし（例Latin1_General_CI_AS）—すべてを同等相互の補助文字（ソートの重みがないため）。 SQL Server 2005からは、少なくとも補助文字のバイナリ比較を行うことができる90シリーズの照合順序（名前に_90_を含む照合順序）が導入されました。希望の順序で並べ替えません。これは、SQL Server 2008で導入された100シリーズの照合順序にも当てはまります。SQLServer 2012では、補助文字を適切に並べ替えるだけでなく、組み込み関数を許可する_SCで終わる名前の照合順序が導入されましたそれらを期待どおりに解釈します（つまり、サロゲートペアを単一のエンティティとして扱います）。 SQL Server 2017以降、すべての新しい照合順序（140シリーズ） 補助文字を暗黙的にサポート 、したがって、名前が_SCで終わる新しい照合順序はありません。

SQL Server 2019以降、UTF-8はCHARおよびVARCHARデータ（列、変数、リテラル）でサポートされているエンコードになりましたが、TEXTではサポートされていません （UPDATEセクションを参照re：SQL Server 2019以降のUTF-8）。

非Unicodeデータ（つまり、CHAR、VARCHAR、およびTEXTタイプにありますが、TEXTは使用せず、代わりにVARCHAR(MAX)を使用）は、8ビットエンコーディング（拡張ASCII、DBCS、またはEBCDIC）を使用します。特定の文字セット/エンコードは、コードページに基づいています。コードページは、列の照合、またはリテラルと変数の現在のデータベースの照合、または変数/カーソル名とGOTOのインスタンスの照合に基づいています。ラベル、またはCOLLATE句で指定されているもの（使用されている場合）。

ロケールが照合にどのように一致するかを確認するには、以下を確認してください。

特定の照合に関連付けられたコードページ（これは文字セットであり、CHAR/VARCHAR/TEXTデータにのみ影響します）を表示するには、次を実行します。

SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'CodePage' ) AS [CodePage];

特定の照合に関連付けられているLCID（ロケール）を表示するには（これは並べ替えと比較の規則に影響します）、次を実行します。

SELECT COLLATIONPROPERTY( 'Latin1_General_100_CI_AS' , 'LCID' ) AS [LCID];

使用可能な照合のリストを、それらに関連付けられたLCIDおよびコードページとともに表示するには、次を実行します。

SELECT [name],
       COLLATIONPROPERTY( [name], 'LCID' ) AS [LCID],
       COLLATIONPROPERTY( [name], 'CodePage' ) AS [CodePage]
FROM sys.fn_helpcollations()
ORDER BY [name];

デフォルト

サーバーとデータベースのデフォルトの照合順序を見る前に、これらのデフォルトの相対的な重要性を理解する必要があります。

サーバー（実際には、インスタンス）デフォルト照合は、新しく作成されたデータベース（システムデータベースを含む：master、model、msdb、およびtempdb）のデフォルトとして使用されます。ただし、これは、4つのシステムDB以外のデータベースがその照合を使用していることを意味するものではありません。データベースの既定の照合順序はいつでも変更できます（ただし、データベースが照合順序を変更できないようにする依存関係があります）。ただし、サーバーのデフォルトの照合順序は簡単に変更できません。すべての照合順序の変更の詳細については、以下を参照してください。 すべてのユーザーデータベースのインスタンス、データベース、およびすべての列の照合順序の変更：何が間違っている可能性がありますか？

サーバー/インスタンス照合は以下を制御します。

  • ローカル変数names
  • CURSOR名
  • GOTOラベル
  • インスタンスレベルのメタデータ

データベースのデフォルト照合は、次の3つの方法で使用されます。

  • 新しく作成された文字列列のデフォルトとして。しかし、これは文字列列がその照合を使用していることを意味しません。列の照合順序はいつでも変更できます。ここで、データベースのデフォルトを知ることは、ストリング列が設定される可能性が最も高いものを示すために重要です。
  • 文字列リテラル、変数、および文字列入力を受け取らず、文字列出力を生成する組み込み関数を含む操作の照合として（つまり、IF (@InputParam = 'something')）。ここで、データベースのデフォルトを知ることは、これらの操作の動作を管理するため、間違いなく重要です。
  • データベースレベルのメタデータ

列照合は、CREATE TABLEまたはALTER TABLE {table_name} ALTER COLUMNのときにCOLLATE句で指定されるか、指定されていない場合はデータベースのデフォルトから取得されます。

ここには照合を指定できるいくつかのレイヤーがあるため（データベースのデフォルト/列/リテラル​​＆変数）、結果の照合は 照合優先順位 によって決定されます。

以上のことをすべて説明すると、次のクエリは、OS、SQL Serverインスタンス、および指定されたデータベースのデフォルト/現在の設定を示しています。

SELECT os_language_version,
       ---
       SERVERPROPERTY('LCID') AS 'Instance-LCID',
       SERVERPROPERTY('Collation') AS 'Instance-Collation',
       SERVERPROPERTY('ComparisonStyle') AS 'Instance-ComparisonStyle',
       SERVERPROPERTY('SqlSortOrder') AS 'Instance-SqlSortOrder',
       SERVERPROPERTY('SqlSortOrderName') AS 'Instance-SqlSortOrderName',
       SERVERPROPERTY('SqlCharSet') AS 'Instance-SqlCharSet',
       SERVERPROPERTY('SqlCharSetName') AS 'Instance-SqlCharSetName',
       ---
       DATABASEPROPERTYEX(N'{database_name}', 'LCID') AS 'Database-LCID',
       DATABASEPROPERTYEX(N'{database_name}', 'Collation') AS 'Database-Collation',
   DATABASEPROPERTYEX(N'{database_name}', 'ComparisonStyle') AS 'Database-ComparisonStyle',
       DATABASEPROPERTYEX(N'{database_name}', 'SQLSortOrder') AS 'Database-SQLSortOrder'
FROM   sys.dm_os_windows_info;

インストールのデフォルト

「デフォルト」の別の解釈は、インストール時にインスタンスレベルの照合に対してどのデフォルト照合が選択されるかを意味します。これはOS言語によって異なりますが、（恐ろしい、恐ろしい）デフォルトのSQL_Latin1_General_CP1_CI_ASです。その場合、「デフォルト」エンコーディングはVARCHARデータのWindowsコードページ1252であり、いつものように、NVARCHARデータのUTF-16です。

2018-10-02更新

SQL Server 2019では、VARCHAR/CHARデータ型（TEXTではなく）でUTF-8のネイティブサポートが導入されています。これは、名前がすべて_UTF8で終わる新しい照合のセットによって実現されます。これは間違いなく一部の人々を助ける興味深い機能ですが、特にすべての列およびデータベースにUTF-8が使用されていない場合、いくつかの「癖」がありますデフォルトの照合順序なので、UTF-8が魔法のように優れていると聞いたという理由だけで使用しないでください。 UTF-8はASCII互換性のためにsolelyに設計されました：ASCIIのみのシステム（つまり、当時のUNIX）が既存のコードを変更せずにUnicodeをサポートできるようにしますまたはファイル。主に（または唯一の）米国英語文字（およびいくつかの句読点）を使用してデータ用のスペースを節約することは、副作用です。ほとんど（またはのみ）米国英語の文字を使用しない場合、使用する文字に応じて、データはUTF-16と同じサイズになるか、さらに大きくなる可能性があります。また、スペースを節約する場合、パフォーマンスは向上する可能性がありますが、悪化する可能性もあります。

この新機能の詳細な分析については、私の投稿「 SQL Server 2019でのネイティブUTF-8サポート：救世主または偽預言者？ 」を参照してください。

33
Solomon Rutzky

SQL Serverデータベースのデフォルトの文字エンコーディングはiso_1で、ISO 8859-1です。文字エンコーディングは列のデータ型に依存することに注意してください。このSQLを使用した照合だけでなく、データベースの列にどの文字エンコードが使用されているかを知ることができます。

select data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name, count(*) count
from information_schema.columns
group by data_type, character_set_catalog, character_set_schema, character_set_name, collation_catalog, collation_schema, collation_name;

デフォルトを使用している場合、charおよびvarcharデータ型のcharacter_set_nameはiso_1である必要があります。 ncharおよびnvarcharはUCS-2形式でUnicodeデータを格納するため、これらのデータ型のcharacter_set_nameはUNICODEです。

18
Rob at TVSeries.com

SELECT DATABASEPROPERTYEX('DBName', 'Collation') SQLCollation;

DBNameはデータベース名です。

15
JNK

これは別の答えに値すると思います：内部的にUnicodeデータはSQL ServerにUTF-16として保存されていますが、これはリトルエンディアンの味ですので、外部システムからデータベースを呼び出す場合は、おそらくUTF-を指定する必要があります16LE。

0
Integrating Stuff