ThinkPHP不自动识别GB2312，需在数据入库前用mb_convert_encoding或iconv手动转UTF-8；数据库charset设置仅影响通信解释，不转换PHP变量内容；文件读取、表单提交等所有GB2312入口均须单独判断并转码。
ThinkPHP 默认不支持 GB2312 编码的自动识别和转换，直接用 iconv 或 mb_convert_encoding 处理原始字符串即可，无需框架层特殊干预——但必须在数据进入模型/数据库前完成转码，否则存入的是乱码。
GB2312 字符串进库前手动转 UTF-8
常见于表单提交含中文旧系统、Excel 导入、或对接老接口返回 GB2312 编码的文本。ThinkPHP 不会自动检测请求编码，$_POST 或 $request->post() 拿到的就是原始字节流。
- 先判断是否为 GB2312 编码：
mb_detect_encoding($str, ['GB2312', 'UTF-8'], true)可能误判，更稳妥是用mb_check_encoding($str, 'GB2312')配合业务上下文（如明确知道来源是 GB2312） - 确认后转码：
mb_convert_encoding($str, 'UTF-8', 'GB2312')或iconv('GB2312', 'UTF-8//IGNORE', $str)（//IGNORE可跳过非法字符） - 注意：若字符串里混有 UTF-8 和 GB2312（极少见），需分段检测，
mb_convert_encoding会静默失败，建议统一用iconv并检查返回值是否为false
数据库连接层不解决编码问题
很多人以为把 database.php 中 'charset' => 'utf8mb4' 设好，就能自动转码——这是误解。MySQL 的 charset 只控制客户端与服务端通信时的解释方式，不负责对 PHP 变量内容做编码转换。
- 如果插入前没转，
INSERT INTO t VALUES ('张三')实际执行的是 GB2312 字节写入 UTF-8 表，结果就是乱码（如 “寮熺”） -
SET NAMES gb2312在 ThinkPHP 连接配置中无效，也不推荐；它只影响 MySQL 解释后续 SQL 字符串，不能修复 PHP 变量本身的编码 - 验证方法：在插入前
dump(bin2hex($str))，GB2312 的“张”是c5c5，UTF-8 是e5bca0；入库后查 hex 值可快速定位问题阶段
文件读取（如 CSV、TXT）时的 GB2312 转码
使用 file_get_contents 读取 GB2312 文件，得到的是原始字节，直接 json_encode 或传给视图会出错。
立即学习“PHP免费学习笔记（深入）”；
- 读取后立即转码：
$content = mb_convert_encoding(file_get_contents($path), 'UTF-8', 'GB2312') - 若文件无 BOM 且含乱码，可能是实际为 GBK（兼容 GB2312），此时改用
'GBK'作源编码更稳妥 - 用
fopen+stream_filter_append也可实现边读边转，但小文件没必要，反而增加复杂度
真正容易被忽略的是「转码时机」：不是在控制器里转一次就万事大吉，而是所有可能携带 GB2312 数据的入口（如 $request->file() 读取的 CSV、curl 返回的响应体、第三方 SDK 回调参数）都得单独判断+转码。ThinkPHP 不提供全局编码钩子，这事只能自己守好边界。
