zabbix 彻底解决图片中文乱码

zabbix 彻底解决图片中文乱码

环境:

CentOS 7.2

zabbix-3.0.4 LTS

nginx-1.10.0

php-5.6.26

mariadb-10.1.13

请参看zabbix-3.0.x LTS源码安装配置

中文支持
#zabbix zh_CN
sed -i '/zh_CN/s/false/true/g' /usr/local/nginx/html/zabbix/include/locales.inc.php
中文乱码

把相应的字体文件(.ttf)copy到/usr/local/nginx/html/zabbix/fonts，再修改zabbix字体定义配置即可。
可以从windows系统C:WindowsFonts中copy喜欢到字体文件，如:simkai.ttf

点击(此处)折叠或打开

//define('ZBX_GRAPH_FONT_NAME', 'DejaVuSans'); // font file name

define('ZBX_GRAPH_FONT_NAME', 'simkai'); // font file name

提示:很多文章讲替换两条记录，实际上只需要改ZBX_GRAPH_FONT_NAME一条即可，改两条是改了整个调用字体(和直接同名替换DejaVuSans是一个意思)

说到这，有个插曲，困惑了好久，通常来说乱码到这里就应该会解决。是的，选项栏等什么的都能正常显示中文，但为独图片报表这一块是乱码。

可能我是个例外，按上面的步骤后，图片乱码依旧，只不过由原来的空心方框变成了看不懂的火星文。一连测试了好几天，终于找到问题出在哪儿了，下面是排查步骤

i.测试数据库

数据库一直都默认为utf8，所以可能性不大。

保持数据库不变，既然源码装的乱码，那么在同一台主机上用iso源自带的rpm包来作相同配置，httpd,php通过iso源安装，按照解决乱码的思路走下来，乱码不见了，中文显示正常。理下现在的环境，在同一台主机上源码安装了nginx,php,mariadb服务都正常，上述乱码解决方法无效；又在其上通过iso源yum安装了httpd,php，直接将在nginx下的zabbix目录整个软链到apache的DocumentRoot下，乱码消失，一切正常。

也就是说数据库都是同一数据库，不同的是iso源yum安装httpd,php与源码安装nginx,php，问题出在源码安装的nginx或php上。

ii.交叉测试以定位web服务器和php

系统自带apache(httpd)调用源码安装的php，中间有个小插曲，在源码解压及安装的php目录下都没找到libphp5.so，百度后解决(源码编译php时需要通过--with-apxs2=/usr/bin/apxs指定apache库调用，apxs同httpd-devel包提供)，于是加上该参数重新编译php，编译安装完，会看到将libphp5.so复制到apache的modules目录。此时重启httpd，结果乱码重现了。

[root@node1 ~]# ll /etc/httpd/modules/libphp5.so

-rwxr-xr-x. 1 root root 33572931 9月 25 03:26 /etc/httpd/modules/libphp5.so

[root@node1 ~]# ll /usr/local/src/php-5.6.26/libs/libphp5.so

-rwxr-xr-x. 1 root root 33572931 9月 25 03:26 /usr/local/src/php-5.6.26/libs/libphp5.so

进一步测试通过iso源安装的php

yum -y install php-fpm

sed -i '/127.0.0.1:9000/c listen = /dev/shm/php-fpm.sock' /etc/php-fpm.d/www.conf

sed -i '/;listen.owner/s/^;//g' /etc/php-fpm.d/www.conf

sed -i '/;listen.group/s/^;//g' /etc/php-fpm.d/www.conf

sed -i '/;listen.mode/c listen.mode = 0666' /etc/php-fpm.d/www.conf

systemctl restart php-fpm

因为之前源码编译的php-fpm是监听在tcp 9000，为了更好的对比这里直接直接采用socket监听方式(当然也可以监听不同端口)，结果通过nginx调iso源的php-fpm中文显示正常。

总结，iso源httpd+源码编译php中文乱码，iso源php+源码编译nginx中文正常。

zabbix图片乱码是源码编译的php导致

iii.php编译参数调试

经过反复编译测试，发现是由--enable-gd-jis-conv参数引起的，编译php时若加入该参数则会导致zabbix图片中文乱码，去掉后一切正常，也有朋友遇到类似的问题http://www.bubuko.com/infodetail-221610.html

php官方解释

*虽然imagettftext()文档标明只接受UTF-8编码，但如果PHP编译时启用–enable-gd-jis-conv选项的话，那么非ASCII字符(例如汉字、拼音、希腊文和箭头)会被当成EUC-JP编码(phpinfo中美其名曰“支持JIS编码的字体”), 从而导致乱码(由于西文字体没有假名或汉字，一般表现为全部是方框)

Although imagettftext()documentation indicates it only accepts UTF-8 encoding, but if–enable-gd-jis-conv is specified when compiling PHP, then non-ASCII characters(like Chinese, accented characters, Greek and arrows) will be (mis-)treated asEUC-JP encoding (referred to as “JIS-mapped Japanese Font Support” in phpinfo)leading to mojibake (this usually shows up as hollow rectangles, as most fontsfor western text lacks glyphs for kanji or kana)

结论，编译php时不要加--enable-gd-jis-conv

说到这，不禁想到之前很尊敬的一位前辈给我讲的一个小故事，大意是

某品牌汽车接到客户投诉，经常熄火。但对于该客户投诉的汽车一直口碑很好且各方指标都非常好，但出于对客户负责，于是派工程师去调查熄火原因。

工程师了解到，客户反映每次去某面包店买完面包回来车就熄火了，其它店买东西都很正常。

工程师于是陪客户一起去该面包店买面包。发现这家面包店很普通的一家店，没什么特别，但有个情况和其它店不一样，这家面包店做面包的工艺比较讲究，出炉的时间比较长，等客户买完面包出来，车就熄火了。

工程师这才明白，为什么车老在这家店门前熄火了。

工程师回去将带速过长导致熄火的原因报告给老板，老板给予了高度认可。

很多表象和实际原因，汽车熄火--面包店看似没有多大关系，只有深入调查才能了解到内在关联。

运维人员更是如此，希望大家一起共勉。