为什么ICU4J不符合UTF-8排序顺序？

Question

我很难理解unicode排序顺序。

当我在ICU4J 55.1下运行Collator.getInstance(Locale.ENGLISH).compare("_", "#")时，我得到-1的返回值，表示_出现在#之前。

然而，看http://www.utf8-chartable.de/unicode-utf8-table.pl?utf8=dec我看到#（U + 0023）出现在_之前（U + 005F）。为什么ICU4J的值为-1？

Answer 1

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

• 单个字符的排序基于排序规则表，该排序表与代码点数量关系不大。请参阅：http://www.unicode.org/reports/tr10/#Default_Unicode_Collation_Element_Table
• 如果您按照该页面上的第一个链接进行操作，则会显示allkeys.txt，这会提供默认的排序规则。
• 特别是，_为005F ; [*020B.0020.0002] # LOW LINE而#为0023 ; [*0391.0020.0002] # NUMBER SIGN。请注意，_的整理编号低于#的编号。

Answer 2

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

现在，您链接的页面以数字代码点顺序显示所有内容。如果使用二进制排序规则（在SQL Server中，这将是以_BIN和_BIN2结尾的名称的排序规则，那么事情就会排序。但非二进制排序要复杂得多。这里描述了规则：Unicode Collation Algorithm (UCA)。

基本规则可在此处找到：http://www.unicode.org/repos/cldr/tags/release-28/common/uca/allkeys_CLDR.txt

它显示：

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

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