GD中文乱码主因是--enable-gd-jis-conv编译选项强制EUC-JP解码及编码链路断裂；需禁用jis_conv、统一转UTF-8、验证字体路径与Unicode覆盖、清除输出缓冲。
GD库输出中文乱码，不是字体没放对，也不是PHP没开GD扩展——根本原因往往藏在编译参数或编码链路里。只要搞清 imagettftext() 的字符流走向，90% 的乱码问题不用换字体、不重装PHP就能修好。
检查 PHP-GD 是否启用了 --enable-gd-jis-conv
这个编译选项会让 GD 把所有非 ASCII 字符（包括中文）强行按 EUC-JP 解码，结果就是“你好”变成一堆方块或问号。它和字体无关，是底层解码逻辑的硬性覆盖。
- 运行
php -i | grep "Configure Command" | grep jis-conv，如果输出非空，说明已被启用 - 临时禁用：在
/etc/php.d/zabbix.ini或php.ini末尾加[gd]段并写入jis_conv = 0 - 若配置不生效，说明 PHP 是静态编译进系统（如某些 Alpine 镜像），必须重新编译 PHP 并去掉该选项
imagettftext() 前必须做编码转换
GD 的 imagettftext() 只认 UTF-8 字节流，但你的 PHP 文件可能是 GBK 编码，数据库字段可能是 latin1，前端 POST 过来的数据可能没声明 charset——任何一环脱节都会导致传给函数的字符串实际是乱码字节。
- 别依赖文件保存编码，用
mb_detect_encoding($str)确认输入源的真实编码 - 统一转成 UTF-8：优先用
mb_convert_encoding($str, 'UTF-8', 'auto')，比iconv()更容错 - 如果已知来源是 GBK，用
iconv('GBK', 'UTF-8//IGNORE', $str)，//IGNORE能跳过无法转换的非法字节 - 避免用
utf8_encode()，它只适用于 ISO-8859-1 → UTF-8，对 GBK/GB2312 会出错
字体路径和字体本身要同时过关
就算编码全对，imagettftext() 仍可能静默失败——不是报错，而是画布上啥也不显示，或者只显示 ASCII 部分。这时大概率是字体路径不可读，或字体不包含对应 Unicode 码位。
立即学习“PHP免费学习笔记（深入）”；
- 路径必须是绝对路径，且 PHP 进程有读权限：
/var/www/html/font/simhei.ttf比./font/simhei.ttf更可靠 - Windows 下注意双反斜杠或正斜杠：
C:/Windows/Fonts/simhei.ttf可用，C:\Windows\Fonts\simhei.ttf可能被当转义序列处理 - 用
file_exists()和is_readable()显式检查字体文件状态，别靠函数返回值判断成败 - simhei.ttf、simsun.ttc 是常见选择，但部分精简版 simhei.ttf 缺少 CJK 扩展区汉字（如“?”“鱻”），测试时用“你好世界”比用“测试”更保险
别忽略输出前的缓冲区污染
很多乱码现象其实不是 GD 绘图出错，而是 HTTP 响应体开头混入了 BOM、空格、警告信息或框架自动注入的 HTML —— 导致浏览器把 PNG 当成文本解析，自然显示为乱码符号。
- 在
header('Content-Type: image/png')前加ob_clean();清掉已有输出 - 确保脚本顶部没有空行、BOM 字节（用
hexdump -C your_script.php | head查看） - 关闭错误报告：临时加
error_reporting(0); ini_set('display_errors', '0');，防止 warning 写进图片流 - 生成后立刻
exit;，避免后续代码意外输出
最常被跳过的其实是编码探测环节：你以为传进去的是 UTF-8，但 $_POST['name'] 可能是 GBK，MySQL utf8mb4 字段查出来也可能是 latin1 连接下的乱码。在调用 imagettftext() 前加一行 var_dump(bin2hex($str));，比猜强十倍。
