为什么在带有越南语_CI_AI 排序规则的 SQL Server 上，'tr' 和 'tR' 之间的比较会失败？

Question

越南语校对中的“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' 的其他组合则不然。

Answer 1

鉴于此行为存在于该排序规则的较新版本中，并且“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. tr
2. 时间
3. TR

"tR" 的组合不会形成 "TR" 字符，很可能是因为这是一个不自然的大写，更意味着单词的分离，例如 Pascal / Camel -casing（例如“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. CH
2. 胃肠道
3. KH
4. NG
5. NH
6. PH值
7. 曲
8. 泰

有关使用排序规则/编码/Unicode 的更多信息，请访问我的网站：排序规则信息

^**排序权重文件包含代码点及其各自的权重值，这些值被分为变音符号权重、案例权重等类别。通常有描述转换的部分，例如将两个代码点组合为单个权重特定的文化/地区（例如越南语）。可以有将预先组合的字符分解为单个字符等的映射。请参阅：访问 Windows 排序权重表。

注意： Microsoft 提供了多个排序权重文件，因为随着 Windows 和 Windows Server 的新版本的发布，这些文件经过多年的更新。请记住，这些文件中没有一个与 SQL Server 使用的规则 100% 匹配。我们得到的最接近的是Windows Server 2008 Sorting Weight Table.txt文件，它应该与版本 100 排序规则的行为（即_100_名称中包含的排序规则）非常匹配。