為什麼在具有越南語_CI_AI 排序規則的 SQL Server 上比較 ’tr’ 和 ’tR’ 失敗？

越南語整理中的“tR”似乎有一些特別之處。了解它的人是否可以簡單地解釋一下。這個問題是在我們的產品安裝在“越南語”整理的 SQL Server 上時發現的。架構中的一個表的名稱中包含“tR”，但儲存過程正在引用所有小寫“tr”的表。這個參考失敗了。

我猜這種情況類似於其他排序規則中的’阝’匹配’ss’。

這是一個複製品：

select  case when 'tr' = 'tR' COLLATE SQL_Latin1_General_CP1_CI_AS   then 'match' else 'no match' end 
select  case when 'tr' = 'tR' COLLATE Vietnamese_CI_AI   then 'match' else 'no match' end 
select  case when 'tr' = 'TR' COLLATE Vietnamese_CI_AI   then 'match' else 'no match' end 

結果：

-----
match


--------
no match


-----
match

第二個 T-SQL 產生不匹配。’t’ 和 ‘R’ 的其他組合沒有。

鑑於此行為存在於該排序規則的較新版本中，並且諸如“fr”和“fR”之類的組合確實匹配（如預期的那樣），它只能是該字元組合的特定於文化的語言規則。

SELECT CASE WHEN 'tr' = 'tR' COLLATE Vietnamese_100_CI_AI THEN 'Y' ELSE 'N' END;
-- N

SELECT CASE WHEN 'fr' = 'fR' COLLATE Vietnamese_100_CI_AI THEN 'Y' ELSE 'N' END;
-- Y

我在排序權重文件中找到了規則******。特殊的是“tr”的組合（越南語），而不是“tR”。越南語似乎有某些字母組合組合成一個字元，例如西班牙語中的“CH”和“LL”組合。因此，以下是“T”+“R”組合形成越南語的“字元”的有效組合：

1. 孩子們
2. 孩子們
3. 孩子們

“tR”的組合不形成“TR”字元，很可能是因為這是一種不自然的大寫，更多地意味著單詞的分離，例如使用 Pascal / Camel 大小寫（例如“Cha tR oom”和“cha tR oom”，分別與“ tR ogdor the Burninator ”相對（我有根據的猜測）。

以下範例顯示“tr”組合在“tz”之後排序：

SELECT *
FROM   (VALUES (N'Atra'), (N'Atz'), (N'Aua'), (N'Ata'), (N'AtR')) tmp(col)
ORDER BY tmp.[col] COLLATE Vietnamese_100_CI_AI ASC
/*
Ata
AtR
Atz
Atra
Aua
*/

這些結果是由於“tr”組合形成一個自然排序在“t”之後的單個字元。意思是，排序算法看到以下內容：

Character #
1  |  2   | 3
-------------
A  |  t   | a
A  |  t   | R
A  |  t   | z
A  |  tr  | a
A  |  u   | a

越南語還有其他兩個字母組合，其工作方式與“TR”相同（即不區分大小寫：）tr == Tr == TR <> tR：

1. 甲烷
2. 給
3. KH
4. NG
5. 小的
6. 酸鹼度
7. QU
8. TH

有關使用排序規則/編碼/Unicode 的更多資訊，請訪問我的網站：排序規則資訊

---

******排序權重文件包含程式碼點及其各自的權重值，這些權重值分為不同的類別，例如變音符號權重、案例權重等。通常有描述轉換的部分，例如將兩個程式碼點組合為單個權重特定的文化/地區（例如越南語）。可以有將預先組合的字元分解為單個字元等的映射。請參閱：訪問 Windows 排序權重表。

注意： Microsoft 提供了多個分類權重文件，因為這些文件多年來隨著新版本 Windows 和 Windows Server 的發布而更新。請記住，這些文件都不是 100% 匹配 SQL Server 使用的規則。我們得到的最接近的是Windows Server 2008 Sorting Weight Table.txt文件，它應該與版本 100 排序規則（即_100_名稱中帶有的排序規則）的行為非常匹配。

引用自：https://dba.stackexchange.com/questions/298499