URL编码不能直接用std::hex或std::tostring，因为它需对UTF-8字节流中非unreserved字符（A-Z a-z 0-9 - . ~）逐字节转%XX，而std::hex会错误处理多字节UTF-8、忽略上下文保留符且不校验编码合法性。
URL编码为什么不能直接用 std::hex 或 std::to_string
因为 URL 编码（也叫 percent-encoding）不是简单转十六进制，而是对**非安全字符**（如空格、中文、斜杠、问号等）逐字节替换成 %XX 形式，且必须基于 UTF-8 字节序列。直接对 std::string 里的每个 char 做 std::hex 会错乱处理多字节 UTF-8 字符（比如一个汉字变成三个独立的 %E4%BD%A0，但若你误按单字节循环处理，可能截断中间字节），还会漏掉保留字符（如 /、? 在路径或查询参数中本就不该编码，但某些场景又必须编码——取决于上下文）。
所以核心原则是：先确保输入是 UTF-8 编码的 std::string，再对每个字节判断是否属于 unreserved 字符集（A-Z a-z 0-9 - _ . ~），其余全部编码。
手写轻量级 URL 编码函数（C++11+，无依赖）
以下函数适用于 query 参数值、form-data 值等需严格编码的场景，不处理空格转 +（那是 application/x-www-form-urlencoded 的规则，不是通用 URL 编码）：
std::string url_encode(const std::string& s) {
std::string result;
result.reserve(s.size() * 3); // 最坏情况：每个字节变 %XX
for (unsigned char c : s) {
if (isalnum(c) || c == '-' || c == '_' || c == '.' || c == '~') {
result += c;
} else {
result += '%';
result += "0123456789ABCDEF"[c / 16];
result += "0123456789ABCDEF"[c % 16];
}
}
return result;
}- 注意：这里用
unsigned char遍历，避免char为负时导致数组越界（如c % 16对负数行为未定义） - 保留字符列表严格按 RFC 3986 定义，不包含
/、?、=等——这些在 query string 中属于分隔符，不应出现在值里被编码；若你传入的是完整 URL 路径片段，需额外逻辑区分上下文 - 不处理 Unicode 字符串（
std::u16string或std::u32string），务必先用 UTF-8 编码转换（例如用std::wstring_convert<:codecvt_utf8>>，但注意该类在 C++17 已弃用；更稳的是用iconv或utf8cpp库）
常见错误：中文字符串传入后编码结果乱码
典型现象是输入 "你好"，输出一堆类似 %FF%FE%xx%xx 的内容，或者长度异常短。这几乎一定是源字符串不是 UTF-8 编码：
立即学习“C++免费学习笔记（深入）”；
- Windows 控制台默认是 GBK/GB2312，
std::string s = "你好";实际存的是 GBK 字节，直接编码就错 - Qt 中
QString::toStdString()默认返回 UTF-8，但若你调用了.toLocal8Bit()就变成本地编码 - C++20 的
std::format不支持直接格式化 UTF-8 字符串为 URL 编码，仍需先确认字节流正确
验证方法：打印原始字符串的十六进制字节，"你好" 的合法 UTF-8 是 E4 BD A0 E5 A5 BD（共 6 字节），如果不是这个，就得先转码。
要不要用 Boost.URL 或 cpp-httplib 内置编码？
Boost.URL（v1.83+）提供 boost::urls::encode，但它是面向 URI 组件的，会自动区分 scheme、host、path、query 各部分，并只对对应位置的非法字符编码，不建议直接用于 raw string 编码；cpp-httplib 的 detail::encode_url 是私有函数，且未导出，也不稳定。
结论：除非你已在项目中重度依赖 Boost.URL 并操作完整 URI 对象，否则手写上面那个函数更可控、无依赖、易调试。真正复杂的需求（如自动识别并跳过 path 中的 /、保留 query 中的 = 和 &）应交由专门的 URI 解析库处理，而不是在编码函数里加 if 分支。
最易被忽略的一点：URL 编码不是“一次编码保终身”。如果你对已编码过的字符串再次编码，就会出现 %2520（即 %20 被二次编码），这种双重编码问题在线上接口调试中极难排查。
