Question

我尝试了解它们但我没有发现任何差异，除了strcoll() this引用说它

根据LC_COLLATE类别定义的当前语言环境比较两个空终止字符串。

关于第二个想法，我知道我正在问另一个问题以获得详细答案，对于C和C ++，这个语言环境究竟是什么？

Answer 1

strcmp()逐个获取字符串的字节，并将它们与字节数进行比较。

strcoll()获取字节，使用语言环境对其进行转换，然后比较结果。转换根据语言重新排序。在法语中，强调的字母出现在非强调的字母之后。所以é在 e 之后。但是，é在 f 之前。 strcoll()做对了。 strcmp()不太好。

但是，在许多情况下strcmp()就足够了，因为您不需要在使用的语言（语言环境）中显示排序的结果。例如，如果您只需要快速访问由字符串索引的大量数据，则可以使用由该字符串索引的映射。使用strcoll()进行排序可能完全没用，这通常非常慢（至少与strcmp()相比。）

有关字符的详细信息，您可能还需要查看Unicode网站。

关于语言环境，它是语言。默认情况下，它设置为“C”（或多或少，没有区域设置）。选择位置后，将相应地设置区域设置。您还可以设置LC_LOCALE环境变量。实际上有很多这样的变数。但一般来说，您使用预定义函数自动将这些变量考虑在内并为您做正确的事情。（即格式化日期/时间，格式数/度量，计算大写/小写等）

Answer 2

出于某些原因，在我测试的所有unicode语言环境中，在几个不同版本的glibc上，strcoll（）为任何两个平假名返回零。这打破了排序， uniq 以及以某种方式与字符串顺序交互的所有内容。

$ echo -e -n＆＃39;い\ nろ\ nは\ nに\ nほ\ nへ\ nと\ n＆＃39; |排序| uniq的

い

简直无法修复。来自世界各地的人们对于是否会有不同的想法。应放在＆＃39;ろ＆＃39;之前或之后，但没有人会认为它们是相同的。

不，将您的语言环境设置为日语并不重要：

$ LC_ALL = ja_JP.utf8 LANG = ja_JP.utf8 LC_COLLATE = ja_JP.utf8 echo -e -n＆＃39;い\ nろ\ nは\ nに\ nほ\ nへ\ nと\ n＆＃ 39; |排序| uniq的

い

在一些官方邮件列表中进行了讨论，但是猜测是什么，它是在2002年，它从未被修复，因为人们不关心：https://www.mail-archive.com/linux-utf8@nl.linux.org/msg02658.html

我们在某一天发生了这个错误，最终我们唯一的出路就是将整理区域设置为＆＃34; C＆＃34;并依赖于utf-8编码的优良特性。这是一次可怕的经历，因为一个人不应该在C＆＃34; C＆＃34;处理全日本数据时的语言环境。

为了您的理智，请不要直接使用strcoll。更安全的变体可能是：

FromTraversable[Input, LUB, Out]

以防strcoll（）决定搞砸你......

strcmp（）和strcoll（）有什么区别？

2 个答案: