因为utf-8是变长编码，std::strcmp逐字节比较、std::tolower仅处理单字节，会拆解多字节序列导致乱码、越界或未定义行为；必须先解码为unicode码点，再按unicode标准做大小写折叠。
为什么 std::strcmp 和 std::tolower 不能直接用于 UTF-8 字符串大小写比较
因为 UTF-8 是变长编码，一个 Unicode 字符可能占 1~4 字节，而 std::strcmp 按字节逐个比较，std::tolower 只处理单字节（即 ASCII 范围的 char），对非 ASCII 字节（如 0xC3、0xA9）会误判甚至导致未定义行为。直接用它们比较 "café" 和 "CAFÉ" 会失败——后者两个字节组成的 é 在大小写转换后无法被单字节函数识别。
如何安全地将 UTF-8 字符串转为 Unicode 码点再做大小写归一化
必须先解码 UTF-8 字节流为 Unicode 码点（char32_t），再对每个码点调用标准 Unicode 大小写映射（不是 ASCII 那套），最后重新编码或直接比较码点序列。C++20 提供了 std::text::utf8_to_utf32（需 <text></text> 头文件，但目前主流编译器尚未完全支持），所以更现实的做法是借助轻量库或手写解码逻辑。
- 推荐用
utf8cpp（头文件仅utf8.h）：它提供utf8::utf8to32将std::string解码为std::vector<char32_t></char32_t> - 避免用
std::wstring_convert+std::codecvt_utf8：C++17 已弃用，且在 GCC/Clang 上行为不一致 - 解码后不要用
toupper/tolower：改用std::toupper(c, std::locale(""))或更稳妥的 ICU / Boost.Locale —— 但若只需基础拉丁+常见欧洲字符，可用std::toupper(c, std::locale("C"))不起作用，必须用带语言环境的 locale，例如std::locale("en_US.UTF-8")
示例关键片段：
#include "utf8.h"
#include <locale>
#include <vector>
#include <algorithm>
std::vector<char32_t> to_lower_codepoints(const std::string& s) {
std::vector<char32_t> cp;
utf8::utf8to32(s.begin(), s.end(), back_inserter(cp));
std::locale loc("en_US.UTF-8");
for (auto& c : cp) {
c = std::tolower(static_cast<wint_t>(c), loc);
}
return cp;
}
</wint_t></char32_t></char32_t></algorithm></vector></locale>
实际比较时要不要全程转码？有没有更省资源的做法
如果只是做一次比较（比如查找、排序），全程转码是清晰且安全的；但如果高频调用（如字符串容器排序），每次解码+转码开销大。此时可考虑“懒解码+逐字符比较”：从头开始同步读取两个 UTF-8 字符串，每次解码出一个码点，立即做大小写归一化并比较，任一不等就返回结果，避免构造完整码点向量。
- 手写 UTF-8 解码逻辑并不复杂：检查首字节高位模式（0xxxxxxx / 110xxxxx / 1110xxxx / 11110xxx），再读取对应数量后续字节，组合出码点
- 注意边界：无效 UTF-8 序列（如
0xC0 0x00）应视为错误或按字节 fallback 处理（取决于业务容忍度） -
std::locale的std::toupper/std::tolower对无效码点（如 >0x10FFFF）行为未定义，需提前过滤
Windows 上用 CompareStringEx 能否替代手写逻辑
可以，而且更可靠——Windows API 的 CompareStringEx 原生支持 UTF-8（通过 LCMAP_UPPERCASE 标志和 dwFlags = NORM_IGNORECASE），但前提是传入的是合法 UTF-8 字节流，并指定 LOCALE_NAME_USER_DEFAULT 或具体 locale 名（如 L"en-US"）。
- 调用前必须确保输入是有效 UTF-8，否则结果未定义
- 返回值是
CSTR_EQUAL/CSTR_LESS_THAN/CSTR_GREATER_THAN，不是 -1/0/1，注意转换 - Linux/macOS 无等价系统 API，跨平台项目仍需备选方案
真正麻烦的从来不是“怎么写”，而是“谁来保证输入 UTF-8 合法”——很多所谓“UTF-8 字符串”其实是混合编码或截断数据，这时候大小写比较的结果本身就不可信。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
