URL解码函数不能直接用std::stoi解析十六进制字符，因为%20中的“20”是十六进制，而std::stoi默认按十进制解析，需显式指定进制为16并跳过%前缀，且须检查i+2是否越界。
URL解码函数为什么不能直接用 std::stoi 解析十六进制字符
因为 %20 这类转义序列里的 20 是十六进制，但 std::stoi 默认按十进制解析，直接传会导致结果错乱（比如把 %20 当成十进制 20，而非十六进制 0x20 = 32）。必须显式指定进制为 16，并跳过 % 前缀。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 遍历字符串，遇到
%后连续两个字符才尝试解码，不足两位直接保留原样 - 用
std::stoi(s.substr(i+1, 2), nullptr, 16)提取并转换，注意边界检查（i+2 ） - 转换后需确保结果在合法 ASCII 范围（0–127），否则可能属于非法 URL 编码，可选择丢弃或保留原始
%xx
空格被编码为 + 还是 %20？解码时怎么统一处理
这是表单提交（application/x-www-form-urlencoded）和通用 URL 编码（RFC 3986）的差异点：前者允许 + 表示空格，后者只认 %20。标准 URL 解码应同时支持两者，但顺序很重要。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 先将所有
+替换为%20，再统一走%xx解码流程 —— 避免+被误当作字面量 - 不要反过来：先解
%xx再替换+，否则像%2B（即+字符本身）会被错误覆盖 - 若业务明确只处理 RFC 3986 标准（如 REST API 路径），可跳过
+处理，仅解%xx
如何安全处理非 ASCII 字符（如中文）的 URL 解码
URL 编码本身不定义字符集，实际中 UTF-8 是事实标准。一个中文字符（如 你）会编码为三个 %xx 单元（%E4%BD%A0），解码时必须按字节组合还原，不能逐个字节转 Unicode 码点。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 解码后得到的是 raw bytes，不是
std::string意义上的“字符” —— 它只是 UTF-8 编码的字节流 - 不要用
static_cast<char></char>强转高字节值（如 0xE4），那会截断或触发未定义行为 - 若需转为
std::u32string或验证合法性，应使用专用 UTF-8 解码库（如utf8cpp）或 C++20 的std::from_chars+ 手动状态机 - 常见坑：把解码结果直接喂给
std::cout，在非 UTF-8 终端显示乱码 —— 这不是解码错，是终端环境问题
为什么用 std::string::reserve() 对性能有明显影响
URL 解码后字符串长度通常比编码前短（%20 → 1 字节），但最坏情况（无编码）长度不变。频繁 push_back 触发多次内存重分配，尤其对长 URL（如带 base64 参数）很敏感。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 预估最大长度：原始长度（假设全不编码）；最小长度：去掉所有
%xx后剩余字节数 - 保守策略：调用
result.reserve(input.length())，避免扩容，也留有余量 - 别用
resize()预设大小再填值 —— 遇到非法%序列时难以安全回退 - 若确定输入 100% 合法且长度已知（如内部协议），可
resize()+ 索引赋值，更快但丧失容错性
真正麻烦的不是解码逻辑本身，而是判断哪些 % 是真的转义、哪些是路径里正常的百分号 —— 比如文件名 report%final.pdf 里的 % 并不表示编码。没有上下文，就无法 100% 正确还原。
