报错原因是输入字符串含非法字节序列，应先用 mb_detect_encoding($str, ['UTF-8','GBK','GB2312'], true) 检测真实编码，再用 mb_convert_encoding 安全转换；若必须用 iconv，需加 //IGNORE 后缀忽略非法字符。
iconv() 报 “Detected an illegal character” 怎么办
直接原因是输入字符串里混了 iconv() 无法识别的字节序列，比如 UTF-8 中的非法多字节组合（如截断的 emoji、损坏的 Base64 解码结果），或本身不是 UTF-8 编码却硬传了 "UTF-8" 当源编码。
别急着改参数，先确认真实编码：
- 用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'GB2312'], true)检测，true开启 strict 模式减少误判 - 更可靠的方式是查来源：数据库字段用的是什么 collation？前端 POST 过来时 header 里有没有
charset=utf-8？文件上传的原始名是否被浏览器自动编码过（如%E4%B8%AD%E6%96%87）？ - 临时加一行
var_dump(bin2hex($str));看前几个字节，UTF-8 中文通常是e4b8ad起头，若出现3f3f（即??）说明之前已被错误转码过一次
检测后按实际编码转，别硬写 "UTF-8"：
$encoding = mb_detect_encoding($str, ['UTF-8', 'GBK', 'GB2312'], true) ?: 'UTF-8'; $str = mb_convert_encoding($str, 'GBK', $encoding); // 比 iconv 更宽容
ThinkPHP 里文件名/导出名中文乱码还报错
典型场景：用 $file->getInfo()['name'] 拿到上传文件名，直接 iconv('utf-8', 'gb2312', $name) 就崩——因为浏览器传来的原始名可能已经是 GBK 编码（尤其 Windows + Chrome），你再当 UTF-8 转就非法。
立即学习“PHP免费学习笔记（深入）”；
正确做法是「不猜，只还原」：
- 上传时原始名一般经过 URL 编码，先
urldecode()，再用mb_convert_encoding($name, 'UTF-8', 'auto')统一转成 UTF-8 - 导出 CSV/Excel 文件名需要给
Content-Disposition头，Windows 客户端认 GBK，但必须确保输入是合法 GBK 字节：iconv('UTF-8', 'GBK//IGNORE', $filename)，//IGNORE很关键，否则一个非法字节整串报废 - TP6 中如果用
Response::create()->header()设置头，注意不要在 header 前有任何输出（包括空格、BOM），否则header()失效，乱码会叠加
为什么 mb_convert_encoding 比 iconv 更稳
iconv() 是 C 层实现，对非法字节零容忍；mb_convert_encoding() 是 PHP 扩展层封装，内部做了更多容错，比如自动跳过不可转换字符、支持 auto 编码探测、对截断 UTF-8 的修复更友好。
实战中优先选 mb_convert_encoding()，除非明确要 //TRANSLIT 这种音译替换（如把 “é” → “e”）：
// 安全兜底写法 $str = mb_convert_encoding($str, 'GBK', 'UTF-8, GBK, GB2312'); // 三个源编码用逗号分隔，mb_convert_encoding 会逐个试，第一个能解析成功的就用
注意：mbstring 扩展必须启用（php -m | grep mbstring 确认），且 mb_internal_encoding() 最好设为 UTF-8 避免隐式干扰。
TP3.2 / TP6 中数据库查询结果中文变问号或乱码
不是 PHP 转码问题，是连接层没对齐。TP3.2 默认 MySQL 连接用 SET NAMES utf8，但如果你的表字段是 gbk 或 utf8mb4，这句就失效。
检查三处：
- 数据库连接配置里加
'charset' => 'utf8mb4'（TP6）或手动在Db.class.php的connect()方法里执行SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci - 确认表结构：用
SHOW CREATE TABLE xxx看字段的COLLATE，不是utf8mb4_0900_ai_ci就容易出问题 - TP3.2 中若用 MSSQL，驱动默认走 GB2312，必须在查询后手动用
iconv('gb2312', 'utf-8', $value)转，但更推荐改 SQLSRV 连接选项，加'CharacterSet' => 'UTF-8'
真正麻烦的是混合环境：前端 UTF-8、数据库 GBK、导出要 GBK、日志又要 UTF-8 —— 这时候别全局转，按用途分段处理，每个输出点单独做编码适配。
