我们正在测试我们的Unicode兼容性应用程序，并且已经在拉丁字符集之外选择了随机字符进行测试。为什么SQL Server考虑N'和N'相等？
在拉丁文和日本整理系统下列等式为真（U+3422）：
N'㐢㐢㐢㐢' = N'㐢㐢㐢'
，但下面是不是（U+30C1）：
N'チチチチ' = N'チチチ'
这被发现时，测试使用第一个示例（使用U + 3422）的情况违反了唯一索引。我们是否需要对我们用于测试的角色更具选择性？显然我们不知道上述比较的语义。对于母语人士来说，这种行为会很明显吗？
Michael Kaplan有一篇博客文章，他解释了如何比较Unicode字符串。这一切都归结为一个字符串需要有一个权重，如果它不会被认为等于空字符串。
Sorting it all Out: The jury will give this string no weight
在SQL Server该重量是通过所定义的排序规则的影响。微软在Windows XP/2003和SQL Server 2005中增加了相应的排序规则CJK Unified Ideographs这post建议使用或Chinese_Simplified_Stroke_Order_100_CI_AS：
您可以随时使用任何二进制和binary2排序规则虽然它不会给你正确的语言结果。对于SQL Server 2005，您应该使用支持代理对比较的Chinese_PRC_90_CI_AS或Chinese_PRC_Stoke_90_CI_AS（但不是语言）。对于SQL Server 2008，您应该使用Chinese_Simplified_Pinyin_100_CI_AS和Chinese_Simplified_Stroke_Order_100_CI_AS，它们具有更好的语言替代比较。我建议您使用这些排序规则作为您的服务器/数据库/表排序规则，而不是在比较过程中传递排序规则名称。
所以下面的SQL语句会按预期工作：
select * from MyTable where N'' = N'㐀' COLLATE Chinese_Simplified_Stroke_Order_100_CI_AS;
所有支持的归类列表，可以在MSDN中找到：
全球化错误的另一个例子，您只需使用您的本地整理装运您的数据库并且在其他国家/地区无效。 – 2010-05-12 15:30:22
该字符U + 3422来自CJK Unified Ideographs表，这些表是unicode标准中比较模糊的（并且是政治上加载的）部分。我的猜测是，SQL Server根本不知道这一部分 - 或者由于政治考虑甚至有意不实施它。
编辑：看起来我的猜测是错误的，真正的问题是拉丁语和日语排序规则都没有为该字符定义权重。
什么是“台独”的汉字？ OMG，SQL Server是满洲人的数据库！ – 2010-05-12 12:31:17
@Dave：不是那么糟糕，但是那些CJK统一的表格就是试图系统地列出在中国，台湾，日本和韩国使用的所有汉字，包括各种历史发展和拼写改革。对于那些应该被视为单独的角色或者仅仅是同一角色的变体的分歧存在无穷的潜力，并且鉴于区域历史，这可能很快变成政治争论。 – 2010-05-12 12:48:55
如果您看看Unihan data page，角色似乎只有“K-Source”字段对应于韩国政府的映射。
我的猜测是MS SQL询问“这个字符是汉字吗？”如果是，则使用日语排序标准，如果排序规则编号不可用，则丢弃该字符 - 可能是SQL Server特定的问题。
我非常怀疑这是一个政治纠纷，因为另一个海报建议，因为角色甚至没有台湾或香港的编码映射。
更多的技术信息：因为它可能是在古典Korean Hanja只用了的J-源（由日本政府规定，日本排序顺序）是空白
（这是现在只有在某些情况下使用的中国文字。）日本政府的JIS排序标准一般按日文排序Kanji个字符阅读时（这通常是字符输入日本时的近似中文发音）。但是这个字符在日语中可能用得不多，甚至可能不会有一个日本的发音与它关联，所以没有被添加到数据中。
有趣的是，fileformat.info中提到了[U + 3422]（http://www.fileformat.info/info/unicode/char/3422/index.htm）以下的“[停止]：U + 3422不是一个有效的Unicode字符“。这可能是相关的。 – BalusC 2010-05-12 12:10:13
fileformat.info然后在破解。 U + 3422是中日韩统一表意文字扩展一套完全有效的字符。 – 2010-05-12 12:13:54
@BalusC：但是，unicode.org似乎认为它是一个有效的代码点。 – 2010-05-12 12:13:58