定序與 Unicode 支援

發行項
07/13/2023

適用於：SQL Server Azure SQL Database Azure SQL 受控執行個體 Azure Synapse Analytics Analytics Platform System (PDW)Microsoft Fabric 中的 SQL 分析端點 Microsoft Fabric 中的倉儲

SQL Server 中的定序會為您的資料提供排序規則、區分大小寫和重音符號的屬性。與字元資料類型 (例如 char 和 varchar) 搭配使用的定序會指示字碼頁，以及可針對該資料類型表示的對應字元。

不論您要安裝新的 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 編碼。

下表描述與這些不同選項建立關聯的行為：

選項	Description
區分大小寫 (_CS)	區分大寫和小寫字母。如果選取此選項，小寫字母會排序在大寫字母的前面。如果未選取此選項，定序就不會區分大小寫。也就是說，在排序用途上，SQL Server 會將大寫和小寫字母視為相同。指定 _CI，就可以明確地選取不區分大小寫。
區分腔調字 (_AS)	區分有腔調和無腔調的字元。例如，"a" 不等於 "ấ"。如果未選取此選項，定序就不會區分腔調。也就是說，在排序用途上，SQL Server 會將有腔調和無腔調字母視為相同。指定 _AI，就可以明確地選取不區分腔調字。
區分假名 (_KS)	區分兩種類型的日文假名字元：平假名與片假名。如果未選取此選項，定序就不會區分假名。也就是說，在排序用途上，SQL Server 會將平假名和片假名視為相同。省略此選項是指定不區分假名的唯一方法。
區分全半形 (_WS)	區分全形與半形字元。如果您未選取此選項，排序時，SQL Server 會將相同字元的全形和半形表示法視為相同。省略此選項，是指定不區分全形與半形的唯一方法。
區分變化選取器 (_VSS)	從 SQL Server 2017 (14.x) 開始，日文定序 Japanese_Bushu_Kakusu_140 和 Japanese_XJIS_140 中的各種不同表意字元變化選取器開始有所區別。變化序列是由基底字元加上變化選取器所組成。如果未選取此 _VSS 選項，則定序不區分變化選取器，且比較時不會將變化選取器納入考量。換句話說，SQL Server 基於排序目的，會將建置在相同基底字元但使用不同變化選取器的字元視為相同。如需詳細資訊，請參閱 Unicode Ideographic Variation Database (Unicode 表意字元變化資料庫)。全文檢索搜尋索引不支援區分變化選取器 (_VSS) 定序。全文檢索搜尋索引支援只區分腔調字 (_AS)、區分假名 (_KS) 和區分全半形 (_WS) 選項。 SQL Server XML 和 CLR 引擎不支援 (_VSS) 變化選取器。
二進位 (_BIN)¹	依據對每一個字元所定義的位元模式，排序及比較 SQL Server 資料表中的資料。二進位排序次序為區分大小寫且區分腔調字。二進位也是最快的排序順序。如需詳細資訊，請參閱本文的＜二進位定序＞一節。
二進位字碼指標 (_BIN2)¹	依據 Unicode 資料的 Unicode 字碼指標，排序及比較 SQL Server 資料表中的資料。針對非 Unicode 資料，二進位字碼指標將使用與二進位排序相同的比較。使用二進位字碼指標排序次序的好處，就是將已排序的 SQL Server 資料匯入應用程式中比較時，不必將資料重新排序。因此，二進位字碼指標排序次序可簡化應用程式的開發並提升效能。如需詳細資訊，請參閱本文的＜二進位定序＞一節。
UTF-8 (_UTF8)	讓 UTF-8 編碼資料可儲存至 SQL Server。如果未選取此選項，則 SQL Server 會使用適用資料類型的預設非 Unicode 編碼格式。如需詳細資訊，請參閱本文的＜UTF-8 支援＞一節。

¹ 如果選取二進位或二進位字碼指標，則無法使用區分大小寫 (_CS)、區分腔調 (_AS)、區分假名 (_KS) 和區分全半形 (_WS) 等選項。

定序選項的範例

