URL编码不能直接用std::hex拼接，因为它需按RFC 3986规范对非unreserved字符（字母、数字、-、_、.、~）逐字节%XX转义，空格处理为+或%20，且必须正确处理UTF-8多字节序列。
URL编码为什么不能直接用std::hex拼接
因为URL编码不是简单把字节转成十六进制字符串。它要求：只对非unreserved字符（即字母、数字、-、_、.、~）以外的字节做%XX转义；空格必须变成+（表单提交场景）或%20（通用URI场景）；多字节UTF-8字符要按字节逐个编码，不能按wchar_t或char32_t处理。
常见错误是拿std::stringstream + std::hex遍历std::string每个char，结果把ASCII空格' '（0x20）编成%20，却漏掉中文字符的多个UTF-8字节（如你是E4 BD A0三字节），导致解码失败。
- 标准URI编码规范见RFC 3986，
unreserved字符列表必须硬编码判断，不能靠isalnum()——它不认~和- - 若输入含BOM或混合编码（如GBK乱码），编码结果不可逆；务必确保输入是合法UTF-8
-
%本身必须编码为%25，否则解码会误拆
手写url_encode函数的关键逻辑
核心是遍历std::string每个unsigned char，查表判断是否需转义。推荐用静态bool数组（256项）预存可直通字符，比每次调用std::isalnum快且确定。
std::string url_encode(const std::string& s) {
static const bool unreserved[256] = {0};
// 初始化：a-z, A-Z, 0-9, '-', '_', '.', '~'
for (char c = 'a'; c <= 'z'; ++c) unreserved[static_cast<unsigned char>(c)] = true;
for (char c = 'A'; c <= 'Z'; ++c) unreserved[static_cast<unsigned char>(c)] = true;
for (char c = '0'; c <= '9'; ++c) unreserved[static_cast<unsigned char>(c)] = true;
unreserved['-'] = unreserved['_'] = unreserved['.'] = unreserved['~'] = true;
<pre class='brush:php;toolbar:false;'>std::string out;
out.reserve(s.size() * 3); // 最坏情况全编码，每个字节变3字符
for (unsigned char c : s) {
if (unreserved[c]) {
out += c;
} else if (c == ' ') {
out += '+'; // 表单兼容模式；若要RFC 3986严格模式，此处用"%20"
} else {
out += '%';
out += "0123456789ABCDEF"[c / 16];
out += "0123456789ABCDEF"[c % 16];
}
}
return out;}
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 注意强制转换
static_cast<unsigned char>(c)：避免char为负时数组越界 -
out.reserve()减少内存重分配，尤其处理长字符串时明显 - 若需区分表单（
application/x-www-form-urlencoded）与通用URI，把空格分支拆成两个函数，或加bool space_as_plus = true参数
url_decode必须处理%XX和+并校验
解码时容易忽略两点：一是%后必须跟两个十六进制字符，否则是非法输入；二是+只在表单上下文中等价于空格，通用URI中+就是字面量+。
典型崩溃场景："%G1"中的G不是十六进制字符，直接std::stoi(..., 0, 16)会抛异常；"%FF"超出unsigned char范围但未截断，导致后续字节错位。
- 逐字符扫描，遇到
'%'就检查后两位是否为0-9或A-F/a-f，用std::tolower统一处理再查表 - 用
static_cast<char>(value & 0xFF)确保结果落在char范围内 - 若输入含
%但不足两位，或十六进制值无效，建议返回空字符串或抛std::invalid_argument，不要静默跳过
第三方库选型：cpp-httplib vs. ICU vs. 手写
轻量项目直接手写更可控；若已依赖cpp-httplib，它提供httplib::detail::encode_url和httplib::detail::decode_url，但属内部接口，头文件未暴露，不建议直接调用。
ICU库功能完备（支持国际化、百分号编码、punycode等），但体积大、编译慢，仅当需要处理UTF-16或复杂国际化场景时才值得引入。
- 手写方案满足95%的HTTP query string和path encoding需求，且无额外依赖
- 注意C++20的
<charconv>不适用此场景——它用于数值转换，无法处理十六进制字符映射 - 若需线程安全，确保
unreserved查找表是static constexpr或初始化完成的static const，避免首次调用时的竞态
真正麻烦的是边界：比如输入含\0，std::string构造时会被截断；或者解码后产生非法UTF-8序列（如%EF%BB缺一位），这些得靠上层业务决定是丢弃、替换还是报错。
