必须用 rawurldecode() 而不是 urldecode() 的核心判断点是数据来源是否经 rawurlencode() 编码或需保留 + 字面意义，如 URL 路径中的 %2B、Location 头、JWT 拼接场景；$_GET 已自动解码，不可重复调用。
rawurldecode() 用来还原 RFC 3986 标准下编码的 URL 字符串，它不处理 + 号——这点和 urldecode() 有本质区别。如果你在解码路径、API 路径参数或 header 中的 Location 值，用错函数就会把 + 错当成空格，导致文件名、ID 或特殊符号出错。
什么时候必须用 rawurldecode() 而不是 urldecode()
核心判断点：数据来源是否经过 rawurlencode() 编码，或者是否明确要求保留 + 的字面意义。
- URL 路径部分（path）里的
%2B表示字面加号，比如/api/v1/users/john%2Bdoe，解码后应为john+doe，不是john doe - HTTP
Location响应头中重定向的目标 URL，通常由服务端用rawurlencode()构造，直接用urldecode()会把其中合法的+吃掉 - JWT 的 payload 或签名部分若含 URL-safe Base64（虽不等价于
rawurlencode，但同属 RFC 3986 语境），后续拼接进 URL 时也倾向搭配rawurldecode() -
$_GET和$_REQUEST已被 PHP 自动解码过，对它们再调用rawurldecode()是冗余且危险的
rawurldecode() 对中文和 UTF-8 的表现
它本身不关心字符编码，只做字节级替换：%E4%B8%AD → 中，%C3%BC → ü。但前提是输入字符串确实是 UTF-8 编码的百分号序列。
- 如果原始字符串是 GBK 编码却误用 UTF-8 解码（比如浏览器发来 GBK 的
%D6%D0），rawurldecode()仍会按 UTF-8 规则尝试解，结果是乱码 - 不要指望它自动修复编码问题；乱码根源在传输链路（如 HTML 表单没设
accept-charset="UTF-8"），而非解码函数 - Latin-1 或 ISO-8859-1 场景下，
%A3这类单字节编码能正常还原，但 PHP 8.2+ 默认内部字符串为 UTF-8，建议统一前端→后端全链路用 UTF-8
常见错误：多重编码 + 混用函数
用户上传文件名含空格和中文，前端用 encodeURIComponent()（等效于 rawurlencode()），后端却用 urldecode()，结果 %2B 变成空格、%20 又变一次空格——最终 ID 错位或 404。
立即学习“PHP免费学习笔记（深入）”；
- 检查原始字符串是否已被解码过：打印
bin2hex($str)，看是否还存在25（即%）字节；若已无%，再调用就是无效操作 - 遇到疑似双重编码（如
%25E4%25BD%25A0），可循环解码：while (preg_match('/%[0-9A-Fa-f]{2}/', $s)) { $s = rawurldecode($s); }，但更应从前端源头杜绝重复 encode - 不要用
rawurldecode()处理表单application/x-www-form-urlencoded数据体——那是urldecode()的职责，因为该格式规范明确把+定义为空格
真正容易被忽略的是：PHP 的 parse_url() 和 parse_str() 都不负责解码，它们返回的 path、query 等字段仍是原始编码态。你得自己决定在哪一层、用哪个函数解——路径用 rawurldecode()，查询参数值用 urldecode()，这个边界一旦模糊，调试成本就翻倍。