每一個定序都會結合成一系列後置詞，以定義大小寫、腔調字、全半形或假名的區分。下列範例描述不同後置詞結合的排序次序行為。

Windows 定序後置詞	排序順序描述
_BIN¹	二進位排序
_BIN2^{1, 2}	二進位字碼指標排序次序
_CI_AI²	不區分大小寫、不區分腔調字、不區分假名、不區分全半形
_CI_AI_KS²	不區分大小寫、不區分腔調字、區分假名、不區分全半形
_CI_AI_KS_WS²	不區分大小寫、不區分腔調字、區分假名、區分全半形
_CI_AI_WS²	不區分大小寫、不區分腔調字、不區分假名、區分全半形
_CI_AS²	不區分大小寫、區分腔調字、不區分假名、不區分全半形
_CI_AS_KS²	不區分大小寫、區分腔調字、區分假名、不區分全半形
_CI_AS_KS_WS²	不區分大小寫、區分腔調字、區分假名、區分全半形
_CI_AS_WS²	不區分大小寫、區分腔調字、不區分假名、區分全半形
_CS_AI²	區分大小寫、不區分腔調字、不區分假名、不區分全半形
_CS_AI_KS²	區分大小寫、不區分腔調字、區分假名、不區分全半形
_CS_AI_KS_WS²	區分大小寫、不區分腔調字、區分假名、區分全半形
_CS_AI_WS²	區分大小寫、不區分腔調字、不區分假名、區分全半形
_CS_AS²	區分大小寫、區分腔調字、不區分假名、不區分全半形
_CS_AS_KS²	區分大小寫、區分腔調字、區分假名、不區分全半形
_CS_AS_KS_WS²	區分大小寫、區分腔調字、區分假名、區分全半形
_CS_AS_WS²	區分大小寫、區分腔調字、不區分假名、區分全半形

¹ 如果選取二進位或二進位字碼指標，則無法使用區分大小寫 (_CS)、區分腔調 (_AS)、區分假名 (_KS) 和區分全半形 (_WS) 等選項。

² 新增 UTF-8 選項 (_UTF8) 可讓您使用 UTF-8 來編碼 Unicode 資料。如需詳細資訊，請參閱本文的＜UTF-8 支援＞一節。

定序集

SQL Server 支援下列定序集：

Windows 定序
二進位定序
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 資料類型的二進位定序，在資料排序時不會考量地區設定。例如， Latin1_General_BIN 和 Japanese_BIN 在 Unicode 數據上使用時會產生相同的排序結果。如需詳細資訊，請參閱 Windows 定序名稱 (Transact-SQL)。

SQL Server 中有兩種二進位定序類型：

舊版 BIN 定序，對 Unicode 資料執行未完成的字碼指標對字碼指標比較。這些舊版二進位定序會將第一個字元作為 WCHAR 進行比較，之後再以逐位元組的方式進行比較。在 BIN 定序中，只有第一個字元是根據字碼指標排序，剩餘字元則是根據其位元組值排序。
較新的 BIN2 定序會實作純字碼指標比較。在 BIN2 定序中，所有字元都是根據其字碼指標排序。因為 Intel 平台是 Little Endian 架構，所以 Unicode 字碼字元一律以位元組交換的方式儲存。

SQL Server 定序

SQL Server 定序 (SQL_*) 提供與舊版 SQL Server 排序次序的相容性。非 Unicode 資料的字典排序規則與 Windows 作業系統所提供任何排序常式不相容。不過，Unicode 資料的排序與 Windows 排序規則的特定版本相容。由於 SQL Server 定序對非 Unicode 資料和 Unicode 資料使用不同的比較規則，因此您會看到，即便比較相同的資料，比較結果還是不同，而這取決於基礎資料類型。

例如，如果您使用 SQL 定序 SQL_Latin1_General_CP1_CI_AS，非 Unicode 字串 'a-c' 會小於字串 'ab'，因為連字號 (-) 會排序為 b 之前的個別字元。不過，如果將這些字串轉換成 Unicode 並執行相同的比較，Unicode 字串 N'a-c' 會被視為大於 N'ab'，因為 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。

注意

