我們正在測試我們的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