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:\Windows\Fonts中copy喜歡到字體文件，如:simkai.ttf

點擊(此處)摺疊或打開

1. //define('ZBX_GRAPH_FONT_NAME', 'DejaVuSans'); // font file name
   
2. 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

說到這，不由想到以前很尊敬的一位前輩給我講的一個小故事，大意是

某品牌汽車接到客戶投訴，常常熄火。但對於該客戶投訴的汽車一直口碑很好且各方指標都很是好，但出於對客戶負責，因而派工程師去調查熄火緣由。

工程師瞭解到，客戶反映每次去某面包店買完麪包回來車就熄火了，其它店買東西都很正常。

工程師因而陪客戶一塊兒去該面包店買麪包。發現這家麪包店很普通的一家店，沒什麼特別，但有個狀況和其它店不同，這家麪包店作麪包的工藝比較講究，出爐的時間比較長，等客戶買完麪包出來，車就熄火了。

工程師這才明白，爲何車老在這家店門前熄火了。

工程師回去將帶速過長致使熄火的緣由報告給老闆，老闆給予了高度承認。

不少表象和實際緣由，汽車熄火--麪包店看似沒有多大關係，只有深刻調查才能瞭解到內在關聯。

運維人員更是如此，但願你們一塊兒共勉。