升級使用英文的 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
阿拉伯文 (阿拉伯聯合大公國)	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	伺服器層級無法使用
莫霍克文 (加拿大)	0x047a	0x047a	Latin1_General_CI_AI
蒙古文 (蒙古)	0x0450	0x0419	Cyrillic_General_CI_AS
蒙古文 (中國)	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
藏文 (中國)	0x0451	0x0451	伺服器層級無法使用
土耳其文 (Türkiye)	0x041f	0x041f	Turkish_CI_AS
土庫曼文 (土庫曼)	0x0442	0x0442	Latin1_General_CI_AI
維吾爾文 (中國)	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
爨文 (中國)	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 資料庫中的定序

無法在 Azure SQL 資料庫上變更或設定邏輯伺服器定序，但可以同時設定資料和目錄的每個資料庫的定序。目錄定序會決定系統中繼資料的定序，例如物件識別碼。當您在 Azure 入口網站、T-SQL (使用 CREATE DATABASE)、PowerShell (使用 New-AzSqlDatabase) 中建立資料庫時，可單獨指定這兩個定序。

Azure SQL 受控執行個體中的定序

建立 Azure SQL 受控執行個體時，可指定執行個體中的伺服器層級定序，且稍後無法變更。

如需詳細資訊，請參閱設定或變更伺服器定序。

資料庫層級定序

當建立資料庫時，您可以使用 CREATE DATABASE 的 COLLATE 子句或 ALTER DATABASE 陳述式來指定預設資料庫定序。如果未指定定序，則會將伺服器定序指派給資料庫。

除非變更伺服器的定序，否則無法變更系統資料庫的定序。

在 SQL Server 和 Azure SQL 受控執行個體中，資料庫定序用於資料庫中的所有中繼資料，且是資料庫中所使用全部字串資料行、暫存物件、變數名稱和任何其他字串的預設值。
在 Azure SQL 資料庫中，沒有伺服器定序，因此每個資料庫都有資料定序和目錄定序。 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;

Locale

地區設定是一組與某個地點或文化特性建立關聯的資訊。這項資訊包括口語的名稱和識別碼、用來撰寫該語言的指令碼及文化習慣。定序可與一個或多個地區設定產生關聯。如需詳細資訊，請參閱 Microsoft 指派的地區設定識別碼。

字碼頁

字碼頁是給定的指令碼的已排序字元集，其中每一個字元與數字索引或字碼指標值相關聯。 Windows 字碼頁一般稱為「字元集」或 charset。字碼頁是用來提供不同 Windows 系統地區設定所使用的字元集和鍵盤配置的支援。

排列順序

排序次序會指定如何排序資料值。次序會影響資料比較的結果。資料是使用定序來排序，而且可以使用索引來最佳化。

Unicode 支援

Unicode 是將字碼指標對應到字元的標準用法。由於 Unicode 主要設計為涵蓋世界上所有語言的字元，因此您不需要使用不同字碼頁來處理不同的字元集。

Unicode 基本概念

若某個資料庫中以多種語言儲存資料，則當您只使用字元資料和字碼頁時會使得管理更加困難。同時，也不容易針對可以儲存所有需要語言特定字元的資料庫尋找某個字碼頁。此外，當以執行各種字碼頁的不同用戶端來讀取或更新特殊字元時，很難保證這些特殊字元能有正確的轉譯。支援國際用戶端的資料庫應該一律使用 Unicode 資料類型，而不使用非 Unicode 資料類型。

例如，考慮必須處理三種主要語言的北美地區客戶資料庫：

墨西哥的西班牙文姓名與地址
魁北克的法文姓名與地址
加拿大其他地區與美國的英文姓名與地址

當只使用字元資料行與字碼頁時，您必須小心確定安裝資料庫時使用了可以處理這三種語言字元的字碼頁。當執行另一種語言之字碼頁的用戶端讀取字元時，您也必須小心確保任何語言的字元都正確轉譯。

注意

用戶端所使用的字碼頁是由作業系統 (OS) 設定決定。若要在 Windows XP 作業系統上設定用戶端字碼頁，請使用 [控制台] 中的 [地區設定] 。

