Java生成PDF的若干坑 | 您所在的位置:网站首页 › java报表生成pdf生僻字问题 › Java生成PDF的若干坑 |
2019独角兽企业重金招聘Python工程师标准>>> 在工作中,有使用Java生成大量的电子凭证,也就是PDF。在之前的文章中,有写过,如何通过Java生成PDF。这里就不再描述,写这篇文章主要是为了记录我在使用Java生成PDF过程中犯过的错,以及踩过的坑。 内存溢出之前在使用生成方案的时候,我们一开始采用的是《PD4ML》框架,这个框架相对来说,要小巧些。但是不足的是:它是闭源的。在批量生成PDF文件时会出现内存泄漏的现象。每每我们在分析内存原因时,都止步于下面这一段代码: private void createPdfByHtml(String html, File file) throws Exception{ FileOutputStream fos = new FileOutputStream(file); ... // 这一行 pd4ml.render(sr, fos, new URL("http://"), "UTF-8"); }因此,我们不得不考虑换一个第三方库。目前我们使用的是开源库《iText》,到目前为止,稳定运行。 (我们在选择第三方框架时,尽量选择开源的,因为在出现问题后,我们可以通过查看源代码分析,甚至可以修改源代码进行优化)。 字体路径这个问题是这样的,我们生成PDF时为了支持中文字体,需要通过路径加载指定的字体文件。而开发环境是windows,测试/生产环境均是Linux。字体放在 /resources/fonts/因为: 在Window下获取Thread.currentThread()为null值 在Linux下获取this.class.getClass().getResource(“/“).getPath();获取为null值 所以在加载路径时,我们通过下述方法进行了兼容处理。 /** * 应用场景: * 1.在windows下,使用Thread.currentThread()获取路径时,出现空对象,导致不能使用 * 2.在linux下,使用PdfUtils.class获取路径为null, * 获取字体路径 * @return */ private static String getFontPath(){ String path=""; // 1. 生产环境路径 ClassLoader classLoader= Thread.currentThread().getContextClassLoader(); URL url = (classLoader==null)?null:classLoader.getResource("/"); String threadCurrentPath = (url==null)?"":url.getPath(); // 2. 如果线程获取为null,则使用当前PdfUtils.class加载路径 if(StringUtil.isBlank(threadCurrentPath)){ path = PdfUtils.class.getClass().getResource("/").getPath(); } // 3.拼接字体路径 StringBuffer stringBuffer = new StringBuffer(path); stringBuffer.append("/fonts/SIMKAI.TTF"); path = stringBuffer.toString(); logger.info("getFontPath threadCurrentPath: {} path: {}",threadCurrentPath,path); return path; }从这个方面也能体现一个程序员常见现象。 为什么在我电脑上是好的,在你电脑上不行,一定是你电脑问题。 不应该啊,在我电脑上是好的。绝对没问题。 小伙伴们知道这个梗吗? 这也是很多程序员使用与生产环境一致的系统作为开发机的原因。 字符编码问题是这样的。是由于在生成PDF文件时转换字节流时没有指定编码导致的: 如下所示: public static void createdPdfByItextHtml(String htmlContent,File file){ ... try { inputStream= new ByteArrayInputStream(htmlContent.getBytes()); outputStream = new FileOutputStream(file); ...此处省略掉部分代码,此时htmlContent.getBytes()该方法没有指定默认的编码导致的。具体的原因,在《初探JDK源码之默认字符集》这篇文章中有详细的描述。 生僻字这个坑是这样的,因为正式公文的字体是:Kaiti_GB2312的字体。我们使用过一段时间发现,Kaiti_GB2312字体对于生僻字支持不友好。 例如: 例如: 陈垚,通过Kaiti_GB2312生成后就只能显示为: 陈 其中垚字就没有正常显示。这个问题是非常严重的。如果电子凭证中姓名错误,也就代表,这份电子凭证是没有法律效应的。在经过测试后,我们最终使用了Kaiti字体,代替了Kaiti_GB2312。(这个坑,还真的不容易发现) 5. 枚举传递类型 如果Dubbo接口中使用枚举作为参数时,如果只有单方面更新枚举的值。会导致序列化出错的问题。也就是说: 调用方在更新枚举后,如果接受方不同时更新枚举,会导致接收方的参数为空对象。 注意点: Dubbo服务调用之间,尽量不要使用enum类型。 严格的HTML语义标签 使用过itext的朋友应该知道。HTML内容是需要严格的标签的。也就是说,一个开始标签,对应一个结束标签。如果不匹配,则会生成失败。(像 错误的html: Hello World!上面这段html内容,就多了一个结束标签,就属于非严格的HTM语义标签。 执行后,就会有下面这类错误: com.itextpdf.tool.xml.exceptions.RuntimeWorkerException: Invalid nested tag span found, expected closing tag body. at com.itextpdf.tool.xml.XMLWorker.endElement(XMLWorker.java:134) at com.itextpdf.tool.xml.parser.XMLParser.endElement(XMLParser.java:396) 最后有些系统,看起来容易。做起来可并非易事。在实现期间可能会遇到各种各样的奇葩问题。但恰恰,就是这些怪问题。给我们积累了经验。我一直觉得,在写代码方面,是一个“倒霉”的人,因为各种奇怪的问题,都能让我遇到。 公众号内回复:【PDF】,即可获取项目。记得更换字体哦! 相关阅读: 《说说面试那些事》 《Java PDF生成方案之iText》 《一个Java细节!》 《记一个有趣的Java OOM!》 扫码关注,一起进步 个人博客: http://www.andyqian.com |
CopyRight 2018-2019 实验室设备网 版权所有 |