共用方式為


Collation and Unicode Support

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)

與定序相關聯的選項是區分大小寫、區分腔調字、區分假名和區分全半形。 這些選項的指定方式是將它們附加至定序名稱。 例如,此定序 Japanese_Bushu_Kakusu_100_CS_AS_KS_WS 區分大小寫、區分腔調字、區分假名和區分全半形。 下表描述與這些選項相關聯的行為。

選項 Description
區分大小寫 (_CS) 區分大寫和小寫字母。 如果選取此選項,小寫字母會排序在大寫字母的前面。 如果未選取此選項,則定序不區分大小寫。 也就是說,在排序用途上,SQL Server 會將大寫和小寫字母視為相同。 指定 _CI,就可以明確地選取不區分大小寫。
區分腔調字 (_AS) 區分有腔調和無腔調的字元。 例如,'a' 不等於 'ấ'。 如果未選取此選項,則定序不區分腔調字。 也就是說,在排序用途上,SQL Server 會將有腔調和無腔調字母視為相同。 指定 _AI,就可以明確地選取不區分腔調字。
區分假名 (_KS) 區分兩種類型的日文假名字元:平假名與片假名。 如果未選取此選項,定序就不會區分假名。 也就是說,在排序用途上,SQL Server 會將平假名和片假名視為相同。 省略此選項,是指定不區分假名的唯一方法。
區分全半形 (_WS) 區分全形與半形字元。 如果未選取此選項,在排序用途上,SQL Server 會將相同字元的全形和半形表示法視為相同。 省略此選項,是指定不區分全形與半形的唯一方法。

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_BIN 和 Japanese_BIN 用於 Unicode 資料時會產生相同的排序結果。