要對支援全球用戶需要的所有字元，選取字元資料類型的字碼頁則相當困難。在國際資料庫中管理字元資料最簡單的方式，就是一律使用支援 Unicode 的資料類型。

Unicode 資料類型

如果您將可反映多種語言的字元資料儲存於 SQL Server (SQL Server 2005 (9.x) 以上版本)，請使用 Unicode 資料類型 (nchar、nvarchar 和 ntext)，而不是使用 Unicode 資料類型 (char、varchar 和 text)。

注意

針對 Unicode 資料類型，資料庫引擎可以使用 UCS-2 表示最多 65,536 個字元，或在使用增補字元的情況下，使用完整的 Unicode 範圍 (1,114,112‬ 個字元)。如需啟用增補字元的詳細資訊，請參閱增補字元。

或者，從 SQL Server 2019 (15.x) 開始，如果使用支援 UTF-8 的定序 (_UTF8)，先前非 Unicode 的資料類型 (char 和 varchar) 會變成使用 UTF-8 編碼的 Unicode 資料類型。 SQL Server 2019 (15.x) 不會變更原有 Unicode 資料類型 (nchar、nvarchar 和 ntext) 的行為，這些資料類型會繼續使用 UCS-2 或 UTF-16 編碼。如需詳細資訊，請參閱 UTF-8 和 UTF-16 間的儲存差異。

Unicode 考量事項

重要限制會與非 Unicode 資料類型相關聯。這是因為非 Unicode 電腦受限於使用單一字碼頁。透過使用 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 用戶端是兩種主要類型中的其中一種：

Unicode 用戶端，其使用 OLE DB 和開放式資料庫連接 (ODBC) 3.7 版或更新版本。
非 Unicode 用戶端，其使用 DB-Library 和 ODBC 3.6 版或較舊版本。

下表將提供搭配 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	這是多國語言資料的限制狀況。您只能使用單一字碼頁。

增補字元

Unicode Consortium 會為每個字元配置唯一的字碼指碼，其值介於 000000 到 10FFFF 的範圍。最常用的字元會具備 000000 到 00FFFF (65,536 個字元) 範圍內的字碼指標值，其在記憶體和硬碟上可容於 8 位元或 16 位元的字組。此範圍通常會指定為基本多語系平面 (BMP)。

但 Unicode Consortium 已建立其它 16 個字元「平面」，每個平面的大小都與 BMP 相同。此定義可讓 Unicode 具備表示 1,114,112 個字元的潛力 (即 2¹⁶ * 17 個字元)，介於字碼指碼範圍 000000 到 10FFFF 中。字碼指標值大於 00FFFF 的字元需要二至四個連續的 8 位元字組 (UTF-8) 或兩個連續的 16 位元字組 (UTF-16)。這些字元位於 BMP 範圍之外，稱為「增補字元」的範圍內，並且額外的連續 8 位元或 16 位元字組稱為「代理字組」。如需增補字元、代理及代理字組的詳細資訊，請參閱 Unicode 標準。

SQL Server 提供 nchar 和 nvarchar 等資料類型，可儲存 BMP 範圍 (000000 到 00FFFF) 內的 Unicode 資料，資料庫引擎會使用 UCS-2 來編碼。

SQL Server 2012 (11.x) 導入的全新系列增補字元 (_SC) 定序可以與 nchar、nvarchar 和 sql_variant 等資料類型搭配使用，以代表完整的 Unicode 字元範圍 (000000 到 10FFFF)。例如：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 旗標)

下表將比較當某些字串函式和字串運算子使用增補字元搭配或不搭配增補字元感知 (SCA) 定序時，這些函式和運算子的行為：

