這是很久前的筆記，僅作為筆記記錄，涉及公司項(xiàng)目故筆記僅會記錄可公開部分。
使用liberoffice轉(zhuǎn)換PDF方案，開發(fā)PDF轉(zhuǎn)換應(yīng)用的時候遇見的一個問題。（以下使用同一應(yīng)用基于JDK:1.7.0_79、TOMCAT:8.0.50版本測試）
現(xiàn)象：
- 使用liberoffice應(yīng)用轉(zhuǎn)換PDF文件時，出現(xiàn)中文字符顯示為“？”。
windows平臺
PDF應(yīng)用轉(zhuǎn)換正常。（默認(rèn)使用GBK）
linux平臺
Red Hat Enterprise Linux Server release 6.7 ：
- 出現(xiàn)部分中文字體及符號亂碼。（LANG=zh_CN.GBK）
Red Hat Enterprise Linux Server release 6.7 ：
- 正常。（LANG=en_US.UTF-8）
CentOS release 6.9：
- 正常。（LANG=en_US.UTF-8）
分析
notepad++查看為UTF-8
圖缺了，直接打開工具查看吧。
UltraEdit：
圖缺了，直接打開工具查看吧。
檢測出文件編碼為UTF-8，但出現(xiàn)了無效字符，故原因出現(xiàn)在此。使用16進(jìn)制打開文件可以看到BOM標(biāo)識符“ef bb bf”。
結(jié)論
存在誤區(qū)：
開發(fā)時存在誤認(rèn)為指定文件編碼后，即不會產(chǎn)生亂碼，但實(shí)際上在獲取輸入流時即可能產(chǎn)生亂碼。養(yǎng)成良好的習(xí)慣，系統(tǒng)在開發(fā)時，統(tǒng)一指定編碼為“UTF-8”。
描述：在多平臺（Windows、linux）部署使用liberoffice轉(zhuǎn)換時，出現(xiàn)部分中文字體及符號亂碼。
- 分析1：
liberoffice在linux系統(tǒng)下中文字體庫支持的較少，需引入中文字體庫，該處不主要敘述，因之前已處理過該問題。
詳細(xì)可自行搜索即可，網(wǎng)方也有相應(yīng)的中文補(bǔ)丁包。
- 分析2：
分析得出，該異常源自于該版本JDK的bug未處理該Bom頭，Apache也針對此編寫了BOMInputStream的實(shí)現(xiàn)類來處理該問題，當(dāng)前也可以編寫來處理。不然程序沒有控制文件及內(nèi)容編碼時，默認(rèn)使用系統(tǒng)編碼，故存在著輸入、輸出的編碼不一致。
提醒：開發(fā)人員不應(yīng)依賴于操作系統(tǒng)所設(shè)置的編碼，在代碼編寫時養(yǎng)成習(xí)慣顯式的聲明編碼為UTF-8。（或處理編碼的兼容）
例如：
//輸入流
isr = new InputStreamReader(in,"UTF-8");
//輸出流
OutputStreamWriter osw = new OutputStreamWriter(fos, "UTF-8");
//解析html文本
Document doc = Jsoup.parse(content.toString(), "UTF-8");
//寫文件
FileUtils.writeStringToFile(new File(tempPath), content.toString(),"UTF-8");
