iconv转换中文返回空或false的根本原因是遇到无法映射字符时默认中止，需加//IGNORE或//TRANSLIT；目标编码须大写并选GBK/GB18030提升兼容性，必要时fallback至mb_convert_encoding。
iconv 转换中文返回空或 false 的根本原因
不是 PHP 版本或扩展没开，而是 iconv 遇到无法映射的字符时默认中止并返回 false，同时不报错（除非开启错误报告），导致你看到的是空字符串或 null。这在 UTF-8 → GB2312/GBK 场景中最典型：UTF-8 支持上万汉字，而 GB2312 只覆盖约 6700 个常用字，像「?」「䶮」「?」这类生僻字、Emoji、全角标点（如「—」、「～」）都会触发截断。
必须加 //IGNORE 或 //TRANSLIT 才能避免截断
iconv 的第二个参数（目标编码）必须显式带上后缀，否则只要碰到一个非法字符，整个转换就停在那儿，后面所有内容全丢。这不是 bug，是设计如此。
-
iconv("UTF-8", "GB2312//IGNORE", $str)：直接丢弃无法转换的字符，适合对数据完整性要求不高、只求能显示的场景（比如日志、前端展示） -
iconv("UTF-8", "GB2312//TRANSLIT", $str)：尝试用近似字符替代，例如把「é」转成「e」，但对中文基本无效，且可能引入意外字符 - 别写
"gb2312"小写——虽然多数系统兼容，但某些旧环境（如 CentOS 6 + glibc 2.12）会识别失败，统一用大写"GB2312"
GBK 比 GB2312 更稳妥，但仍有盲区
GB2312 是子集，GBK 是超集，覆盖了更多简体中文扩展字（如「镕」「堃」）。很多看似“转码失败”的情况，其实只是用了 "GB2312" 而非 "GBK"。
-
iconv("UTF-8", "GBK//IGNORE", $str)比"GB2312//IGNORE"成功率高得多 - 但注意：GBK 仍不支持 Unicode 基本多文种平面以外的字符（如大部分 Emoji、古汉字），遇到照样返回
false - 若需更高兼容性，可先用
mb_detect_encoding($str, ['UTF-8', 'GBK', 'GB18030'], true)粗略判断源编码，再选目标编码
比 iconv 更鲁棒的 fallback 方案
当 iconv 返回 false 时，不要直接报错或丢数据，应降级处理：
立即学习“PHP免费学习笔记（深入）”；
- 先检查返回值：
if (false === $result = iconv($from, $to.'//IGNORE', $str)) { ... } - 尝试换目标编码：从
"GB2312"→"GBK"→"GB18030"（后者是国标超集，Windows 记事本默认保存格式） - 终极兜底用
mb_convert_encoding($str, $to, $from)：它内部做了容错，不会因单个字符失败而中断，但性能略低、依赖mbstring扩展开启 - 避免嵌套调用：
iconv('UTF-8', 'GBK', iconv('GBK', 'UTF-8', $str))这类写法极易因中间结果乱码导致二次失败
真正难处理的从来不是标准汉字，而是混合来源的数据：爬虫抓取的网页、老旧数据库导出的 CSV、用户粘贴进表单的 Word 内容——它们常夹带 BOM、控制字符、UTF-8 代理对或损坏字节。这时候光靠 //IGNORE 不够，得先清洗再转码。
