Java常用压缩解压类库与Gzip_技术教程_奈瑶·映南科技互联网学院

Java中GZIPOutputStream是JDK自带的gzip压缩方案，需调用close()确保CRC和长度信息写入，避免解压异常；小数据解压时read()返回0属正常，应循环至-1；多文件需先tar再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依赖：


  org.apache.commons
  commons-compress
  1.24.0

用法示例：

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组合。