web-dev-qa-db-ja.com

SQL Server：文字セットを設定します（照合ではありません）

SQL Serverでテーブルを作成するときに、フィールドのデフォルトの文字セットをどのように設定しますか？ MySQLではこれを行います：

CREATE TABLE tableName (
    name VARCHAR(128) CHARACTER SET utf8
) DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_general_ci;

ここでは文字セットを2回設定していることに注意してください。それは冗長です、私は単に示すために両方の方法を追加しました。

また、照合が異なるものであることを示すために、照合を設定しました。照合順序の設定についてではありません。 ほとんど質問 SQL Serverの文字セットとエンコーディングについて尋ねると、照合で答えられます。これはnotです。 ） 同じこと。

sql-servercharacter-encodingcollationcharacter-set
14
dotancohen

BOLで述べられているように

各SQLServer照合順序は、次の3つのプロパティを指定します。

  • Unicodeデータ型（nchar、nvarchar、およびntext）に使用するソート順。ソート順は、文字がソートされる順序、および比較操作で文字が評価される方法を定義します。
  • 非Unicode文字データ型（char、varchar、およびtext）に使用するソート順。
  • Unicode以外の文字データを格納するために使用されるコードページ。

上記の引用は2000のドキュメントからのものです。 この2008年のリンクも参照 。以下もこれを示しています。

DECLARE @T TABLE 
(
     code TINYINT PRIMARY KEY,
     Arabic_CS_AS CHAR(1) COLLATE Arabic_CS_AS NULL,
     Cyrillic_General_CS_AS CHAR(1) COLLATE Cyrillic_General_CS_AS NULL,
     Latin1_General_CS_AS CHAR(1) COLLATE Latin1_General_CS_AS NULL
);

INSERT INTO @T(code) VALUES (200),(201),(202),(203),(204),(205)

UPDATE @T 
  SET Arabic_CS_AS=CAST(code AS BINARY(1)),
      Cyrillic_General_CS_AS=CAST(code AS BINARY(1)),
      Latin1_General_CS_AS=CAST(code AS BINARY(1))

SELECT * 
FROM @T

結果

code Arabic_CS_AS Cyrillic_General_CS_AS Latin1_General_CS_AS
---- ------------ ---------------------- --------------------
200  ب            И                      È
201  ة            Й                      É
202  ت            К                      Ê
203  ث            Л                      Ë
204  ج            М                      Ì
205  ح            Н                      Í
14
Martin Smith

@Martinの答えを拡張するには：

SQL Serverで「文字セット」を設定する方法は、使用しているデータ型によって異なります。使用している場合：

  • NVARCHAR、NCHAR、およびNTEXT（NTEXTは非推奨であり、SQL Server 2005以降は使用しないでください）はすべてUnicode文字セットを使用します。変えられない。これらのデータ型はすべてUTF-16LE（リトルエンディアン）としてエンコードされます（各「文字」が2バイトまたは4バイトの16ビットエンコード）。これも変更できません。これらのデータ型の場合、使用されている照合順序は、並べ替えと比較に使用される一連のルールを決定するロケール（照合順序のLCIDによって決定される）にのみ影響します。

  • XMLは、N接頭辞付きのタイプと同様に、Unicode文字セットを使用し、UTF-16 LE（リトルエンディアン）としてエンコードされます。どちらも変更できません。ただし、他の文字列データ型とは異なり、XMLデータに関連付けられた照合順序はありません。これは、データを並べ替えたり比較したりできないためです（少なくとも、最初にNVARCHAR(MAX) [preferred]またはVARCHAR(MAX)）。

  • VARCHAR、CHAR、およびTEXT（TEXTは非推奨であり、SQL Server 2005以降では使用しないでください）は、それぞれ8ビットエンコーディングです「文字」は1バイトまたは2バイトです。文字セットは、各照合順序に関連付けられたコードページによって決定されます。並べ替えと比較のルールは、使用されている照合のタイプによって異なります。

    • SQL Server照合順序：これらはすべて_SQL__で始まる名前を持ち、SQL Server 2000以降は非推奨になっていますが、（残念ながら）現在でも広く使用されています。これらは、sys.fn_helpcollations()によって返されるdescriptionフィールドにある「SQLServerの並べ替え順序」番号として示される単純なルールを使用します。
    • Windows照合順序：これらはすべて、_SQL__で始まるnotの名前を持っています。これらの照合順序により、非Unicode文字列データは、照合順序のLCIDによって示されるUnicodeの並べ替えと比較のルールを使用できます。

そうは言っても、使用されている文字セット（CHAR、VARCHAR、およびTEXT、つまり非Unicodeデータ）を見つけるには、次のクエリを実行してCodePageフィールドに細心の注意を払ってください。 LCIDフィールドは、N接頭辞付きの（つまりUnicode）タイプと非Unicodeタイプのソートおよび比較ルールに使用されるロケールを示します（= /// =）ifWindows照合順序を使用します。

_SELECT *,
       COLLATIONPROPERTY(col.[name], 'CodePage') AS [CodePage],
       COLLATIONPROPERTY(col.[name], 'LCID') AS [LCID]
FROM   sys.fn_helpcollations() col
ORDER BY col.[name];
_

コードページIDは、 コードページ識別子 のMSDNページを介してより意味のあるものに変換できます。

O.P.の コメント について@Martinの回答：

彼らが誤解を招く/不完全な用語「照合」を選択したのは残念です。これは明らかにソート順を指します：照合定義。

マイクロソフトが名前を選択する際にもっとうまくできたのは事実ですが、残念ながら、「エンコーディング」、「文字セット」、「照合」などの用語について、業界全体で一般的な混乱があります。マイクロソフトの使用（または誤用） 「照合」の問題は、単に大衆の混乱の一因となっています。しかし、 "utf8"が具体的にnot文字セット;-)であることを考えると、この混乱がMySQLでも明らかです。

UTF-8は、Unicode文字セットのいくつかのエンコーディングの1つです。 UTF-16とUTF-32は、他の2つのエンコーディングです。これらの3つのエンコーディングはすべて、まったく異なるUnicodeの文字セットを表します。 MySQL文字セットのリストを見る– 11.1.10サポートされている文字セットと照合順序 –「ucs2」、「utf8」、「utf8mb4」、「utf16」、「utf16le」、「utf32」文字セットそれ自体は実際には文字セットではなく、Unicode文字セットのさまざまな表現です。しかし、「文字セット」と「エンコーディング」の概念が重複していることを考えると、この混乱を避けることは難しいでしょう。 11.1.10.1 Unicode文字セット ページは、「utf8mb4」、「utf16」、「utf16le」、および「utf32」文字セットが完全なUnicode文字セットであり、「ucs2」および「utf8」がUnicode文字セットのサブセット、具体的には最初の65,536コードポイント（別名Basic Multilingual Plane（BMP））。

さまざまなRDBMS間での照合の詳細については、DBA.StackExchangeの次の質問に対する私の回答を参照してください。

DBMSには、大文字と小文字が区別され、アクセントが区別されない照合順序がありますか？

UPDATE 2018-10-02

これはまだ実行可能なオプションではありませんが、SQL Server 2019では、VARCHAR/CHARデータ型でUTF-8のネイティブサポートが導入されています。現在、バグが多すぎて使用できませんが、修正されている場合、これは一部のシナリオのオプションです。この新機能の詳細な分析については、私の投稿「 SQL Server 2019でのネイティブUTF-8サポート：救世主か偽預言者か？ "」を参照してください。

7
Solomon Rutzky