ThinkPHP接收get参数字符转换如何处理-php教程-PHP中文网

thinkphp 6 默认自动 url 解码 $_get 参数，$request->get('name') 或 input('name') 返回的是已解码值，无需也不应手动 urldecode()，否则会导致二次解码乱码；原始未解码值需从 $_server['query_string'] 中解析。

thinkphp接收get参数字符转换如何处理

ThinkPHP 6 默认会自动 URL 解码 `$_GET` 参数

TP6 启动时通过 think\Request 类对原始 $_GET 做了一层封装，默认已调用 urldecode()，所以你拿到的 $request->get('name') 或 input('name') 通常是解码后的中文或特殊字符。不需要手动再 urldecode()，否则可能造成二次解码（比如把 %E4%BD%A0 变成乱码）。

常见错误现象：
• 手动对 input('q') 再套一层 urldecode()，结果中文变问号或
• 在 Nginx + PHP-FPM 环境下，请求中带 %2B（+ 号），手动解码后变成空格，而原生 $_GET 里它就是 +，TP6 封装后默认把它转为空格——这是符合 CGI 规范的，但业务若依赖原始 +，就得换方式取值

优先用 $request->param('key')（兼容 GET/POST/Route）而非直接读 $_GET
如需原始未解码值，可从 $_SERVER['QUERY_STRING'] 中自行解析，或用 parse_str(rawurldecode($_SERVER['QUERY_STRING']), $raw)
注意：TP6 的 input() 和 param() 都走过滤逻辑，若开启 default_filter（如 htmlspecialchars），会进一步转义，需确认配置项 app.default_filter

ThinkPHP 5.1 的 `input()` 不自动解码，但 `I()` 会

TP5.1 是个分水岭：原生 input('name') 直接返回 $_GET['name'] 值，没做 urldecode()；而旧版助手函数 I('get.name') 内部调用了 urldecode()。这容易导致同一参数在不同写法下行为不一致。

使用场景：
• 你维护一个 TP5.1 项目，接口被其他系统用 encodeURIComponent 编码传参，用 input('q') 拿到的是 %E4%BD%A0%E5%A5%BD，不是“你好”
• 但用 I('get.q') 就能直接拿到解码后内容

统一用 I('get.key') 或 input('key', '', 'urldecode') 显式解码
避免混用 $_GET['key'] 和 input()，因为前者是原始值，后者默认不过滤也不解码
TP5.1 中 input('key', '', 'htmlspecialchars') 的第三个参数是过滤函数，支持传字符串或回调，'urldecode' 是合法值

URL 中的 `+`、空格、斜杠等特殊字符处理差异

浏览器地址栏中空格常被编码为 +，但标准 URL 编码应为 %20；而 /、?、= 这类字符若未被编码，会导致路由或参数截断。TP 对这些的容忍度取决于 Web 服务器和 PHP 配置，不是框架能完全兜底的。

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

常见错误现象：
• 请求 /search?q=a+b+c，TP 认为 q = "a b c"（+ 被当空格）
• 请求 /search?q=a%2Bb%2Bc，TP 正确识别为 q = "a+b+c"
• 请求 /user/123/name/张三，若 name 值含 / 且未编码，路由匹配失败

前端必须用 encodeURIComponent() 编码每个参数值，不要拼接 raw URL
后端不要依赖框架“自动修复”，比如把 + 当空格是 CGI 协议行为，非 TP 特性
若必须接收含 / 的参数，改用 POST 或 base64 编码传参，避免路由层解析失败

调试时怎么看实际收到的原始 GET 数据

别只信 var_dump(input('q'))，它已经过框架封装。要看最原始输入，得绕过 Request 实例：

var_dump($_GET); // 原始 PHP 解析结果（已 urldecode，但受 php.ini 中 arg_separator.input 影响）
var_dump($_SERVER['QUERY_STRING']); // 完整未解析字符串，含所有原始 % 编码
var_dump(urldecode($_SERVER['QUERY_STRING'])); // 模拟 TP6 行为

尤其在 Nginx 配置了 merge_slashes off 或使用了自定义重写规则时，$_SERVER['QUERY_STRING'] 可能被意外截断或污染，这时候框架层看到的参数就不可靠了。

真正复杂的地方不在框架怎么解码，而在前端发什么、Web 服务器怎么转发、PHP 怎么解析这三层之间是否对齐。一个 + 字符，可能在 Chrome 地址栏里显示正常，到 Nginx access_log 里变成空格，再到 PHP $_GET 里消失，最后在 TP 里根本收不到——这种链路问题，光看框架文档解决不了。