Java常用Gzip压缩解压方法详解

本文深入解析Java中使用GZIPOutputStream和GZIPInputStream进行gzip压缩与解压的核心要点，涵盖JDK原生方案的正确用法、常见陷阱及最佳实践：强调必须调用close()（而非仅flush）以确保CRC和长度信息完整写入，避免解压失败；澄清小数据解压时read()返回0属正常现象，需循环读取至-1；指出gzip本质是单流压缩，不支持多文件元数据，处理多个文件须先tar再gzip；同时提供安全解压模板、压缩级别自定义方式、HTTP响应解压注意事项，以及Android平台的兼容性建议，帮助开发者避开高频坑点，高效、稳健地集成gzip压缩功能。

Java里gzip压缩用java.util.zip.GZIPOutputStream最直接

不用额外依赖，JDK自带，适合简单场景。它包装一个OutputStream，写入时自动压缩，底层调用zlib。

常见错误是忘记close()——不关流会导致尾部CRC和长度信息缺失，解压时抛java.util.zip.ZipException: invalid stored block lengths或类似IO异常。

• 必须调用close()（或用try-with-resources），不能只flush()
• 压缩级别用Deflater控制：new GZIPOutputStream(out, true)第二个参数启用默认压缩，但无法自定义级别；如需设级别，得手动构造Deflater并传给GZIPOutputStream(OutputStream, Deflater)
• 对小数据（

Apache Commons Compress更适合多格式统一处理

如果项目里还要处理.tar、.zip、.xz等，commons-compress比零散用JDK类更可控。它把gzip封装成ZipArchiveOutputStream的兄弟类GzipCompressorOutputStream，API更一致。

注意它不替代JDK的GZIPOutputStream，而是提供另一套实现，压缩结果完全兼容标准gzip（RFC 1952），但内部缓冲策略不同，小文件吞吐略低，大文件稳定性更好。

• 添加Maven依赖：

  <dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-compress</artifactId>
    <version>1.24.0</version>
  </dependency>

• 用法示例：

  GzipCompressorOutputStream gzos = new GzipCompressorOutputStream(new FileOutputStream("out.gz"));
  gzos.write("hello".getBytes(StandardCharsets.UTF_8));
  gzos.close(); // 同样必须close

• 它支持setBufferSize(int)，对高吞吐场景（如日志压缩）可设为64KB以上

Spring Framework的GzipResponseWrapper仅限Web响应压缩

Spring MVC没提供通用gzip工具类，但org.springframework.web.servlet.resource.GzipResponseWrapper专用于HTTP响应体压缩。它不是独立工具，而是配合ResourceHttpRequestHandler或过滤器使用的包装器。

别误以为它能压缩任意字节数组——它只在Servlet容器响应写出前拦截getOutputStream()或getWriter()，内部仍委托给GZIPOutputStream。配置不当会导致Content-Encoding未设、浏览器不解压，或乱码（没设Content-Type字符集）。

• 启用方式：在WebMvcConfigurer中配ResourceHandlerRegistry，或加@Bean注册GzipEncodingFilter
• 关键点：response.setHeader("Content-Encoding", "gzip")必须由它自动完成，手动设容易漏掉Vary头
• 它不处理请求体解压，POST的gzip body要靠ContentLengthFilter或自己用GZIPInputStream解析

解压时GZIPInputStream遇到EOF异常多数是流没关或数据截断

读取gzip流时抛java.io.EOFException: Unexpected end of ZLIB input stream，基本可断定输入源不完整：要么原始gzip文件被截断，要么网络传输中途断开，要么写入方没close()导致尾部校验字节丢失。

不要用available() > 0判断是否还有数据——它在gzip流里返回0是常态，正确做法是循环read(byte[])直到返回-1。

• 安全解压模板：

  try (GZIPInputStream gzin = new GZIPInputStream(new FileInputStream("in.gz"))) {
    byte[] buf = new byte[8192];
    int len;
    while ((len = gzin.read(buf)) != -1) {
      // 处理buf[0..len)
    }
  }

• 若输入来自HTTP响应，确认服务端确实返回了Content-Encoding: gzip且响应体完整（检查Content-Length或用chunked编码）
• Android上部分旧版本API对gzip尾部校验更敏感，建议用Okio.source().gzip()替代原生类

Gzip本身是单流压缩，不存文件名、权限等元数据——这点常被忽略，导致误用它替代zip处理多文件打包。真要存多个资源，得先tar再gzip，或者直接上commons-compress的TarArchiveOutputStream + GzipCompressorOutputStream组合。

今天关于《Java常用Gzip压缩解压方法详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！