RFC 3986要求URL百分比转义仅对非unreserved和非上下文允许的sub-delimiters字节编码，且必须按UTF-8字节流操作；unreserved字符（A-Z、a-z、0-9、-、.、_、~）不得编码，sub-delimiters在query值中若作数据需编码。
什么是RFC规范要求的URL百分比转义
RFC 3986定义了URL中哪些字符必须编码、哪些可以保留。关键点是：unreserved字符（A-Z、a-z、0-9、-、.、_、~）**不应编码**；sub-delimiters（如!、$、&、'、(、)、*、+、,、;、=）和gen-delimiters（/、?、#、[、]、@、:）**在URL特定上下文里通常不编码，但若作为数据值出现（比如query参数值），就必须编码**。
很多C++库（如std::urlencode不存在）或第三方实现默认只逃逸空格和<>等HTML字符，或把/也编码——这不符合RFC 3986对路径段（path segment）和查询值（query value）的差异化要求。你得自己控制“哪些字符放行”。
手动实现：用std::ostringstream + 白名单判断
最可控的方式是遍历每个char或unsigned char，查表决定是否编码。注意：输入可能是UTF-8字符串，但RFC百分比编码是对**字节**操作，不是对Unicode码点——所以不要先转UTF-32再编码，直接按UTF-8字节流处理。
- 定义白名单：所有
unreserved字符 + 需要保留的sub-delimiters（例如!$'()*常用于query value中保留） - 对每个字节，若不在白名单中，用
std::hex+std::uppercase格式化为%XX - 务必把
char转成unsigned char再查表，否则高位为1的UTF-8字节（如0xC3）会被解释为负数，导致越界或错误查表 - 示例片段：
std::string url_encode(const std::string& s) { static const std::string unreserved = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_.~"; static const std::string subdelim = "!$'()*"; std::ostringstream oss; for (unsigned char c : s) { if (unreserved.find(c) != std::string::npos || subdelim.find(c) != std::string::npos) { oss << c; } else { oss << '%' << std::hex << std::uppercase << std::setw(2) << std::setfill('0') << (int)c; } } return oss.str(); }
为什么不能用curl_easy_escape或libcurl的编码函数
curl_easy_escape默认对/、?、#等也编码，且不支持细粒度控制保留字符集；它更偏向“安全保守”，而非RFC合规。如果你传入的是完整URL（如https://example.com/path?k=v），它会把/和?都变成%2F、%3F，破坏URL结构。
立即学习“C++免费学习笔记（深入）”；
- 它适合编码单个query value，但需配合
curl_free手动释放内存，容易漏掉 - 返回值是
char*，非std::string，和现代C++惯用法脱节 - 无法指定是否保留
!或'——而RFC明确允许它们在query中不编码
UTF-8边界问题：多字节字符不能拆开编码
UTF-8里一个中文字符占3个字节（如你 → 0xE4 0xBD 0xA0），必须把这三个字节当作整体看待，**不能单独对每个字节做白名单判断**——因为单个字节（如0xE4）永远不在unreserved里，会被错误编码成%E4%BD%A0，这反而是正确的；但如果你误用std::wstring + wchar_t逐字符处理，再转UTF-8，就可能因平台宽字符长度差异（Windows是UTF-16，Linux常是UTF-32）引入转换错误。
- 坚持用
std::string接收原始UTF-8字节流 - 不做任何字符解码（即不调用
std::codecvt_utf8等已弃用设施） - 只要确保输入本身是合法UTF-8（可用
utf8_checker类简单验证），编码结果自然正确
真正容易被忽略的是：你得清楚自己编码的是URL哪一部分——路径段（path）通常保留/，而查询值（query value）中/必须编码。没有上下文感知的通用函数，本质上不存在“完全RFC合规”的黑盒函数；你得根据用途决定白名单。
