PHP解码URL编码字符串应使用urldecode()函数，它将%XX还原为字节、+号还原为空格；但不可对已自动解码的$_GET值重复调用，否则引发双重解码错误，中文乱码主因是字符编码不匹配而非函数本身。
直接用 urldecode() 就行，但别乱用在 $_GET 上
PHP 的 urldecode() 函数本身很简单：传一个字符串进去，它把 %XX 解成字节、把 + 变成空格，然后返回原始内容。但它不是万能解药，尤其不能套在 $_GET 或 $_REQUEST 的值上再解一次——因为 PHP 在接收到请求时，已经自动对这些超全局变量做过一次 urldecode() 了。再解一遍，%20 可能变成空格，%2520（即编码后的 %20）会先解成 %20，再解成空格，结果完全失控。
常见错误现象：
-
$_GET['q'] = 'hello%2Bworld'→ 实际拿到的是hello+world，再urldecode($_GET['q'])得到hello+world（没变），但如果原始是hello%252Bworld，二次解码就变成hello%2Bworld，逻辑错乱 - 中文参数如
name=%E4%BD%A0%E5%A5%BD，$_GET['name']已是你好，再urldecode()可能触发乱码或截断
urldecode() 适合解什么？明确来源的 raw 编码串
它真正该用的场景，是处理你自己编码过、或从非 $_GET 渠道拿到的原始 URL 编码字符串，比如：
- 从数据库读出的存档 URL 参数（之前用
urlencode()存的） - API 返回的 query string 片段，例如
$raw = 'city=%E5%8C%97%E4%BA%AC&age=25' - 手动拼接的跳转链接中截取的 value 部分，如
parse_url($url, PHP_URL_QUERY)拿到后按&和=拆分出来的值
示例：
立即学习“PHP免费学习笔记（深入）”；
$raw_value = 'name%3Dphp%2Btest%21'; echo urldecode($raw_value); // 输出：name=php+test!
注意：这里 %3D 是 = 的编码，%2B 是 + 的编码——urldecode() 正确还原了它们，而不是当成普通字符保留。
遇到中文乱码？问题通常不在 urldecode()，而在编码源头或脚本声明
如果 urldecode() 后中文显示为 或问号，大概率不是函数错了，而是：
- 原始字符串根本不是 UTF-8 编码的（比如 GBK 页面提交，却用 UTF-8 解）
- 浏览器发送时用了不一致的编码，例如某些老客户端对
º发%BA（ISO-8859-1）而标准应是%C2%BA（UTF-8） - PHP 脚本没声明输出编码，
header('Content-Type: text/html; charset=utf-8');缺失
不要指望 urldecode() 自动转码。它只做“字节还原”，不做字符集转换。若确认输入是 UTF-8 编码的 %XX 串，解出来还是乱码，就该检查 mb_internal_encoding() 和页面 meta 声明是否统一为 UTF-8。
想绕过安全校验？小心双重解码陷阱
CTF 或代码审计中常见这种模式：$_GET['id'] = urldecode($_GET['id']); 然后拿去比对。这时攻击者可构造 ?id=%2561dmin：第一次浏览器解码得 %61dmin，PHP 再 urldecode() 一次得 admin。本质是 %25 → %，再 %61 → a。
这种逻辑风险极高，但真实存在。如果你要防御，关键不是禁用 urldecode()，而是：
- 避免对用户输入反复解码
- 比对前统一 normalize，比如用
rawurldecode()+mb_convert_encoding()强制转 UTF-8 - 永远用
===严格比较，且提前校验长度、字符范围等业务约束
最易被忽略的一点：URL 解码发生在 CGI 层和 PHP 运行时两个阶段，中间还夹着 Web 服务器（如 Nginx）的配置。有些服务器默认会对路径部分做一次解码，导致你根本没机会控制——这时候光靠 PHP 函数已不够，得查 location 配置里的 decode 行为。
