ThinkPHP字符乱码如何转换正确编码格式-php教程-PHP中文网

改config.php的charset无效，因其仅控制html响应头，不影响数据库连接；真正起效的是database.php中charset=utf8mb4、dsn写死charset=utf8mb4、mysql服务端character_set_server=utf8mb4，并需手动执行set names utf8mb4。

thinkphp字符乱码如何转换正确编码格式

ThinkPHP字符乱码不是单一环节问题，而是文件、HTTP头、数据库、模板四者编码不一致导致的叠加故障。直接改 config.php 里的 'charset' => 'utf-8' 几乎没用。

为什么改 `config.php` 的 `charset` 不起作用

这个配置项只影响 ThinkPHP 自动渲染 HTML 模板时的 Content-Type 响应头（比如 fetch() 输出页面），它完全不控制数据库连接、SQL 执行、PDO 初始化或文件读取的编码。很多开发者卡在这里反复修改却无效，就是因为误以为它是“全局编码开关”。

'charset' => 'utf-8' 在 TP5/6 中对数据库连接无任何影响；真正起作用的是 database.php 里的 'charset'
即使你写了 'charset' => 'utf8mb4'，如果 MySQL 服务端 character_set_server 是 latin1 或 utf8，连接后仍不会自动执行 SET NAMES utf8mb4
TP6 默认不触发 SET NAMES，必须显式配置或手动执行，否则 PDO 会沿用服务器默认字符集

`database.php` 必须设为 `utf8mb4`，且不能写 `utf8`

MySQL 的 utf8 是历史包袱，实际是 utf8mb3，不支持 emoji 和部分生僻中文（如「?」「?」）。一旦存入这类字符，会被静默截断或变问号，且无法通过后续转换恢复。

btpanel phpsite 宝塔面板PHP网站

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

下载

在 config/database.php 中，把 'charset' => 'utf8' 改成 'charset' => 'utf8mb4'（注意拼写，不能少 mb4）
DSN 字符串里也得带 ;charset=utf8mb4，例如：mysql:host=127.0.0.1;dbname=test;charset=utf8mb4
确认 MySQL 服务端已启用：SHOW VARIABLES LIKE 'character_set_server'; 返回值必须是 utf8mb4，否则改配置无效
连接建立后，检查日志或用 Db::connect()->getPdo()->getAttribute(PDO::ATTR_CLIENT_VERSION) 验证是否真用了 utf8mb4

文件 BOM、HTML meta、`header()` 必须三者统一

乱码常出现在调试输出（如 dump()）、错误页（halt()）、或纯 PHP 脚本直出内容上，根源是 PHP 文件本身含 BOM 或未发送正确响应头。

用 VS Code 或 Notepad++ 打开所有 PHP 入口文件（public/index.php、app/common.php 等），保存为 UTF-8 无 BOM 格式（不是“UTF-8 with BOM”）
入口文件顶部加：header('Content-Type: text/html; charset=utf-8'); —— 这能覆盖 IIS/Apache 的默认响应头，尤其对 dump() 和 halt() 生效
所有 HTML 模板头部必须有：<meta charset="utf-8">；若用 <meta http-equiv="Content-Type">，确保属性值与 header 一致
不要依赖框架自动输出 meta：TP 的模板引擎不会帮你补 meta，fetch() 只输出内容，不注入 head

GET/POST 中文参数乱码要单独处理

IIS 或某些 Nginx 配置下，URL 中的中文参数（如 ?name=张三）会被服务器按 GBK 解码再传给 PHP，而 PHP 默认以 UTF-8 处理，结果就是乱码。这不是 ThinkPHP 的 bug，是 Web 服务器层的编码错位。

最可靠方案：前端传参前用 urlencode() 编码，后端接收后用 urldecode() 解码，例如：$name = urldecode(input('get.name'));
若必须兼容旧链接，可在中间件或 app/common.php 开头统一转码：$_GET = array_map(function($v) { return is_string($v) ? iconv('gbk', 'utf-8//IGNORE', $v) : $v; }, $_GET);
避免用 mb_convert_encoding($_GET['name'], 'UTF-8', 'auto')，auto 不可靠，容易误判
POST 表单乱码同理，确保表单 <form accept-charset="utf-8"></form>，且页面本身是 UTF-8 编码

真正棘手的不是某处漏配，而是多个环节都“看起来正常”——文件是 UTF-8、数据库设了 utf8mb4、meta 也写了，但只要 MySQL 服务端没切到 utf8mb4，或 PHP 文件带了 BOM，或 URL 参数未经 urlencode，乱码就会在某个具体场景突然冒出来。排查时得逐层验证，不能只看配置项有没有写。