ZipUtil压缩工具类坑点

工具类包名：cn.hutool.core.util.ZipUtil

场景：需要将本地的文件以流的形式压缩并传给前端(本意是想着如果压缩成文件，还得开一个InputStream来读，性能可能会下降，实验结论在后文)

问题发现

第一次直接调用ZipUtil的public static void zip(OutputStream out, Charset charset, boolean withSrcDir, FileFilter filter, File... srcFiles)方法

脱敏代码如下：

HttpServletResponse response = getResponse();
response.setHeader("Content-disposition","attachment;filename=" + URLEncoder.encode("testOutPut", "UTF-8") + ".zip");
File file = new File("C:\\Users\\win\\Desktop\\新建文本文档.txt");ServletOutputStream outputStream = response.getOutputStream();
ZipUtil.zip(outputStream, Charset.defaultCharset(),Boolean.FALSE,null,file);

遇到的问题：前端下载正常，使用win10资源管理器打开压缩包显示 Windows 无法打开文件夹。“压缩(zipped)文件夹”C:\Users\win\Downloads\testOutPut.zip无效。

面向百度编程后，得到线索：压缩文件结尾有额外的异常文件，所以打不开，解决方案是关闭输出流。

但是我是从前端拿到的输出流，根据谁创建谁关闭原则，不应该关闭这个流。(当然我尝试过了，outputStream.close()还是同样的问题)

神奇的是，只有资源管理器不能打开该压缩包，使用360压缩可以正常解压，使用7-zip虽然打开和解压会报错，但是依然正常解压出文件。

第二次调用ZipUtil的public static void zip(ZipOutputStream zipOutputStream, boolean withSrcDir, FileFilter filter, File... srcFiles)方法

脱敏代码如下：

ZipOutputStream zipOutputStream = new ZipOutputStream(outputStream);
ZipUtil.zip(zipOutputStream,false,null,file);
zipOutputStream.close();

此时zip恢复正常，资源管理器可以正常打开。

问题溯源

第一个参数为OutputStream的方法本质上在内部将其包装成ZipOutputStream后再调用方法二
查看getZipOutputStream方法，其实就是判断是否为ZipOutputStream，否则new一个，将传入的流进行包装

到了这一步，我的想法是他创建了一个流，但是内部没有任何地方关闭它，且外部也没办法关闭，这样理论上不就违反了谁创建谁关闭原则吗？

后来经过老师指点，其实这个地方的思想是装饰者模式，本质上只是将传入的流进行包装，不是自己创建的新流，自然也不需要他关闭。

不过新的问题又出现了，按上述结论，zipOutputStream是不应该被关闭的，我为什么不加close就生成错误的zip，加了反而能正确运行呢？

// ZipOutputStream.java的close方法实际上调用的是他的父类DeflaterOutputStream.java的close
/*** Closes the ZIP output stream as well as the stream being filtered.* @exception ZipException if a ZIP file error has occurred* @exception IOException if an I/O error has occurred*/
public void close() throws IOException {if (!closed) {super.close();closed = true;}
}
// DeflaterOutputStream.java的close方法源码如下
/*** Writes remaining compressed data to the output stream and closes the* underlying stream.* @exception IOException if an I/O error has occurred*/
public void close() throws IOException {if (!closed) {finish();if (usesDefaultDeflater)def.end();out.close();closed = true;}
}

可以清楚的看到，DeflaterOutputStream.java的close方法先执行了finish()方法，再对流进行关闭。(同时修改关闭标志)

结论

实际上是流的finish()生效，每次创建一个压缩文件流时，需要finish()来标识该文件流已达到末尾，资源管理器在读到带结束标识的压缩文件才会正确打开(第三方压缩软件估计做了兼容处理)

而ZipUtil工具类中，作者直接new ZipOutputStream(ouputStream)，却没有在任何地方调用finish()方法来标识结束，导致当传入一个不需要关闭的Stream的时候，无法正确标识结束

解决方案

当你在传入一个不希望被关闭的Stream时，请在外部自行new一个ZipOutputStream对象并传入该Stream，调用完ZipUtil的方法后，手动调用ZipOutputStream的finish()方法来标识