C++ collate：字符串排序不是按 ASCII 码“硬排”，而是听 locale 的话

你有没有试过用 std::sort 对一串中文或带重音的法文单词（比如 café, naïve, Zoë）排序，结果发现 é 跑到了 z 后面，ü 排在了 a 前面？或者更离谱——同一段代码，在 macOS 上跑出的顺序，和在 Linux 容器里完全不一样？这时候别急着怀疑编译器 bug，大概率是 collate 在 quietly 发声。

std::collate 是 C++ 标准库里最安静、也最容易被忽略的本地化“裁判”。它不负责编码转换，也不管内存布局，只干一件事：定义两个字符串谁该排在前面——而且这个“前面”，由当前 locale 的语言习惯说了算。

很多人以为 std::string::operator< 或 std::lexicographical_compare 就是“字典序”，其实那是假字典序。真正的字典序，是德语词典里 ä 视为 ae 的等价变体，是西班牙语中 ch 曾经作为一个独立字母排在 c 之后（虽已废止，但老数据仍存在），是中文拼音排序里 张（zhāng）必须紧挨着 章（zhāng），而不是按 UTF-8 首字节 e5 bc b5 和 e7-ab a0 的十六进制大小硬比。

collate 的核心接口就两个：

• compare()：返回负值、0、正值，表示小于/等于/大于；
• transform()：把字符串映射成一个可安全做 memcmp 的字节序列（内部用，不常手写）。

关键在于：它默认绑定的是全局 C locale（"C"），也就是纯 ASCII 码序。所以 é（U+00E9，UTF-8 三字节 c3 a9）开头的字符串，在 C locale 下永远比 z（U+007A，单字节 7a）靠前——因为第一个字节 c3 > 7a。这显然不是人眼所见的“字典顺序”。

想让它“懂人话”，得换 locale。比如：

std::locale loc("de_DE.UTF-8"); // Linux/macOS
// 或 std::locale loc("German"); // Windows
auto& coll = std::use_facet<std::collate<char>>(loc);
std::vector<std::string> words = {"Ärger", "Apfel", "Zoo", "Ökologie"};
std::sort(words.begin(), words.end(), 
    [&coll](const std::string& a, const std::string& b) {
        return coll.compare(a.data(), a.data() + a.size(),
                            b.data(), b.data() + b.size()) < 0;
    });

这时 Ärger 会排在 Apfel 之后（德语中 Ä 视为 Ae，与 A 同级），而 Ökologie 在 Zoo 之前——这才是真实德语词典的逻辑。

但注意：collate::compare() 不是万能胶水。它只比较“整理权重”（collation weight），不处理大小写折叠、连字分解或 Unicode 正规化。比如 "cafe" 和 "café"，即使在法语 locale 下，compare() 默认也不会把 é 当作 e 的带调形式来等价处理——除非 locale 明确启用了二级强度（secondary strength），而标准库实现对此支持参差不齐。

这也是为什么实践中更稳的路径是：先做 Unicode 正规化（NFD/NFC），再转小写（或按需大小写归一），最后用 collate 比较。C++20 没有内置正规化，但 std::locale 的 collate 至少保证：同一 locale 下，transform() 输出的字节序列满足全序，且 compare(a,b) == memcmp(transform(a), transform(b)) ——这让你能在自定义容器里安全缓存 transform 结果，避免重复计算。

还有一点常被忽略：collate 是 facet，它活在 locale 对象的生命期内。不要保存 &coll 的裸引用去跨函数使用——万一 locale 临时对象析构了，你的引用就悬空了。稳妥做法是每次需要时 std::use_facet，或把 locale 本身作为成员变量长期持有。

另外，collate<char> 处理多字节编码（如 UTF-8）时，依赖底层 C 库对 locale 的实现。glibc、musl、Windows CRT 对 de_DE.UTF-8 的 collation 权重定义并不完全一致。如果你的程序要跨平台输出稳定排序，要么统一用 ICU 库（绕过 std::collate），要么接受“同 locale 下行为一致”这一底线——毕竟，语言本就没有绝对唯一的排序答案，只有约定俗成。

回到最初那个问题：为什么 café 有时排在 cake 前，有时在后？答案不在算法，而在你有没有告诉 C++：“我们现在说的是法语。”
collate 不是魔法，它是桥梁——一端连着二进制字节，另一端连着活的语言习惯。你给它什么 locale，它就还你什么秩序。

下次看到排序结果“不对劲”，先别改 sort 的 lambda，打开终端敲一句 locale，看看你代码正在说哪种语言。毕竟，让程序讲人话的第一步，是让它先听懂人话。