SQL Server：設置字符集（不歸類）

在SQL Server中創建表時，如何設置字段的默認字符集？在MySQL中是這樣的：SQL Server：設置字符集（不歸類）

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

請注意，我在這裏設置了兩次字符集。這是多餘的，我添加了兩種方式來證明。

我還設置了排序規則，以證明排序規則是不同的。我是而不是詢問設置排序規則。 Most questions詢問有關SQL Server中的字符集和編碼是否與排序對應，即而不是是同樣的事情。

來源

2011-10-15 dotancohen

他們是在SQL Server同樣的事情。通過在'varchar'列上設置排序規則，您還可以設置代碼頁。 –

謝謝Martin。記錄在哪裏？當然，我通過精細的手冊（MSDN在線），但我沒有看到它。 – dotancohen

排序規則控制SQL Server中字符串的物理存儲。排序規則指定[** both **]代表每個字符的位模式**和**字符排序和比較的規則。 [鏈接]（http://msdn.microsoft.com/en-us/library/ms186356.aspx） –

As stated in BOL

每個SQL Server排序規則指定三個屬性：

的排序順序以用於Unicode數據類型（NCHAR，nvarchar和NTEXT）。排序順序定義字符排序的順序，以及在比較操作中評估字符的方式。

用於非Unicode字符數據類型（char，varchar和text）的排序順序。

用於存儲非Unicode字符數據的代碼頁。

以上引用來自2000文檔。 See also this 2008 link。下面也演示了這一點。

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 ح   Н      Í

來源

2011-10-16 10:06:28

謝謝Martin。不幸的是，他們選擇了誤導性/不完整的術語「整理」，它明確指出排序順序：[整理定義]（http://dictionary.reference.com/browse/collate）。它似乎也不能因此使用此設置使用自定義排序規則（我有一個與自定義排序規則無關的PHP/MySQL應用程序）。順便說一句，我喜歡這個優雅的例子！ – dotancohen

@dotancohen - 您可以使用明確的「collate」子句來使用不同的比較語義，但不能定義自己的排序規則。 –

@Martin Smith你的答案是grate ....所有問題都取決於數據庫創建的時刻......選擇適當的排序規則非常重要.. –

爲了擴大對@馬丁的回答是：

您在SQL Server中如何設置「字符集」取決於你所使用的數據類型。如果您正在使用：

NVARCHAR，NCHAR和NTEXT（NTEXT已被棄用，不應該被用來作爲的SQL Server 2005）都使用Unicode字符集，這不能被改變。這些數據類型全部編碼爲UTF-16 LE（Little Endian）– 16位編碼，每個「字符」爲2或4字節–，這也不能改變。對於這些數據類型，正在使用的排序規則僅影響區域設置（由Collation的LCID確定），它確定用於排序和比較的規則集。
XML，像N -prefixed類型，使用Unicode字符集和被編碼爲UTF-16 LE（小端），和既不那些可以改變。但與其他字符串數據類型不同，沒有與XML數據關聯的歸類，因爲它不能被排序或比較（至少先不將其轉換爲NVARCHAR(MAX) [首選]或VARCHAR(MAX)）。
VARCHAR，CHAR，和TEXT（TEXT已被廢棄，不應該被用作的SQL Server 2005）都爲8位編碼，每個「字」是1或2個字節。字符集由與每個歸類關聯的代碼頁確定。的排序和比較規則取決於整理的類型使用：
- SQL Server排序規則：這些都開始SQL_名稱和自SQL Server 2000中已被否決，雖然是（不幸）仍被廣泛使用的今天。這些使用簡單規則，如sys.fn_helpcollations()返回的description字段中所示的「SQL Server排序順序」編號。
- 窗口排序規則：這些都有名字，做不是開始於SQL_。這些排序規則允許非Unicode字符串數據使用排序規則的LCID指示的Unicode排序和比較規則。

話雖這麼說，找出哪些字符集（CHAR，VARCHAR和TEXT –即非Unicode –數據）正在被使用，運行下面的查詢，並密切關注CodePage領域。該LCID字段表示用於排序和比較規則爲N -prefixed –即統一–類型以及非Unicode類型如果使用Windows排序規則的語言環境：

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

代碼頁ID可以通過Code Page Identifiers的MSDN頁面翻譯成更有意義的內容。

關於O.P.上@的comment馬丁的回答是：

不幸的是，他們選擇了誤導性/不完整的術語「整理」，這顯然是指排序順序：整理定義。

儘管微軟在選擇名稱時可以做得更好，但不幸的是，在諸如「編碼」，「字符集」，「整理」等術語方面存在一般性的，整個行業的混淆。微軟對「整理」的使用（或濫用）僅僅造成了大規模混亂。但是，由於「utf8」具體是而不是字符集，所以在MySQL中這種混淆也很明顯.--)。

UTF-8是Unicode字符集的幾種編碼之一。另外兩種編碼是UTF-16和UTF-32。所有這三種編碼都以不同的方式表示完全相同的Unicode字符集。查看MySQL字符集列表– 11.1.10 Supported Character Sets and Collations –「ucs2」，「utf8」，「utf8mb4」，「utf16」，「utf16le」，「utf32」字符集實際上並不是字符集，而是各種表示形式的字符集Unicode字符集。但是，鑑於「字符集」和「編碼」這兩個概念之間的重疊，難以避免混淆。11.1.10.1 Unicode Character Sets頁面指示「utf8mb4」，「utf16」，「utf16le」和「utf32」字符集是完整的Unicode字符集，而「ucs2」和「utf8」是Unicode字符集的子集，特別是第65,536個代碼點（又稱Basic Multilingual Plane（BMP））。

有關跨各種RDBMS的排序規則的詳細信息，請參閱我的回答下面的問題上DBA.StackExchange：

Does any DBMS have a collation that is both case-sensitive and accent-insensitive?

來源

2017-02-03 18:31:22

我覺得這是一個更好的解釋，那麼最初接受的是什麼。 – Exocomp

SQL Server：設置字符集（不歸類）

回答

相關問題