SQL Server中有兩種類型的二進位定序;較舊的 BIN 定序和較 BIN2 新的定序。 在 BIN2 定序中,所有字元都是根據其字碼指標排序。 在 BIN 定序中,只有第一個字元是根據字碼指標排序,剩餘字元則是根據其位元組值排序。 (因為 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的英文實例時,可以指定SQL Server定序 (SQL_*) ,以便與現有的 SQL Server 實例相容。 因為設定期間會定義SQL Server實例的預設定序,所以請確定您在下列情況成立時仔細指定定序設定:

  • 應用程式的程式碼取決於先前的 SQL Server 定序行為。
  • 您必須儲存反映多國語言的字元資料。

您可以在 SQL Server 執行個體的下列層級完成定序設定:

伺服器層級定序
預設伺服器定序會在SQL Server安裝期間設定,也會成為系統資料庫和所有使用者資料庫的預設定序。 請注意,無法在SQL Server安裝期間選取僅限 Unicode 定序,因為它們不支援做為伺服器層級定序。

將定序指派給伺服器之後,除非匯出所有資料庫物件和資料,並重建 master 資料庫,然後匯入所有資料庫物件和資料,否則無法變更此定序。 您可以指定建立新資料庫或資料庫資料行時所需的定序,而不是變更SQL Server實例的預設定序。

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

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

資料庫定序是用於資料庫中的所有中繼資料,而且是資料庫中使用之所有字串資料行、暫存物件、變數名稱和任何其他字串的預設值。 請注意,如果變更使用者資料庫的定序,則在資料庫中的查詢存取暫存資料表時,可能會發生定序衝突。 暫存資料表一律儲存在 tempdb 系統資料庫中,以使用執行個體的定序。 如果定序導致評估字元資料發生衝突,則比較使用者資料庫與 tempdb 間之字元資料的查詢可能會失敗。 您可以在查詢中指定 COLLATE 子句以解決此問題。 如需詳細資訊,請參閱 COLLATE (Transact-SQL)

資料行層級定序
建立或改變資料表時,可以使用 COLLATE 子句來指定每個字元字串資料行的定序。 若未指定任何定序,就會將資料庫的預設定序指派給此資料行。

運算式層級定序
運算式層級定序是在執行陳述式時設定的,而且它們會影響傳回結果集的方式。 這樣可讓 ORDER BY 將結果排序成地區設定特定的結果。 使用類似下面的 COLLATE 子句來實作運算式層級定序:

SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;  

Locale

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

字碼頁

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

排序次序

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

Unicode 支援

Unicode 是將字碼指標對應到字元的標準用法。 由於 Unicode 主要設計為涵蓋世界上所有語言的字元,因此不需要使用不同的字碼頁來處理不同的字元集。 如果您儲存能夠反映多種語言的字元資料,一定要使用 Unicode 資料類型 (ncharnvarcharntext) 而不要使用非 Unicode 資料類型 (charvarchartext)。

重要限制會與非 Unicode 資料類型相關聯。 這是因為非 Unicode 電腦受限於使用單一字碼頁。 透過使用 Unicode,您可能會發現效能獲得明顯改善,因為所需要的字碼頁轉換減少。 您必須在資料庫、資料行或運算式層級個別選取 Unicode 定序,因為伺服器層級不支援這些定序。

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

當您將資料從伺服器移至用戶端時,舊版用戶端驅動程式可能無法辨識您的伺服器定序。 這種問題可能會發生在您將資料從 Unicode 伺服器移至非 Unicode 用戶端時。 此時,最佳選項可能就是升級用戶端作業系統,以便更新基礎系統定序。 如果用戶端已經安裝資料庫用戶端軟體,就可以考慮將服務更新套用至資料庫用戶端軟體。

此外,您也可以嘗試針對伺服器上的資料使用不同的定序。 您可以選擇將會對應至用戶端字碼頁的定序。

若要使用 SQL Server 2019 (15.x) 中提供的 UTF-16 定序,您可以選取其中一個補充字元定序, (Windows 定序) 以改善某些 Unicode 字元 _SC 的搜尋和排序。

若要評估與使用 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 這是多國語言資料的限制狀況。 您只能使用單一字碼頁。

增補字元

SQL Server提供和 等 ncharnvarchar 資料類型來儲存 Unicode 資料。 這些資料類型會使用稱為 UTF-16的格式來編碼文字。 Unicode Consortium 會為每個字元配置唯一的字碼指標,其值介於 0x0000 到 0x10FFFF 的範圍。 最常用的字元具有可在記憶體和磁碟上納入 16 位元單字的字碼指標值,但是字碼指標值大於 0xFFFF 的字元則需要兩個連續的 16 位元單字。 這些字元稱為 「增補字元」(Supplementary Character),而這兩個連續的 16 位元單字則稱為 「Surrogate 字組」(Surrogate Pair)。

如果您使用增補字元:

  • 增補字元可用於 90 (含) 以上定序版本的排序及比較作業。

  • 所有 _100 層級定序都支援含有增補字元的語言排序。

  • 不支援在中繼資料內使用增補字元,例如資料庫物件的名稱。

  • 在 SQL Server 2012 中引進,新的補充字元系列 (SC) 定序可以搭配 資料類型 ncharnvarcharsql_variant 和 使用。 例如: Latin1_General_100_CI_AS_SCJapanese_Bushu_Kakusu_100_CI_AS_SC(如果使用日文定序的話)。

    SC 旗標可套用至:

    • 90 版本的 Windows 定序

    • 100 版本的 Windows 定序

    SC 旗標無法套用至:

    • 80 版本的非版本控制 Windows 定序

    • BIN 或 BIN2 二進位定序

    • SQL* 定序

下表將比較當某些字串函數和字串運算子使用增補字元搭配或不搭配 SC 定序時,這些函數和運算子的行為。

字串函數或運算子 搭配 SC 定序 不搭配 SC 定序
CHARINDEX

LEN

PATINDEX
將 UTF-16 Surrogate 字組視為單一字碼指標。 將 UTF-16 Surrogate 字組視為兩個字碼指標。
LEFT

REPLACE

REVERSE

RIGHT

SUBSTRING

STUFF
這些函數會將每個 Surrogate 字組視為單一字碼指標,並且如預期方式運作。 這些函數可能會將 Surrogate 字組拆開,造成無法預期的結果。
NCHAR 傳回對應至指定之 Unicode 字碼指標值 (在 0 到 0x10FFFF 的範圍內) 的字元。 如果指定的值位於 0 到 0xFFFF 的範圍內,就會傳回單一字元。 若為更高的值,則傳回對應的 Surrogate。 高於 0xFFFF 的值會傳回 NULL 而非對應的 Surrogate。
UNICODE 傳回 UTF-16 字碼指標 (在 0 到 0x10FFFF 的範圍內)。 傳回 UCS-2 字碼指標 (在 0 到 0xFFFF 的範圍內)。
符合單一萬用字元

萬用字元 - 不相符的字元
增補字元支援所有萬用字元作業。 增補字元不支援這些萬用字元作業, 但支援其他萬用字元運算子。

GB18030 支援

GB18030 是一種獨立標準,可供中華人民共和國進行中文字元的編碼。 在 GB18030 中,字元的長度可以是 1、2 或 4 個位元組。 SQL Server 可在 GB18030 編碼的字元從用戶端應用程式進入伺服器時加以辨識,並在轉換後以原生模式將其儲存為 Unicode 字元,藉以支援這種字元。 當 GB18030 編碼的字元儲存在伺服器中後,任何後續作業都會將其視為 Unicode 字元。 您可以使用任何中文定序,最好是使用最新的 100 版本。 所有 _100 層級定序都支援含有 GB18030 字元的語言排序。 如果資料包含 (代理字組) 的增補字元,您可以使用 SQL Server 2019 (15.x) 中提供的 SC 定序來改善搜尋和排序。

複雜字集支援

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

  • 包括由右至左和由左至右兩種文字之組合的字集,如阿拉伯文和英文文字的組合。

  • 字元的形狀會隨著位置或是否結合其他字元而不同的字集,例如,阿拉伯文、印度文和泰文字元。

  • 泰文之類的語言,因為單字之間不中斷,所以需要用內部字典來辨識單字。

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

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

SQL Server 最佳作法定序變更

<SQL Server 最佳作法:移轉至 Unicode>

Unicode Consortium 網站

另請參閱

自主資料庫定序
選擇建立全文檢索索引時的語言
sys.fn_helpcollations (Transact-SQL)