标准C++无内置URL解码函数，需手写轻量实现：识别%后两个十六进制字符（大小写不敏感），用std::isxdigit校验，stoi转字节；遇非法格式（如%结尾、%后不足两位）跳过；遍历时严格检查i+2 < len防越界。
标准C++没有内置URL解码函数，必须手写或借助第三方库；最稳妥的做法是自己实现一个轻量、不依赖外部头文件、能正确处理%xx转义和边界情况的解码逻辑。
如何识别并转换%xx十六进制转义序列
URL解码的核心是把形如%20、%E5%AD%97这样的序列还原为对应字节（UTF-8编码下即原始字符）。关键点在于：只对%后紧跟两个十六进制字符的部分做转换，其余内容原样保留；遇到非法格式（如%G1、%Z、%结尾）应跳过，不崩溃也不误改。
- 用
std::isxdigit判断后续两个字符是否为合法十六进制字符 - 用
std::stoi(s, nullptr, 16)或手动查表（"0123456789ABCDEF"）转成字节值 - 注意大小写：
%aF和%Af都合法，需统一转为大写或小写后再解析 - 别直接用
std::tolower处理整个字符串——可能误改非转义部分（如hello%20WORLD里的WORLD）
如何安全处理输入并避免越界访问
解码时最常踩的坑是数组越界：比如字符串以%结尾，或%后只剩一个字符，此时若强行取[i+1]和[i+2]会读越界。必须在每次访问前检查剩余长度。
- 遍历索引
i时，条件应为i + 2 才考虑匹配<code>%xx - 遇到
%但后面不足两位，直接把%当作普通字符追加到结果中 - 不要用
str.at(i)代替str[i]——前者抛异常，而URL解码函数不该因输入脏就中断流程 - 输出字符串建议预分配空间：
result.reserve(str.length())，因为解码后长度 ≤ 原长（每个%xx变1字节）
要不要对空格+做特殊处理
严格来说，+ → 空格是application/x-www-form-urlencoded的规则，不是通用URL Percent Encoding的标准。RFC 3986明确指出+在URI路径中无特殊含义，仅在查询参数（query string）中被约定为替代空格。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 如果你解码的是完整URL（如
https://example.com/path%20to/+file），则+应保留原义，不替换为空格 - 如果你解码的是query string（如
q=hello+world&lang=zh），则应在Percent解码**之后**再单独把+替换成' ' - 很多“万能”解码函数默认处理
+，反而导致路径解码出错（如把/api/v1/abc+def错解成/api/v1/abc def）
一个足够健壮的C++11实现示例
下面这段代码不依赖Boost或cpp-netlib，只用<string>、<cctype>、<cstdlib>，可直接粘贴进项目：
std::string url_decode(const std::string& s) {
std::string result;
result.reserve(s.length());
for (size_t i = 0; i < s.length(); ++i) {
if (s[i] == '%' && i + 2 < s.length()) {
if (std::isxdigit(s[i + 1]) && std::isxdigit(s[i + 2])) {
std::string hex_str = s.substr(i + 1, 2);
int char_code = std::stoi(hex_str, nullptr, 16);
result += static_cast<char>(char_code);
i += 2;
continue;
}
}
result += s[i];
}
return result;
}
它不处理+，符合RFC；对%开头但后续非法的情况完全容错；所有索引访问都有长度保护。真正需要兼容表单查询的场景，调用方再包一层std::replace(out.begin(), out.end(), '+', ' ')即可。
最易被忽略的一点：这个函数返回的是字节序列，不是自动转码后的Unicode字符串——如果输入是UTF-8编码的URL（绝大多数现代Web场景），解码后仍是合法UTF-8，但C++标准库不验证其有效性；若业务需确保UTF-8合法性，得额外加校验逻辑。
