mb_convert_encoding 转不了 GBK 的根本原因是未指定源编码，必须显式传入第三个参数如 'GBK'，否则依赖默认编码易导致误判和乱码。
mb_convert_encoding 转不了 GBK？检查第三个参数
很多 PHP 开发者用 mb_convert_encoding 处理中文乱码时发现，从 GBK 转 UTF-8 结果还是乱码，甚至返回空字符串。根本原因常是漏传或错传了源编码标识。
这个函数必须明确告诉 PHP “当前字符串是什么编码”，否则它会按 mb_internal_encoding() 默认值猜，而默认通常是 UTF-8——一旦源码其实是 GBK，就直接误判、截断或静默失败。
- 正确写法：
mb_convert_encoding($str, 'UTF-8', 'GBK') - 错误写法：
mb_convert_encoding($str, 'UTF-8')（缺源编码，依赖内部设置，极不可靠） - 源编码不区分大小写，但推荐用大写标准名：
GBK、GB2312、UTF-8、ISO-8859-1 - 如果不确定源编码，先用
mb_detect_encoding($str, ['UTF-8','GBK','GB2312'], true)猜，但注意：该函数不可靠，仅作辅助，不能用于生产环境自动判断
iconv 函数报 “Illegal character” 错误怎么处理
iconv 比 mb_convert_encoding 更严格，默认遇到无法转换的字符就中止并报 iconv(): Illegal character。这不是 bug，是它的设计逻辑——它不自动跳过或替换非法字节。
解决方法是加 //IGNORE 或 //TRANSLIT 后缀，但二者行为差异很大：
立即学习“PHP免费学习笔记（深入）”；
-
iconv('GBK', 'UTF-8//IGNORE', $str)：直接丢弃无法转换的字节（可能造成文本缺失） -
iconv('GBK', 'UTF-8//TRANSLIT', $str)：尝试用近似字符替代（如把「℃」转成「C」），但对中文基本无效，慎用 - 注意：
//IGNORE必须紧贴目标编码，写成'UTF-8//IGNORE'，不能有空格或分开 - PHP 8.2+ 中
iconv已废弃，新项目优先用mb_convert_encoding；若需兼容老系统，务必加错误抑制符@iconv(...)防止报错中断流程
从数据库读出的中文是乱码，光转 PHP 字符串没用
常见误区：以为只要在 PHP 里用 mb_convert_encoding 把变量转一遍就能解决乱码。实际上，如果 MySQL 连接本身没设对编码，数据在进 PHP 前就已经损坏了。
必须三处同步设置：
- MySQL 连接层：执行
SET NAMES utf8mb4（或对应源库编码，如gbk），PDO 构造时加charset=utf8mb4，mysqli 用set_charset('utf8mb4') - 表与字段：确认
SHOW CREATE TABLE xxx中列定义带CHARACTER SET utf8mb4（不是utf8） - PHP 输出前：确保
header('Content-Type: text/html; charset=utf-8')，且 HTML 中有<meta charset="utf-8"> - 如果数据库存的是
GBK编码内容，连接也要设为gbk，而不是强行在 PHP 层“补救”
file_get_contents 读 GBK 文件后中文变问号？别忘了指定 encoding
file_get_contents 本身不处理编码，它只是原样读取字节流。如果你读的是 GBK 文件，得到的是一串 GBK 字节，此时直接 echo 或参与 UTF-8 页面渲染，必然显示为 或乱码。
关键动作不是“读”，而是“读完立刻转”：
- 先读：
$raw = file_get_contents('data.txt') - 再转：
$utf8 = mb_convert_encoding($raw, 'UTF-8', 'GBK') - 不要试图让
file_get_contents自动识别编码——它没有这个能力 - 如果文件无 BOM 且编码未知，可用
mb_check_encoding($raw, 'GBK')和mb_check_encoding($raw, 'UTF-8')辅助判断，但仍有误判风险 - 写回文件时同理：
file_put_contents('out.txt', mb_convert_encoding($str, 'GBK', 'UTF-8'))
真正麻烦的从来不是调哪个函数，而是搞清每个环节的数据到底以什么编码存在——连接、存储、传输、读取、输出，任一环错配，转换就变成掩耳盗铃。
