必须编码的字符是除A-Z、a-z、0-9及-_.~以外的所有字符；空格须编码为%20，UTF-8字节流按字节处理，不可用std::isalnum或重复编码，推荐使用Boost.URL等成熟库。
URL 编码（Percent-encoding）在 C++ 中没有标准库函数直接支持，必须手动实现或借助第三方库；标准 std::string 不提供 encodeURIComponent 类能力，所有非字母数字字符（除 -、_、.、~ 外）都需转为 %XX 形式。
哪些字符必须被编码？
根据 RFC 3986，URL 中仅以下字符被视为“未保留”（unreserved），可不编码：
- 大写/小写字母：
A-Z、a-z - 数字：
0-9 - 特殊符号：
-、_、.、~
其余所有字符（包括空格、中文、/、?、=、&、#、控制字符等）都应被编码。注意： （空格）必须转为 %20，不是 + —— 后者是 application/x-www-form-urlencoded 的规则，不适用于通用 URL 编码。
手写 URL 编码函数（C++11+）
核心逻辑：遍历每个字节，判断是否属于 unreserved 字符；若否，则用 % + 两位十六进制大写表示该字节值。注意：此实现针对 UTF-8 编码的字符串（现代 C++ 项目默认假设），不做 Unicode 码点拆分，直接按字节处理。
立即学习“C++免费学习笔记（深入）”；
std::string url_encode(const std::string& s) {
std::string result;
result.reserve(s.size() * 3); // 最坏情况：每个字节变成 %XX
for (unsigned char c : s) {
if ((c >= 'A' && c <= 'Z') ||
(c >= 'a' && c <= 'z') ||
(c >= '0' && c <= '9') ||
c == '-' || c == '_' || c == '.' || c == '~') {
result += c;
} else {
result += '%';
result += "0123456789ABCDEF"[c >> 4];
result += "0123456789ABCDEF"[c & 15];
}
}
return result;
}使用示例：
std::string raw = "hello 世界?key=value&sub=path/to"; std::string encoded = url_encode(raw); // → "hello%20%E4%B8%96%E7%95%8C?key=value&sub=path/to"
⚠️ 注意：%E4%B8%96%E7%95%8C 是 UTF-8 字节序列的编码结果，不是 UTF-16 或其他编码。若输入不是合法 UTF-8（如 GBK 字符串混入），结果将错误且不可逆。
常见错误与兼容性陷阱
实际项目中容易踩的坑：
-
std::isalnum(c)不能直接用：它依赖当前 locale，可能把非 ASCII 字母（如 é、α）判为 alnum，导致漏编码 - 误用
std::hex+std::stringstream：易引入前导空格、大小写混乱、性能差，且难以控制两位固定宽度 - 对已编码字符串重复编码：例如
%20再次编码成%2520，造成双编码污染 - 混淆 URL 编码与 form 表单编码：后者把空格转
+，且不编码*、'等字符；二者不可互换 - 忽略路径分隔符语义：如
/在路径段中通常不编码（它是分隔符），但在查询参数值中必须编码（如?q=a/b应为?q=a%2Fb）
更安全的替代方案：用成熟库
若项目允许引入依赖，推荐：
-
cpp-httplib：轻量，含
detail::encode_url（内部函数，需复制或封装） -
Boost.URL（v1.83+）：提供
boost::urls::encode，支持按 component（scheme、path、query 等）精细编码，自动处理 UTF-8 边界 -
cpr 或 libcurl：其 C 接口有
curl_easy_escape，但已标记为 deprecated；新代码应避免
Boost 示例（需链接 boost_url）：
boost::urls::result<boost::urls::url> u = boost::urls::parse_uri("https://ex.com/q?k=v w");
auto encoded = boost::urls::encode(u.value().params().begin()->value, boost::urls::pct_encode_opts{}); // → "v%20w"真正难的不是写一个能跑的编码函数，而是确保它在所有边界场景下——比如混合中日韩文字、emoji、NUL 字节、代理对（surrogate pairs）缺失、locale 切换时——行为一致且符合 RFC。多数业务代码其实只需要对 query 参数值做编码，此时明确限定输入范围 + 单字节处理，比追求“全 Unicode 支持”更可靠。
