Java原生ZipOutputStream中文乱码本质是编码写入与解压端解析不匹配的兼容性问题；变量文件名因来源不可控，易引发路径非法、编码冲突及跨平台解析失败，须结合目标环境选择UTF-8或GBK编码，并严格清洗文件名。
Java 原生 ZipOutputStream 处理含中文或特殊字符的变量文件名时，乱码不是“不支持”，而是编码约定与解压端解析方式不匹配导致的兼容性问题。关键不在文件内容，而在 ZIP 文件头中文件名字段用什么编码写入、以及目标系统用什么编码读取。
为什么变量文件名容易出问题
变量文件名（如用户上传的 fileName = "订单_20260508_张三.xlsx"）通常来自外部输入，未经规整就直接传给 ZipEntry，会放大以下风险：
- 路径非法：含
../、首字符为/或 Windows 盘符（C:），部分解压工具拒绝处理 - 编码不可控：若系统默认
sun.jnu.encoding=GBK（Windows 常见），但代码用 UTF-8 构造ZipOutputStream，而 WinRAR 却按 GBK 解析，就会显示乱码 - 混合环境：同一份 ZIP 可能在 macOS（默认 UTF-8）、Windows 资源管理器（默认 GBK）、Linux 终端（依赖 locale）中被打开，没有单一编码能 100% 兼容
推荐的编码设置策略
不要硬写死 "UTF-8" 或 "GBK"，应根据部署目标和工具链选择：
- 仅 Java 程序间传输（如服务端压缩 → Android/Java 客户端解压）：用
new ZipOutputStream(out, StandardCharsets.UTF_8)，最稳妥 - 需兼容 Windows 资源管理器或旧版 WinRAR：改用
org.apache.commons.compress.archivers.zip.ZipArchiveOutputStream，并调用setEncoding("GBK")和setUseUnicodeExtraFields(UnicodeExtraFieldPolicy.NOT_REQUIRED) - 跨平台交付且无法控制解压端：优先使用
org.apache.ant:ant的ZipOutputStream，它支持setEncoding(System.getProperty("sun.jnu.encoding"))，自动适配宿主系统文件名编码
变量名安全处理四步法
无论选哪种 ZIP 类，对变量文件名都必须做前置清洗：
- 过滤非法路径：用
Paths.get(name).getFileName().toString()提取纯文件名，丢弃上级路径 - 替换危险字符：将
、:、*、?、"、<、>、|替换为下划线或删除（Windows 文件系统限制） - 长度截断：ZIP 规范对单个文件名长度无硬限，但部分工具（如 iOS 文件 App）在 >100 字符时可能截断或报错，建议控制在 80 字符内
- 编码再确认：若用非 UTF-8 编码（如 GBK），确保字符串本身可无损转码——例如
"张三".getBytes("GBK").length == 4，而"€".getBytes("GBK")会抛UnsupportedEncodingException
避免踩坑的关键细节
这些操作看似微小，但漏掉一个就可能导致 ZIP 在某类设备上完全不可用：
- 别用
File.getName()直接构造ZipEntry：它可能返回"C:\data\report.pdf"，导致 ZIP 写入绝对路径 - 不要依赖
System.setProperty("sun.zip.encoding", ...)：该属性仅影响ZipFile构造，对ZipOutputStream无效 - 流式写入时禁止先
readAllBytes：变量文件若来自上传临时文件，应始终用FileInputStream+ 小缓冲区（如 8KB）逐块写入，防止 OOM - 每个
putNextEntry后必须closeEntry()：否则 ZIP 中央目录结构损坏，WinRAR 可能提示“文件损坏”
