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），但内部缓冲策略不同，小文件吞吐略低，大文件稳定性更好。

立即学习“Java免费学习笔记（深入）”；

MTTSHOP包包免费商城系统

一款非常包包、衣服、鞋子类网站，页面干净清洁、一目了然，mttshop打造精致、简单、易用、免费的商城。 系统要求：IIS5.1以后，必须安装.net 3.5 安装步骤： 1、下载完成后，直接解压文件mttshop.rar 2、附加数据库：解压后的可以找一个叫db的文件夹，解压后直接附加就可以，支持SQL 2000、2005、2008 3、配置web.config文件，找到key=&qu

下载

• 添加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()替代原生类