这是很久前的笔记，仅作为笔记记录，涉及公司项目故笔记仅会记录可公开部分。
使用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");
