不能直接用 std::map 做繁简映射，因为繁简字非一一对应（如「后」有「後」「后」两义），且需整词替换（如「裏面」→「里面」），必须按最长匹配原则从长到短查询，vector+降序排序可实现该逻辑。
为什么不能直接用 std::map 做繁简映射
因为繁体字和简体字不是一一对应关系，比如「後」→「后」，但「后」→「後」还是「后」（皇后/后来），直接键值对查表会丢语义。更麻烦的是，有些词必须整词替换，比如「裏面」→「里面」，拆成单字会错成「裡面」→「里面」+「面」→「面」。
实际可行的思路是：用 std::unordered_map 存储「词或字」到「目标字符串」的映射，但查询时必须从长到短匹配（即最长匹配原则），否则「長」和「長安」共存时，先匹配到「長」就截断了「長安」。
- 优先构建词表（如 OpenCC 的
zhs2zht.ini格式），而非单字表 - 映射键必须按长度降序排序，否则
find_first_of或简单遍历会命中短键 - 避免用
std::string::replace原地替换——它不保证偏移不变，多次替换易错位
如何用 vector> 实现可排序的映射表
比起 std::map 或 std::unordered_map，std::vector<:pair std::string>></:pair> 更适合手动控制匹配顺序。关键是初始化时按键长度降序排列：
std::vector<std::pair<std::string, std::string>> mapping = {
{"長安", "长安"},
{"後悔", "后悔"},
{"後", "后"},
{"裏", "里"}
};
std::sort(mapping.begin(), mapping.end(), [](const auto& a, const auto& b) {
return a.first.length() > b.first.length(); // 长的在前
});
这样遍历时就能自然实现最长匹配。注意：中文字符在 UTF-8 下占 3 字节，std::string::length() 返回字节数，所以「長」是 3，「長安」是 6，排序有效；但如果混入 ASCII 字符（如半宽标点），需统一用 UTF-8 aware 方案（如 ICU 或 utf8cpp）处理长度。
立即学习“C++免费学习笔记（深入）”；
- 不要用
std::map自动排序——它的默认字典序对中文无意义 - 如果映射表很大（>10k 条），线性遍历慢，可改用 AC 自动机或 trie，但绝大多数场景下 vector + sort 足够
- 加载时校验重复键：用
std::set检查mapping[i].first是否已存在
怎么安全地逐段替换而不破坏 UTF-8 编码
直接用 std::string::find 和 substr 是最稳妥的方式，前提是每次只替换一个匹配项，然后从下一个位置继续搜，避免重叠和越界：
std::string convert(const std::string& src, const std::vector<std::pair<std::string, std::string>>& mapping) {
std::string result;
size_t pos = 0;
while (pos < src.length()) {
bool matched = false;
for (const auto& [from, to] : mapping) {
if (src.substr(pos, from.length()) == from) {
result += to;
pos += from.length();
matched = true;
break;
}
}
if (!matched) {
result += src[pos++];
}
}
return result;
}
这个实现不依赖任何外部库，兼容所有 C++11+ 编译器，且能正确处理 UTF-8 多字节序列——因为只按字节比较、不拆解 Unicode 码点。
- 别用
std::string::replace在原串上操作：它会移动后续内存，导致 pos 计算错乱 - 别用
std::wstring+std::locale：Windows 上 locale 对 GBK/UTF-8 支持不稳定，Linux 上也未必覆盖全部汉字 - 如果性能敏感（如每秒处理 MB 级文本），可预计算每个起始位置的最大可能匹配长度，跳过无效检查
遇到「一简对多繁」怎么办（比如「发」→「發/髮」）
纯静态映射表无法解决歧义，必须引入上下文判断。最轻量的做法是加规则层：例如「发」后面跟「财」「展」「明」等字时映射为「發」，跟「型」「根」「廊」时映射为「髮」。
实际工程中，OpenCC 用的是基于词性的双数组 trie + 规则引擎，但自己实现只需加一层条件判断：
if (from == "发") {
if (pos + from.length() < src.length()) {
char next = src[pos + from.length()];
if (next == '财' || next == '展' || next == '明') {
result += "發";
pos += from.length();
continue;
} else if (next == '型' || next == '根') {
result += "髮";
pos += from.length();
continue;
}
}
}
这种硬编码规则适用于固定场景（如游戏本地化、合同模板），但若需通用支持，就得引入分词库（如 cppjieba）先切词再映射——否则「发展」会被当成「发」+「展」，而「发廊」里的「发」本应是「髮」却匹配不到。
- 静态映射永远只是基础，真正可靠的繁简转换必须结合分词
- OpenCC 的词表本身已含部分上下文规则（如「头发」、「发展」单独列项），优先用现成词表比手写规则更可靠
- 测试时务必覆盖「发」、「干」、「行」、「后」等典型多音多义字，它们占错误 80% 以上
