如何统一ThinkPHP请求参数编码，避免乱码输入？

本文共计1220个文字，预计阅读时间需要5分钟。

ThinkPHP+6 的 input() 函数直接获取 $_GET 和 $_POST 原始值，不会自动执行 urldecode() 或字符集转换。如果前端传递的是 UTF-8 编码的中文字符串 URL 参数（如 ?name=你好），input('name') 获取到的就是已解码的字符串；但如果某些客户端或网关二次编码（如 %E4%BD%A0%E5%A5%BD），则会出现乱码或问号。

常见错误现象：input('title') 返回 "???" 或空字符串，但 $_GET['title'] 看起来是正常百分号编码；或者 POST 表单提交含中文字段后，input('content') 变成乱码。

• 必须在全局中间件或 Base Controller 的 initialize() 中统一处理，不能只在某个接口里临时 urldecode()
• 优先用 mb_convert_encoding() + urldecode() 组合，别依赖 iconv()（PHP 8.2+ 已废弃）
• 注意：input() 对数组参数（如 input('list/a')）会递归处理，但自定义解码逻辑需手动遍历，否则深层键值仍可能乱码

POST 请求中 JSON Body 的中文乱码不是编码问题，是 Content-Type 没配对

当用 fetch 或 axios 发送 Content-Type: application/json 请求时，ThinkPHP 默认不解析 JSON body，input() 拿不到任何值——除非你显式调用 input('', '', false) 并手动 json_decode(file_get_contents('php://input'), true)。这时候如果 JSON 字符串本身是 UTF-8，但请求头漏了 ; charset=utf-8，某些旧版 Nginx 或代理会按 ISO-8859-1 解析原始流，导致中文变乱码。

• 前端必须确保发送 JSON 时带完整 header：Content-Type: application/json; charset=utf-8
• ThinkPHP 6.1+ 可在 app/middleware.php 中注册一个中间件，在 $request->getContent() 后检查是否为 JSON，再强制以 UTF-8 解析
• 不要在控制器里反复写 json_decode(file_get_contents('php://input'))，容易漏掉 trim() 和空内容判断，导致 null 或解析失败

Request::instance()->param() 和 input() 在编码行为上完全一致

有人以为 Request::instance()->param() 是“更底层”的接口，能绕过编码问题，其实它和 input() 共享同一套参数解析逻辑，底层都走 think\Request::filterValue()，默认不做额外转码。区别只在于：param() 合并 GET/POST/ROUTE，input() 默认只读 POST，加 'get.' 前缀才读 GET——但两者对编码的处理毫无差别。

立即学习“PHP免费学习笔记（深入）”；

• 不要因为换函数名就以为能解决乱码，重点还是看原始输入流是否被正确解码
• 调试时可直接打印 file_get_contents('php://input') 和 $_SERVER['QUERY_STRING']，对比原始字节，比猜 input() 行为更可靠
• 若用了 Swoole 或 RoadRunner，php://input 可能不可读，此时必须依赖 Swoole 的 $request->rawContent() 并确保其编码正确

Apache + mod_php 下的 .htaccess 不影响 PHP 层编码，别白配

有些人在项目根目录加 AddDefaultCharset UTF-8 或 SetEnvIfNoCase 规则，指望靠 Apache 配置解决 ThinkPHP 接收参数的乱码。这是无效的——Apache 的字符集设置只影响响应头和静态文件输出，对 $_GET/$_POST 的原始字节无任何干预。PHP 解析这些超全局变量时，完全由自身扩展（如 php_url_scanner）决定如何 decode，跟 Apache 无关。

• 真正要配的是 PHP 配置：default_charset = "UTF-8"（仅影响 header，默认已设）和 mbstring.http_input = "UTF-8"（PHP 7.4+ 已移除，勿设）
• 如果你用的是 Nginx + PHP-FPM，确认 fastcgi_param 没覆盖 QUERY_STRING 或篡改原始值（某些安全模块会做 URL 过滤）
• 最稳的方式：所有外部输入（URL、表单、API）在进入业务逻辑前，统一用 mb_convert_encoding($str, 'UTF-8', 'auto') 强制归一化，'auto' 能识别 GBK/GB2312/UTF-8，比硬写 'GBK' 更容错

真正麻烦的不是怎么转码，而是同一个参数在不同入口（URL、Form、JSON、CLI）下，原始编码状态完全不同——有的已被 decode 一次，有的被代理多 encode 一层，有的根本没进 $_POST。所以别信“统一配置就能搞定”，得按入口类型分别验、分别转。