Tomcat10/Java11迁移后PDF/XLS浏览器响应内容损坏排查求助

核心原因：JSP字符流与二进制输出的冲突 #

老JSP代码默认使用字符输出流（JspWriter）处理内容，而PDF/XLS属于二进制数据，直接通过字符流输出时，会被JSP的默认字符编码（如UTF-8）转码，导致二进制字节被篡改。Java 8到Java 11的字符编码默认规则、Tomcat 8到Tomcat 10的JSP容器处理逻辑变化，放大了这个问题——之前可能因某些兼容逻辑侥幸生效，迁移后暴露了本质问题。

具体排查与修复步骤 #

• 强制JSP使用二进制输出流
  在JSP开头添加page指令，明确设置内容类型为对应二进制格式，并禁用字符编码转换：

  <%@ page contentType="application/pdf; charset=UTF-8" %>
  <%@ page pageEncoding="ISO-8859-1" %> <!-- 用单字节编码避免转码 -->
  <%
    response.setContentType("application/pdf");
    response.setContentLength(pdfByteArray.length); // 必须设置准确长度
    ServletOutputStream out = response.getOutputStream();
    out.write(pdfByteArray);
    out.flush();
    out.close();
    return; // 终止JSP后续的字符流输出
  %>
  

  关键是直接获取ServletOutputStream（字节流）输出，而非使用JSP默认的out对象（字符流），同时设置Content-Length让浏览器准确接收全部字节。

• 检查是否意外触发字符流与字节流的冲突
  Tomcat 10对getWriter()和getOutputStream()的调用顺序检查更严格。如果JSP中先隐式调用了getWriter()（比如输出了任何文本内容，包括空白字符），再调用getOutputStream()会抛出异常，而老版本Tomcat可能静默处理，导致部分字节被截断或转码。
  解决：确保JSP中除了二进制输出代码外，没有任何多余的文本（包括JSP标签外的空格、换行）。

• 验证响应头的正确性
  检查响应头是否包含以下必要字段：

  • Content-Type：必须准确对应文件类型（如application/pdf、application/vnd.ms-excel）
  • Content-Disposition：可选，用于指定下载文件名，如attachment; filename="report.pdf"
  • Content-Length：必须与字节数组长度完全一致，避免分块传输导致的解析错误

• 排除Tomcat压缩配置影响
  如果Tomcat开启了Gzip压缩，可能对二进制内容的压缩处理逻辑在新版本中变化，导致损坏。可以临时关闭对应路径的压缩，验证是否解决问题：
  在server.xml的Connector中添加或修改：

  <Connector ...>
    <Compression>off</Compression>
  </Connector>
  

  确认问题后，再配置仅对文本内容启用压缩，排除二进制类型。

额外说明 #

Java 11本身的字节数组编码逻辑并未改变，问题根源在于JSP容器的输出流处理规则变化，而非Java核心库的差异。本地文件写入正常，说明生成的字节数组完全有效，故障点仅在从服务器响应到浏览器的传输环节。

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