为什么SQL Server认为N“”和N“”相等?

michaelkaplan在博客中解释了Unicode字符串是如何比较的。这一切都归结为一个字符串需要有一个重量,如果它没有它将被视为等于空字符串。

Sorting it all Out: The jury will give this string no weight

CJK Unified Ideographs 在WindowsXP/2003和SQLServer2005中 post Chinese_Simplified_Pinyin_100_CI_AS 或 Chinese_Simplified_Stroke_Order_100_CI_AS :

您总是可以使用任何二进制和binary2排序规则,尽管它不会给出正确的语言结果。对于SQL Server 2005,应该使用Chinese\u PRC\u 90\u CI\u AS或Chinese\u PRC\u Stoke\u 90\u CI\u AS,它们支持代理项对比较(但不支持语言比较)。对于SQLServer2008,您应该使用中文简体拼音和中文简体笔画顺序,这两种方法在语言上有更好的代理比较。我建议您使用这些排序规则作为服务器/数据库/表排序规则,而不是在比较期间传递排序规则名称。

因此,以下SQL语句将按预期工作:

select * from MyTable where N'' = N'㐀' COLLATE Chinese_Simplified_Stroke_Order_100_CI_AS;

可以在MSDN中找到所有受支持排序规则的列表:

SQL Server 2008 Books Online: Windows Collation Name

这个字符U+3422来自 CJK Unified Ideographs 表,这是unicode标准中一个相对晦涩的部分(而且在政治上也很繁杂)。我的猜测是,SQL Server根本不知道这一部分,或者出于政治考虑,甚至可能故意不实现它。

编辑 :看起来我的猜测是错误的,真正的问题是拉丁和日语的排序规则都没有定义该字符的权重。

如果你看看 Unihan data page

J-Source(日本政府规定的日本分类顺序)是空白的,因为它可能只在古典音乐中使用 Korean Hanja (现在只在某些上下文中使用的汉字。)

JIS 排序标准通常是排序 Kanji 日本人阅读的汉字(通常是汉字输入日本时的近似汉语发音),但这个汉字在日语中可能用得不多,甚至可能连日语发音都没有,所以没有添加到数据中。