rfc3986规定必须编码除a-z、a-z、0-9、-、.、_、~外的所有字节，包括空格（%20）、保留字符（/、:、@等）、中文及emoji等utf-8多字节字符，且需按字节逐个编码。
URL编码必须转义哪些字符
RFC3986 明确规定，只有 unreserved 字符（A-Z、a-z、0-9、-、.、_、~）和 sub-delimiters（!、$、&、'、(、)、*、+、,、;、=）在特定上下文中可不转义——但实际做 query 参数时，&、=、?、# 等分隔符必须保留原义，不能编码；而空格、中文、/、:、@、[、] 等一律要编码。
也就是说：不是“只编码特殊字符”，而是“只保留 unreserved + 少量 sub-delimiters，其余全 encode”。常见错误是漏掉 ~ 或误把 !、' 编码（它们属于 sub-delimiters，query 中通常不需编码）。
std::string 手动实现 encode_uri_component
标准库没提供现成函数，得自己写。核心逻辑：遍历每个字节，判断是否属于 RFC3986 的 unreserved 集合；如果不是，就用 %XX 格式转义（注意用大写十六进制）。
-
%本身必须编码为%25—— 否则会破坏编码结构 - 多字节 UTF-8 字符（如中文）按字节处理，每个字节单独编码，不要先转宽字符再处理（易出错且非必要）
- 空格应编码为
%20，不是+（那是 application/x-www-form-urlencoded 的规则，不符合 RFC3986）
示例片段：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::string url_encode(const std::string& s) {
std::string out;
for (char c : s) {
if ((c >= 'A' && c = 'a' && c = '0' && c > 4) & 0xF];
out += "0123456789ABCDEF"[(unsigned char)c & 0xF];
}
}
return out;
}
注意 C++ 字符编码与 locale 无关
URL 编码操作对象是字节序列，不是字符。传入的 std::string 必须已是 UTF-8 编码（这是现代 Web 的事实标准）。如果原始字符串是 GBK、UTF-16 或其他编码，先转换为 UTF-8 再编码——否则中文会变成乱码或部分字节被错误转义。
常见坑：
- 直接用
std::wstring+wctomb或WideCharToMultiByte转换时未指定 UTF-8，结果仍是本地 code page 编码 - 误以为
std::locale能自动处理编码转换——它不能，C++ 标准库不内置 UTF-8 转换 - 用
iconv或std::codecvt_utf8（已弃用）时未检查转换失败，导致截断或崩溃
第三方库推荐：cpp-httplib 和 Boost.URL
如果项目允许依赖，优先用成熟实现：
-
cpp-httplib的httplib::detail::encode_url是轻量、头文件-only、严格遵循 RFC3986 的实现，支持空格→%20，且不含额外依赖 -
Boost.URL（v1.83+）提供boost::urls::encode，支持多种编码模式（query、path、fragment），并能自动处理 UTF-8 边界（比如不拆开 UTF-8 多字节序列），比手写更健壮 - 避免用
curl_easy_escape：它默认用+代替空格，且不保证 RFC3986 兼容性
Boost 示例：
#include <boost>
std::string encoded = boost::urls::encode("hello 世界").to_string();
// → "hello%20%E4%B8%96%E7%95%8C"
</boost>
实际写的时候，最容易被忽略的是：你拿到的原始字符串到底是不是 UTF-8。很多 Windows 程序默认用本地 ANSI 编码读文件或输入，直接喂给 URL 编码函数就会崩。务必确认源头编码，再决定是否需要转换。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
