为什么在OS和Linux之间UTF-8文本排序的顺序不同？

Question

我有一个带有UTF-8编码文本行的文本文件：

mac-os-x$ cat unsorted.txt
ウ
foo
チ
'foo'
津

如果它有助于再现这个问题，下面是一个校验和和以及文件中确切字节的转储，以及如何自己生成文件(在Linux上，使用base64 -d而不是-D)：

mac-os-x$ shasum unsorted.txt
a6d0b708d3e0cafb0c6e1af7450e9243da8cb078  unsorted.txt

mac-os-x$ perl -ne 'print join(" ", map { sprintf "%02x", ord } split //), "\n"' unsorted.txt
e3 82 a6 0a
66 6f 6f 0a
e3 83 81 0a
27 66 6f 6f 27 0a
e6 b4 a5 0a

mac-os-x$ echo 44KmCmZvbwrjg4EKJ2ZvbycK5rSlCg== | base64 -D > unsorted.txt

当我在Mac上对这个输入文件进行排序时(无论我是使用Mac附带的GNU sort 5.93，还是安装了GNU 8.23版本的Homebrew )，我都会得到以下排序结果：

mac-os-x$ env -i LANG=en_US.utf-8 LC_ALL=en_US.utf-8 /usr/bin/sort unsorted.txt
'foo'
foo
ウ
チ
津

mac-os-x$ echo `sw_vers -productName` `sw_vers -productVersion`
Mac OS X 10.10.1

mac-os-x$ /usr/bin/sort --version | head -1
sort (GNU coreutils) 5.93

当我在Linux上用相同的区域设置对同一个文件进行排序时(我在CentOS5.5和Centos 6.5上都进行了测试)，得到了不同的结果：

linux-centos-6.5$ env -i LANG=en_US.utf-8 LC_ALL=en_US.utf-8 /bin/sort unsorted.txt
ウ
チ
foo
'foo'
津

linux-centos-6.5$ cat /etc/redhat-release
CentOS release 6.5 (Final)

linux-centos-6.5$ /bin/sort --version | head -1
sort (GNU coreutils) 8.4

请注意日本kana与英语的不同位置，以及两行之间的不同排序顺序，这两行仅通过单引号不同。

为了在这个组合中添加另一个变体，我注意到在一个非常旧的FreeBSD 6框中，我得到了与OS相同的排序顺序：

freebsd-6.0$ env -i LANG=en_US.utf-8 LC_ALL=en_US.utf-8 /usr/bin/sort unsorted.txt
'foo'
foo
ウ
チ
津

freebsd-6.0$ uname -rs
FreeBSD 6.0-RELEASE

freebsd-6.0$ sort --version | head -1
sort (GNU coreutils) 5.3.0-20040812-FreeBSD

我预计在每种情况下排序顺序都是相同的，因为所有情况都使用GNU，它们都具有相同的地区设置。我尝试单独设置LC_COLLATE，并尝试使用LC_COLLATE=C强制按字节顺序排序，但这并没有改变任何结果。

为什么我的示例输入文件在OS和Linux之间排序不同？我怎么能强迫这两个系统产生相同排序的文本(我不在乎哪一个变体，只要两者之间是一致的)？

Answer 1

看起来-- sort 并没有保留正确的UTF-8命令。

十六进制UTF-8表示您的unsorted.txt (第一个字母)将是：

ウ - 30A6 foo - 0066 チ - 30C1 'foo' - 0027 津 - 6D25 取自http://www.ltg.ed.ac.uk/~richard/utf-8.cgi?input=%E3%82%A6&mode=char

因此，根据unicode排序规则(http://www.unicode.org/Public/UCA/latest/allkeys.txt)进行适当的排序应该是：

'foo' -第487行 foo - line 8966 ウ -第20875行 チ -第21004行 津 -文件中没有

因此，为了回答您的问题，您的linux机器向sort函数提供了错误的排序表。不幸的是，我不知道这可能是什么原因。

PS:有类似的问题，你的这里。

编辑

正如@ instead注意到的那样，glibc并不使用UCA，而是ISO-14651。这个错误报告建议向UCA迁移。不幸的是，它仍未解决。

此外，它还可以以某种方式连接到关于ls案件不敏感的问题 on MacOSX上。有些人甚至认为这与HFS文件系统有关。