字串函數或運算子	搭配 SCA 定序	不搭配 SCA 定序
CHARINDEX LEN PATINDEX	將 UTF-16 代理字組視為單一字碼指標。	將 UTF-16 代理字組視為兩個字碼指標。
LEFT REPLACE REVERSE RIGHT SUBSTRING STUFF	這些函數會將每個代理字組視為單一字碼指標，且如預期方式運作。	這些函數可能會將代理字組拆開並造成無法預期的結果。
NCHAR	傳回對應至所指定 Unicode 字碼指標值 (在範圍 0 到 0x10FFFF 中) 的字元。如果所指定值位於 0 到 0xFFFF 的範圍內，即會傳回單一字元。若為更高的值，則傳回對應的 Surrogate。	高於 0xFFFF 的值會傳回 NULL 而非對應的 Surrogate。
UNICODE	傳回 UTF-16 字碼指標在範圍 0 到 0x10FFFF 中)。	傳回 UCS-2 字碼指標 (在範圍 0 到 0x10FFFF 中)。
符合單一萬用字元萬用字元 - 不相符的字元	增補字元支援所有萬用字元作業。	增補字元不支援這些萬用字元作業。但支援其他萬用字元運算子。

GB18030 支援

GB18030 是一種獨立標準，可供中華人民共和國進行中文字元的編碼。在 GB18030 中，字元的長度可以是 1、2 或 4 個位元組。 SQL Server 可在 GB18030 編碼的字元從用戶端應用程式進入伺服器時加以辨識，並在轉換後以原生模式將其儲存為 Unicode 字元，藉以支援這種字元。當 GB18030 編碼的字元儲存在伺服器後，任何後續作業都會將其視為 Unicode 字元。

您可以使用任何中文定序，最好是使用最新的 100 版本。所有 100 版定序都支援含有 GB18030 字元的語言排序。如果資料內有增補字元 (代理字組)，您可以使用 SQL Server 所提供的 SC 定序來改善搜尋和排序作業。

注意

確認您的用戶端工具 (例如 SQL Server Management Studio) 確實使用 Dengxian 字型，以正確顯示包含 GB18030 編碼字元的字串。

複雜字集支援

SQL Server 可以支援輸入、儲存、變更及顯示複雜的字集。複雜字集包括下列類型：

包括由右至左和由左至右兩種文字之組合的字集，如阿拉伯文和英文文字的組合。
字元的形狀會隨著位置或是否結合其他字元而不同的字集，例如，阿拉伯文、印度文和泰文字元。
泰文之類的語言，因為單字之間不中斷，所以需要用內部字典來辨識單字。

與 SQL Server 互動的資料庫應用程式必須使用可支援複雜字集的控制項。受控碼中所建立標準 Windows Form 控制項具有複雜字集的功能。

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 僅適用於支援增補字元的 Windows 定序，此格式已於 SQL Server 2012 (11.x) 推出。 nchar 和 nvarchar 資料類型只允許 UCS-2 或 UTF-16 編碼，沒有產生任何變更。

Azure SQL Database 和 Azure SQL 受控執行個體也支援資料庫和資料行使用 UTF-8，而 SQL 受控執行個體在伺服器層級也支援此功能。

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 個位元組。

下表列出每個字元範圍和編碼類型的編碼儲存體位元組：

字碼範圍 (十六進位)	字碼範圍 (十進位)	使用 UTF-8 的儲存體位元組¹	使用 UTF-16 的儲存體位元組¹
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–03FFFF² 040000–10FFFF²	65,536–262,143² 262,144–1,114,111²	4	4

¹儲存體位元組指的是編碼的位元組長度，而非資料類型在磁碟上的儲存大小。如需磁碟上儲存大小的詳細資訊，請參閱 nchar 與 nvarchar 和 char 與 varchar。

²增補字元的字碼指碼範圍。

提示

一般認為在 CHAR(n) 和 VARCHAR(n) 中，或在 NCHAR(n) 和 NVARCHAR(n) 中，n 會定義字元數。這是因為在 CHAR(10) 資料行的範例中，可以使用定序 (例如 Latin1_General_100_CI_AI) 來儲存範圍 0-127 中的 10 個 ASCII 字元，因為此範圍內的每個字元只會使用 1 個位元組。

不過，在 CHAR(n) 和 VARCHAR(n) 中，n 會以「位元組」為單位 (0-8,000) 來定義字串大小，且在 NCHAR(n) 和 NVARCHAR(n) 中，n 會以「位元組配對」為單位 (0-4,000) 來定義字串大小。 n 一律不會定義可儲存的字元數。

