URL编码是将非ASCII或保留字符（如空格→%20、中文→%E4%B8%AD）按UTF-8字节+十六进制转义规则转换为%XX格式的机制；不能暴力删%因需整体识别多字节序列，且%XX必须合法校验并还原为原始字节流。
什么是URL编码，为什么不能直接用std::string::erase暴力删
URL编码（Percent-encoding）是把非ASCII或保留字符（如/、?、&）转成%XX形式的规则，例如空格→%20，中文“中”→%E4%B8%AD。它总是以%开头，后跟两个十六进制数字（大小写不敏感）。直接搜索并删除所有%或%20会出错：可能误删合法内容（比如用户ID含%），更严重的是——%E4%B8%AD是三个连续编码单元，必须整体识别、整体解码，不能只删%或只替换成一个字符。
用std::regex_replace一步解码最简但有陷阱
正则确实能匹配%[0-9A-Fa-f]{2}，再用回调函数转义，但要注意三点：
-
std::regex在部分旧编译器（如GCC 4.9前）性能差、不支持ECMAScript模式下的Unicode感知，别指望它高效处理长URL - 正则替换无法处理连续编码（如
%E4%B8%AD），因为每次只匹配单个%XX，而UTF-8多字节字符必须三组一起解，否则得到乱码 - 必须手动做
std::stoi(..., nullptr, 16)转字节，再确保结果拼成合法UTF-8字节序列；若输入非法（如%GG），得决定是跳过、保留原样还是抛异常
示例安全解法（仅处理合法编码，跳过非法）：
std::string url_decode(const std::string& s) {
std::string out;
out.reserve(s.size());
for (size_t i = 0; i < s.size(); ++i) {
if (s[i] == '%' && i + 2 < s.size()) {
char hex1 = s[i+1], hex2 = s[i+2];
if (isxdigit(hex1) && isxdigit(hex2)) {
char byte = static_cast<char>(
std::stoi(std::string({hex1, hex2}), nullptr, 16)
);
out += byte;
i += 2; // 跳过已处理的两位
continue;
}
}
out += s[i];
}
return out;
}
遇到加号+要单独处理：它不是URL编码，但代表空格
application/x-www-form-urlencoded格式（常见于表单提交）里，空格被编码为+而非%20。标准URL路径中不用+，但实际数据常混用。所以严格来说，“移除URL编码”应包含这步：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 先做
+→' '替换（只在query部分？看需求；若整个字符串都按form-urlencoded解析，就全局换） - 再做
%XX解码；顺序不能反，否则%2B（+号本身编码）会被误当成+处理 - 注意：如果原始字符串明确是URI path（RFC 3986），
+就是字面量，不该动；只有确认是query或form body才替换
边界情况比想象中多：空字节、超长序列、嵌套编码
真实数据里可能有%00（C字符串终结符）、%FF%FF（非法UTF-8）、甚至%2525（即%25被二次编码成%2525）。这些不会被上面简单循环捕获：
-
%00解出来是\0，存入std::string完全合法，但后续若传给C函数（如printf）会截断——得确认下游是否容忍二进制数据 - 连续三个
%XX如%E4%B8%AD需识别为一个UTF-8字符，但简单循环只认单个%XX，会错误拆成三个字节；正确做法是检测首字节范围（0xC0–0xF4），再根据前缀推断后续字节数 - 二次编码（
%2520→%20→空格）需递归解码，但一般场景不推荐自动递归，容易陷入死循环；建议由调用方控制是否重复调用解码函数
真正健壮的实现得区分上下文：是纯路径解码？还是完整URL query解析？后者还需按&和=切分键值对，再分别解码——这时候别自己造轮子，用boost::urls或cpp-httplib的detail::url_decode更稳妥。
