为何NVarchar中'œ'匹配'oe'而Varchar中不匹配？

这其实是SQL Server对Unicode和非Unicode字符串的排序规则与字符等价性处理逻辑差异导致的，咱们结合你的测试例子来拆解：

核心原因：Unicode排序规则的等价匹配 vs 单字节字符集的精确匹配 #

1. NVarchar（Unicode类型）的处理逻辑 #

NVarchar存储的是Unicode字符，SQL Server对Unicode字符串使用的排序规则（比如常见的SQL_Latin1_General_CP1_CI_AS）会遵循Unicode标准中的字符等价性规则——对于很多欧洲语言里的连字（比如œ，法语里的连字），排序规则会将其视为对应的字符组合（oe）的等价形式。

也就是说，在Unicode比较/替换操作中，N'œ'和N'oe'会被排序规则判定为"语义相等"，哪怕它们的底层码点完全不同：

• œ是单个Unicode码点U+0153
• oe是两个独立码点U+006F（o）+ U+0065（e）

2. Varchar（非Unicode类型）的处理逻辑 #

Varchar使用的是单字节字符集（比如Windows-1252，SQL Server默认的Latin1字符集），这里的œ是一个单独的单字节字符（编码为0x9C），而oe是两个独立的单字节字符（0x6F + 0x65）。

单字节字符集的排序规则只会做精确的字节匹配，不会把单个字符和两个字符的组合视为等价，所以'œ'和'oe'在Varchar比较中完全是两回事。

结合你的测试示例验证 #

测试示例1：REPLACE函数的差异 #

SELECT REPLACE(N'Chloe', 'œ', 'o'), REPLACE('Chloe', 'œ', 'o')

• 第一个REPLACE(N'Chloe', 'œ', 'o')：因为NVarchar的等价规则，N'Chloe'里的oe被识别为和œ等价，所以被替换成o，结果是Chlo。
• 第二个REPLACE('Chloe', 'œ', 'o')：Varchar的'Chloe'里的oe是两个独立单字节字符，和单字节的œ（0x9C）不匹配，所以没有替换，返回原字符串Chloe。

测试示例2：相等性比较的差异 #

SELECT CASE WHEN N'œ' = N'oe' THEN 1 ELSE 0 END as NVarcharMatch, 
       CASE WHEN 'œ' = 'oe' THEN 1 ELSE 0 END as VarcharMatch

• NVarcharMatch返回1：Unicode排序规则认为两者语义等价，所以判定相等。
• VarcharMatch返回0：单字节字符的精确匹配下，单个字符和两个字符的长度、字节值都不一样，自然不相等。

内容的提问来源于stack exchange，提问作者Amy B