定序與 Unicode 支援

適用于:SQL Server (所有支援的版本) Azure SQL Database Azure SQL 受控執行個體 Azure Synapse Analytics Analytics Platform System (PDW)

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) 區分兩種類型的日文假名字元:平假名與片假名。 如果未選取此選項,定序就不會區分假名。 也就是說,在排序用途上,SQL Server 會將平假名和片假名視為相同。 省略此選項是指定不區分假名的唯一方法。
區分全半形 (_WS) 區分全形與半形字元。 如果未選取此選項,SQL Server會考慮相同字元的全形和半形標記法,以便進行排序。 省略此選項,是指定不區分全形與半形的唯一方法。
區分變化選取器 (_VSS) 區別日文定序Japanese_Bushu_Kakusu_140和Japanese_XJIS_140的各種表像變化選取器,這些選取器是在 2017 SQL Server 2017 (14.x) 中引進。 變化序列是由基底字元加上額外的變化選取器所組成。 如果未選取此_VSS選項,定序會不區分變化選取器,而且不會在比較中考慮變化選取器。 也就是說,SQL Server考慮以相同基底字元為基礎建置的字元,而差異變化選取器在排序時會相同。 如需詳細資訊,請參閱 Unicode Ideographic Variation Database (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 資料類型的二進位定序,在資料排序時不會考量地區設定。 例如,Latin_1_General_BINJapanese_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 Server 定序名稱 (Transact-SQL)

在SQL Server安裝期間,預設安裝定序設定取決於作業系統 (作業系統) 地區設定。 您可以在安裝期間變更伺服器層級的定序,也可以在安裝之前變更 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 伺服器層級無法使用
土耳其文 (土耳其) 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 Database 上變更或設定實例層級定序。 如需SQL 受管理執行個體和SQL Server的詳細資訊,請參閱:設定或變更伺服器定序

資料庫層級定序

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

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

資料庫定序是用於資料庫中的所有中繼資料,且是資料庫中所使用全部字串資料行、暫存物件、變數名稱和任何其他字串的預設值。 請注意,如果變更使用者資料庫的定序,則在資料庫中的查詢存取暫存資料表時,可能會發生定序衝突。 暫存資料表一律儲存在 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、NvarcharNtext) ,而不是非 Unicode 資料類型 (charVarchartext) 。

注意

For Unicode data types, the Database Engine can represent up to 65,536 characters using UCS-2, or the full Unicode range (‭1,114,112‬ characters) if supplementary characters are used. 如需啟用增補字元的詳細資訊,請參閱增補字元

或者,從 2019 SQL Server 2019 (15.x) 開始,如果使用 UTF-8 啟用定序 (_UTF8) ,先前非 Unicode 資料類型 (charVarchar) 就會變成使用 UTF-8 編碼的 Unicode 資料類型。 SQL Server 2019 (15.x) 不會變更先前現有 Unicode 資料類型的行為, (NcharNvarcharNtext) ,這會繼續使用 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 個字元的潛力 (即 216 * 17 個字元),介於字碼指碼範圍 000000 到 10FFFF 中。 字碼元素值大於 00FFFF 的字元需要二至四個連續的 8 位元字組 (UTF-8) 或兩個連續的 16 位元字組 (UTF-16)。 這些字元位於 BMP 範圍之外,稱為「增補字元」的範圍內,並且額外的連續 8 位元或 16 位元字組稱為「代理字組」。 如需增補字元、代理及代理字組的詳細資訊,請參閱 Unicode Standard (Unicode 標準)。

SQL Server提供NcharNvarchar等資料類型,以將 Unicode 資料儲存在 BMP 範圍 (000000–00FFFF) ,而 Database Engine 會使用 UCS-2 編碼。

SQL Server 2012 (11.x) 引進了可搭配NcharNvarcharSQL_variant資料類型使用的新增補字元 (_SC) 定序系列,以代表完整的 Unicode 字元範圍 (000000–10FFFF) 。 例如:Latin1_General_100_CI_AS_SCJapanese_Bushu_Kakusu_100_CI_AS_SC (如果使用日文定序的話)。

SQL Server 2019 (15.x) 會將補充字元支援延伸到已啟用新 UTF-8 的定序 (_UTF8) 的charVarchar資料類型。 這些資料類型也能夠代表完整的 Unicode 字元範圍。

注意

從 2017 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 允許用於 charvarchar 資料類型,且會在您建立物件定序或將其變更為具有 UTF8 尾碼的定序時啟用。 例如,LATIN1_GENERAL_100_CI_AS_SCLATIN1_GENERAL_100_CI_AS_SC_UTF8

UTF-8 僅適用于支援增補字元的 Windows 定序,如 SQL Server 2012 (11.x) 所引進。 ncharnvarchar 資料類型只允許 UCS-2 或 UTF-16 編碼,沒有產生任何變更。

Azure SQL 資料庫和Azure SQL 受控執行個體也支援資料庫和資料行層級上的 UTF-8,而受控執行個體也支援伺服器層級的 UTF-8。

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 的儲存體位元組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 與 nvarcharchar 與 varchar

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

提示

一般認為在 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 時只能保留 5 個字元,而在範圍為 2048-65535 時只能保留 3 個字元。 相較之下,由於 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 範圍上方,幾乎所有以拉丁為基礎的腳本,以及希臘文、斯拉夫文、Coptic、亞美尼亞文、希伯來文、阿拉伯文、希伯來文、阿拉伯文、希伯來文、希伯來文、阿拉伯文、希伯來文和 N'Ko,都需要 UTF-8 和 UTF-16 中的每一個字元 2 個位元組。 在這些案例中,可比較的資料類型 (例如使用 charnchar) 沒有明顯的儲存差異。
  • 若其內容大部分是東亞字集 (例如韓文、中文和日文),則在 UTF-8 中每個字元都需要 3 個位元組,UTF-16 中則為 2 個位元組。 使用 UTF-16 可提供儲存空間上的優勢。
  • 範圍 010000 至 10FFFF 的字元在 UTF-8 和 UTF-16 中都需要 4 個位元組。 在這些案例中,可比較的資料類型 (例如使用 charnchar) 沒有儲存體差異。

針對其它考量事項,請參閱撰寫國際 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 陳述式
描述如何變更錯誤訊息的語言和喜好設定,以瞭解日期、時間和貨幣資料的使用和顯示方式 設定工作階段語言

如需詳細資訊,請參閱下列相關內容:

另請參閱

自主資料庫定序
選擇建立全文檢索索引時的語言
sys.fn_helpcollations (Transact-SQL)
單位元組和多位元組字元集