ZipOutputStream 中文乱码因默认IBM437编码，JDK7u40+需显式指定UTF-8；读取时须过滤目录项并调用closeEntry；大文件应流式处理避免内存溢出；ZIP64影响旧工具兼容性。
ZipOutputStream 写入时文件名乱码或中文路径报错
Java 原生 ZipOutputStream 默认使用 IBM437 编码，遇到中文路径或文件名会变成乱码，甚至抛出 java.util.zip.ZipException: invalid CEN header (bad signature) 或解压后文件名损坏。
根本原因不是“不支持中文”，而是 ZIP 规范本身没强制编码标准，而 JDK 8 及以前默认用旧编码。JDK 9+ 虽引入了 ZipCoder 自动探测，但不可靠，仍需显式控制。
- 用
new ZipOutputStream(OutputStream, Charset.forName("UTF-8"))构造（JDK 7u40+ 支持） - 确保所有
ZipEntry的name是合法路径字符串（不含..、首字符不为/），否则部分解压工具会拒绝处理 - 别依赖
File.getName()直接塞进ZipEntry：Windows 下可能带盘符，Linux 下可能含非法字符，先做路径规整
ZipInputStream 读取时跳过目录项或重复读取同一文件
ZipInputStream 是顺序流式读取，它把 ZIP 中的目录项（如 src/main/）也当作一个 ZipEntry 返回，但其 isDirectory() 为 true，且没有实际内容。如果代码没判断就直接调用 read()，会返回 -1，还可能干扰后续 entry 的读取位置。
更隐蔽的问题是：某些 ZIP 工具（如 macOS Finder 打包）会在末尾写入额外数据，导致 getNextEntry() 返回 null 后再调用一次，可能抛 IOException。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 每次循环必须检查
entry != null，且用if (!entry.isDirectory())过滤掉纯目录项 - 不要在
while ((entry = zis.getNextEntry()) != null)循环体里嵌套另一个getNextEntry() - 读取完当前 entry 内容后，**必须**调用
zis.closeEntry()，否则下一个getNextEntry()行为未定义（尤其在压缩包含加密或 ZIP64 扩展时）
压缩大文件时内存爆满或临时文件堆积
直接用 Files.readAllBytes(path) 把整个文件读进 byte[] 再写入 ZipOutputStream，等于内存里存了两份数据（原始文件 + ZIP 缓冲区），1GB 文件很可能触发 OutOfMemoryError。另外，若用 FileInputStream 读取后再通过 ByteArrayOutputStream 中转，同样白占内存。
还有人习惯边解压边生成临时文件到磁盘，却不清理，导致 /tmp 占满。
- 对每个
ZipEntry，用FileInputStream→BufferedInputStream→ZipOutputStream管道式写入，缓冲区设为 8192 字节足矣 - 避免任何
readAllBytes、toList()、collect(toList())等全量加载操作 - 解压目标路径务必用
Files.createDirectories()预建父目录，而不是靠new File(...).mkdirs()—— 后者在 NFS 或容器挂载卷上常静默失败
ZIP64 扩展与跨平台兼容性问题
当单个文件超过 4GB 或 ZIP 总条目数超 65535，JDK 默认启用 ZIP64 扩展。但老版本解压工具（如 Windows 自带的“压缩文件夹”、部分 Android App）根本不识别 ZIP64，直接报“无法打开归档文件”或“无效的 ZIP 文件”。
另外，ZipOutputStream.setMethod(ZipEntry.STORED) 虽能跳过压缩节省 CPU，但要求你手动计算 CRC32 和 size，稍有不慎就校验失败——而且 STORED 模式下 ZIP64 是强制的，反而加剧兼容问题。
- 如需兼容旧工具，压缩前先检查文件大小：
file.length() （约 2GB 安全阈值），超限则分卷或换 7z 格式 - 禁用 ZIP64 的唯一可靠方式是：确保所有文件
< 4GB、总条目< 65535、且不调用setUseZip64(ZipOutputStream.YES) - 别用
STORED模式除非你真能精确提供setSize()、setCrc()、setCompressedSize()三个值——漏一个，WinRAR 也会提示“CRC failed”
ZIP 的坑不在 API 多难，而在它表面简单、实则处处要和编码、边界、工具链博弈。最常被忽略的是：closeEntry() 不是可选的，Charset 参数不是装饰用的，而 ZIP64 兼容性问题往往等交付到客户环境才暴露。
