为什么 ICU4J 不匹配 UTF-8 排序顺序？

Question

我很难理解 unicode 排序顺序。

当我在 ICU4J 55.1 下运行 Collator.getInstance(Locale.ENGLISH).compare("_", "#") 时，我得到 return 值 -1 表明 _ 在 # 之前。

但是，查看 http://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=dec 我发现 # (U+0023) 在 _ (U+005F) 之前。为什么 ICU4J returning 的值为 -1？

Answer 1

将 Mark Ransom 的评论转换为答案：

单个字符的排序基于排序规则 table，与代码点编号关系不大。参见：http://www.unicode.org/reports/tr10/#Default_Unicode_Collation_Element_Table
如果您关注该页面上的第一个 link，它会指向 allkeys.txt，它给出了默认的排序规则。
特别是，_ 是 005F ; [*020B.0020.0002] # LOW LINE 而 # 是 0023 ; [*0391.0020.0002] # NUMBER SIGN。请注意，_ 的归类编号低于 #.

Answer 2

首先，UTF-8只是一种编码。它指定了如何在物理上存储 Unicode 代码点，但不处理排序、比较等。

现在，您链接到的页面以数字代码点顺序显示所有内容。如果使用二进制排序规则（在 SQL 服务器中，这将是名称以 _BIN 和 _BIN2 结尾的排序规则）。但是非二进制排序要复杂得多。规则描述如下：Unicode Collation Algorithm (UCA).

显示：

005F  ; [*010A.0020.0002] # LOW LINE
...
0023  ; [*0290.0020.0002] # NUMBER SIGN

切记任何地区/文化都可以覆盖这些基本规则，这一点非常重要。因此，虽然上面提到的几行解释了这种特定情况，但其他情况需要检查 http://www.unicode.org/repos/cldr/tags/release-28/common/collation/ 以查看是否有任何特定于语言环境的覆盖。

Why doesn't ICU4J match UTF-8 sort order?