PDF转换应用（使用Liberoffice）文件编码导致的中文乱码。

这是很久前的笔记，仅作为笔记记录，涉及公司项目故笔记仅会记录可公开部分。

使用liberoffice转换PDF方案，开发PDF转换应用的时候遇见的一个问题。（以下使用同一应用基于JDK:1.7.0_79、TOMCAT:8.0.50版本测试）

现象：

• 使用liberoffice应用转换PDF文件时，出现中文字符显示为“？”。

windows平台

PDF应用转换正常。（默认使用GBK）

linux平台

Red Hat Enterprise Linux Server release 6.7 ：

• 出现部分中文字体及符号乱码。（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，但出现了无效字符，故原因出现在此。使用16进制打开文件可以看到BOM标识符“ef bb bf”。

结论

存在误区：

开发时存在误认为指定文件编码后，即不会产生乱码，但实际上在获取输入流时即可能产生乱码。养成良好的习惯，系统在开发时，统一指定编码为“UTF-8”。

描述：在多平台（Windows、linux）部署使用liberoffice转换时，出现部分中文字体及符号乱码。

• 分析1：
  liberoffice在linux系统下中文字体库支持的较少，需引入中文字体库，该处不主要叙述，因之前已处理过该问题。

详细可自行搜索即可，网方也有相应的中文补丁包。

• 分析2：
  分析得出，该异常源自于该版本JDK的bug未处理该Bom头，Apache也针对此编写了BOMInputStream的实现类来处理该问题，当前也可以编写来处理。不然程序没有控制文件及内容编码时，默认使用系统编码，故存在着输入、输出的编码不一致。

提醒：开发人员不应依赖于操作系统所设置的编码，在代码编写时养成习惯显式的声明编码为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");