如以上所見，取決於使用的字元集，選擇適當 Unicode 編碼和資料類型可能會節省大量儲存體或增加目前體存體使用量。例如，使用啟用 UTF-8 的拉丁定序 (例如 Latin1_General_100_CI_AI_SC_UTF8) 時，CHAR(10) 資料行會儲存 10 個位元組，且可以保留範圍 0-127 內的 10 個 ASCII 字元。但在範圍為 128-2047 時只能保留五個字元，而在範圍為 2048-65535 時只能保留三個字元。相較之下，由於 NCHAR(10) 資料行會儲存 10 個位元組配對 (20 個位元組)，因此可以保留範圍 0-65535 內的 10 個字元。

在您為資料庫或資料行選擇使用 UTF-8 或 UTF-16 編碼前，請考慮要儲存之字串資料的分佈：

若大部分都在 ASCII 範圍 0-127 內 (例如英文)，則使用 UTF-8 時每個字元將需要 1 個位元組，UTF-16 則需要 2 個位元組。使用 UTF-8 可提供儲存空間上的優勢。將具有 ASCII 字元 (範圍 0-127) 的現有資料行資料類型從 NCHAR(10) 變更為 CHAR(10)，並使用啟用 UTF-8 的定序，會使儲存體需求減少 50%。這項減少的原因是 NCHAR(10) 需要 20 個位元組作為儲存體，相較於 CHAR(10) 針對相同的 Unicode 字串表示只需要 10 個位元組。
在 ASCII 的範圍之上，幾乎所有拉丁語系字集，以及希臘文、斯拉夫、科普特文、亞美尼亞文、希伯來文、阿拉伯文、敘利亞文、它拿文和西非書面文字在 UTF-8 和 UTF-16 中的每個字元都需要 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 定義的是儲存體位元組大小，而不是可儲存的字元數，因此請務必判斷您必須轉換成的資料類型大小，以避免資料截斷。

例如，假設有一個資料行定義為 NVARCHAR(100) ，其中儲存 180 個位元組的日文字元。在此範例中，資料行資料目前是使用 UCS-2 或 UTF-16 編碼，每個字元是使用 2 個位元組。將資料行類型轉換成 VARCHAR(200) 不足以防止資料截斷，因為新的資料類型只能儲存 200 個位元組，但日文字元以 UTF-8 編碼時需要 3 個位元組。因此，必須將資料行定義為 VARCHAR(270) 以避免資料因資料截斷而遺失。

因此，在將現有資料轉換為 UTF-8 之前，必須事先知道資料行定義的預估位元組大小，並據此調整新資料類型大小。請參閱資料範例 GitHub 中的 Transact-SQL 指令碼或 SQL Notebook，該範例使用 DATALENGTH 函式和 COLLATE 陳述式，判斷現有資料庫中 UTF-8 轉換作業的正確資料長度需求。

若要變更現有資料表中的資料行定序和資料類型，請使用設定或變更資料行定序中所述的其中一個方法。

若要變更資料庫定序，讓新物件根據預設繼承資料庫定序，或變更伺服器定序，讓新資料庫根據預設繼承系統定序，請參閱此文章的相關工作一節。

Task	發行項
描述如何設定或變更 SQL Server 執行個體的定序。變更伺服器定序並不會變更現有資料庫的定序。	設定或變更伺服器定序
描述如何設定或變更使用者資料庫的定序。變更資料庫定序並不會變更現有資料表資料行的定序。	設定或變更資料庫定序
描述如何設定或變更資料庫中資料行的定序	設定或變更資料行定序
描述如何傳回伺服器、資料庫或資料行層級的定序資訊	檢視定序資訊
描述如何撰寫 Transact-SQL 陳述式，讓它們可以從某種語言攜至另一種語言，或更輕鬆地支援多種語言	撰寫國際通用的 Transact-SQL 陳述式
描述如何變更錯誤訊息的語言，以及變更日期、時間和貨幣資料使用及顯示方式的偏好設定。	設定工作階段語言