PDF流传输损坏（含NUL前缀、缺失%%EOF）技术问询

开发者阿泽

2026-5-29

先快速回顾下你的场景：你的应用提供PDF查看/下载功能，核心输出代码如下：

while ((readLength = bufInputStream.read(buffer)) != -1) { 
    outStream.write(buffer, 0, readLength); 
}

近期出现「打开文档出错，文件已损坏无法修复」的报错，排查后发现损坏PDF开头带有NUL前缀、结尾丢失了%%EOF标识，手动补全结尾可恢复正常；且问题从PDF 1.6版本开始出现，传输链路包含负载均衡、缓存服务器。下面逐个解答你的疑问：

核心原因是PDF版本升级后，格式校验和传输组件行为的双重变化：

旧版本PDF（比如1.5及以下）的解析器容错性更高，即使存在小格式问题（缺失EOF或前缀冗余字符），Acrobat或浏览器也能兼容解析；但PDF 1.6开始规范更严格，解析器对格式错误的容忍度大幅降低，直接判定文件损坏。
传输链路上的负载均衡、缓存服务器可能对PDF 1.6的文件处理逻辑有差异：比如文件大小、编码方式的变化触发了组件的缓存/转发bug，导致NUL前缀被添加，同时截断了结尾的%%EOF；而之前的PDF版本刚好没触发这个bug。
也有可能是PDF 1.6的生成逻辑有细微调整，和传输组件的bug叠加后，才让之前隐藏的格式问题暴露出来。

这是两个独立的问题，不存在因果关系：

%%EOF是PDF格式标准规定的必须结尾标识，应该在PDF生成阶段就已经存在。NUL前缀是传输过程中由中间组件（负载均衡/缓存）额外添加的，不属于PDF生成环节的内容，所以生成端不会因为传输中多了NUL就自动补全EOF。
传输组件的核心职责是转发或缓存数据，默认不会修改文件内容结构，它们不会主动检测PDF是否缺失%%EOF并补全——除非你配置了专门的自定义规则。
你看到的情况应该是：传输过程中既意外添加了NUL前缀，又因为Content-Length设置错误、分块传输截断等原因丢失了原始PDF的%%EOF结尾，两个问题同时发生而已。

没有通用的开箱即用配置，但可以通过组件的自定义能力实现：

WebSphere：本身没有默认配置，但你可以编写自定义Servlet Filter，在响应输出到客户端前，检查响应内容是否为PDF，验证结尾是否有%%EOF，缺失则追加。
负载均衡/缓存服务器：比如Nginx、Varnish这类组件，可以通过Lua脚本或自定义规则，检测响应的Content-Type为application/pdf时，检查响应体结尾是否包含%%EOF，缺失则追加；同时也可以过滤开头的NUL字符。不过这种方式需要一定的组件配置能力，还要注意性能影响，避免误处理其他文件。
注意：Acrobat和浏览器没有这类自动补全的配置，它们只会严格校验格式。

不是必须，但修改应用代码是最可靠、最易维护的解决方案：

优先从根源入手：检查PDF生成环节，确保生成的原始PDF本身就包含正确的%%EOF结尾，避免后续环节的截断问题。
针对NUL前缀：可以在应用读取PDF内容输出前，过滤掉开头的NUL字符；或者检查响应头的Content-Length是否设置准确，避免传输过程中因为长度不匹配导致额外字符添加或内容截断。
如果不想修改应用代码，也可以在传输链路的组件上配置规则处理，但这种方式依赖组件能力，后续维护成本更高，且可能因组件升级导致规则失效。从长期稳定性考虑，修改应用代码规范PDF输出和响应处理是最优选择。

Acrobat：没有相关设置。Acrobat对PDF格式的校验非常严格，尤其是高版本PDF，一旦检测到格式不符合规范（缺失%%EOF、前缀有无效字符），就会判定文件损坏，无法通过设置跳过这些校验。
WebSphere：没有直接的设置，但可以通过自定义Filter来处理PDF响应，过滤NUL前缀并确保%%EOF存在；另外可以检查WebSphere的传输配置，比如是否开启了分块传输（Chunked Encoding），如果是，确保Content-Length头正确设置，避免传输截断。
浏览器：内置的PDF viewer同样没有这类容错设置，它们依赖标准的PDF解析库，严格遵循格式规范。第三方浏览器插件可能有更高的容错性，但这不是通用解决方案，不建议作为生产环境的依赖。

内容的提问来源于stack exchange，提问作者MQ Beginner