我应该为多语言网站选择哪种排序规则？

Question

排序规则对查询速度有任何影响吗？表的大小是否根据排序规则而变化？

如果我想构建一个必须支持所有可能语言的网站（例如 Google），推荐的排序规则是什么？

我将需要存储的字符，例如???，我的搜索过的网站将有返回something的sóméthíng输入，它必须是不区分大小写也是如此。

我怎么知道哪个是最好的选择？哪种排序规则更适合这种情况？

Answer 1

一般来说，Unicode 变体之一可能最适合广泛的语言支持 - UTF-8 每个代码点将使用更少的内存，因此在您发现自己需要进行的任何时间/空间权衡中都有轻微的优势；但是，我认为 UTF-8 无法表示一些更深奥的语言/脚本（但我不能 100% 确定，我还没有对此事进行详尽的研究）。

这篇维基百科文章可能对每个人的缺点/优点有所启发。

Answer 2

我相信您应该使用不区分重音和大小写的 Unicode 排序规则。请阅读 MSDN 文章选择排序规则和使用 sql 排序规则以及所有链接的文章。

Answer 3

我认为所陈述的问题（在 2015-04-20，“Which collat​​ion [...]”）并不是什么意思，因为接受的答案谈论的是编码而不是整理。让我回答所陈述的问题而不是预期的问题，只是因为我认为它很有趣:-)

维基百科说“整理是将书面信息组装成标准顺序”。在计算中，整理具有“这种顺序的规范”的含义。换句话说，排序规则是（或暗示）三路比较函数的定义。

我认为简短的回答是“肯定可能”。至少我知道以下恶作剧：

#!/usr/bin/python
name = u"Jonas K\xf6lker" # \xf6 is o-umlaut
enc = name.encode('utf-8')
assert len(name) == 12  # \xf6 is one character
assert len(enc) == 13   # but two bytes in utf-8

import locale
locale.setlocale(locale.LC_COLLATE, "da_DK.utf8") # works on my machine
long_form = locale.strxfrm(enc)
assert len(long_form) == 38

locale.strxfrm是一个函数Returns a string that behaves for cmp locale-aware，也就是说，它对一个字符串进行编码，使得与另一个类似编码的字符串的逐字节标准字典比较将产生与根据语言环境指定的排序规则函数比较字符串相同的结果。

一些观察结果：在 中da_DK.utf8，字符串ouüö已排序。在 中de_DE.utf8，字符串oöuü已排序。请注意，len(long_form) == 38并且 38 > 13。（长度也是 38 英寸de_DE.utf8。）

如果您的数据库在某个字符串字段上有一个索引，根据 整理da_DK.utf8，它可能在内部做一些类似的事情strxfrm，以便进行简单的比较。（另一方面，磁盘很慢。如果每个字符的比较成本更高，而通过比较较少的字符来抵消，则基于更紧凑的表示进行索引可能会更快。）

你问“排序规则对查询速度有什么影响吗？”，我很确定答案是肯定的：“C”（又名“POSIX”）排序规则只是比较 unicode 代码点值，而丹麦语（da_DK.utf8) 和德语 ( de_DE.utf8) 语言环境做一些更棘手的事情。这将对查询速度产生一些影响，尽管我怀疑这不值得担心。

“表格的大小是否会根据排序规则而改变？” — 我可以想象有一个根据一个排序规则的索引和一个根据另一个排序规则的不同索引，或者只是这两个索引中的一个，并strxfrm应用了一些类似的转换。在那个假设场景中，如果有两个具有不同大小特征的排序规则，答案是肯定的。

“推荐的排序规则是什么？” — 这取决于您为什么需要对字符串进行排序。如果只是有一些规范的字符串排序方式，我可能会选择“C”。如果要根据人类的期望以排序的顺序向用户呈现数据，而这些期望是由他们的文化塑造的，并且您希望数据库（而不是其他层）进行排序，那么也许您应该为每个排序规则构建一个索引，即至少有一项da_DK.utf8适用于丹麦人，一项de_DE.utf8适用于德国人。不过，我认为这可能会很快变得相当大。

所有这些都高度依赖于数据库的内部工作方式；我认为它远远超出了“标准化”（大声笑！）SQL。与往常一样，请查阅特定数据库系统的文档。