golang如何处理zip压缩包_golang zip压缩包处理思路-Golang-PHP中文网

go 的 zip.writer 默认不压缩、不设时间戳、不处理路径和编码，需显式设置 header.method=zip.deflate、header.modified、filepath.clean、utf-8标志（flags|=0x800）等，否则导致体积大、乱码、zip slip 漏洞等问题。

golang如何处理zip压缩包_golang zip压缩包处理思路

archive/zip 创建 zip 包必须手动设 header.Method = zip.Deflate，否则只是归档，不是压缩。

很多人发现用 Go 打出的 .zip 文件体积和源文件几乎一样，解压后时间戳全为 1970 年，打开还乱码——根本原因不是“Go 压缩不行”，而是默认用 zip.Store（即无压缩存储），且没设时间、没标编码、路径也没清理。

关键点在于：zip.Writer 不是“点一下就压缩”的黑盒，它只负责按 ZIP 格式把数据流写进去，压缩、路径、编码、时间，全得你显式控制。

为什么 `zip.Writer.CreateHeader` 调用后必须检查 `err`

这个函数会静默校验 header.Name：如果含 ../、以 / 开头、含非法字符（如 Windows 的 : 或 ?），它直接返回 error，但不会 panic，也不中断后续流程。结果就是 ZIP 看似生成成功，实际内部结构损坏，Windows 资源管理器打不开，unzip -t 报 “invalid central directory”。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

header.Name 必须是正斜杠分隔的相对路径，用 filepath.ToSlash(filepath.Clean(relPath)) 处理
绝对路径（如 /home/user/file.txt）或带盘符（如 C:\data\file.txt）会被拒绝写入
用户上传的原始文件名绝不能直传，需白名单过滤（如只允许 [a-zA-Z0-9._-] + /）
每次调用 writer.CreateHeader(header) 后必须写 if err != nil { return err }

解压时不做 `filepath.Clean` + 前缀校验，等于开放任意文件写入

攻击者构造一个名字为 ../../../etc/shadow 的条目，不校验就直接 os.OpenFile(filepath.Join(dst, f.Name), ...)，你的服务就可能把敏感文件覆盖掉——这就是 Zip Slip 漏洞，2026 年仍高频出现在 CI/CD 和文件共享服务中。

先用 filepath.Clean(f.Name) 归一化路径（把 ..\、./、重复 / 全干掉）
再判断是否仍含 ".." 或以 "/" 开头，有则跳过
更安全做法：算出目标绝对路径 dstAbs, _ := filepath.Abs(dstDir)，再检查 cleanedPath 拼接后是否仍以 dstAbs 开头（用 strings.HasPrefix(filepath.ToSlash(absDstPath), filepath.ToSlash(expected))）
遇到 f.IsDir() 为 true 的条目，也要调用 os.MkdirAll(..., 0755)，别指望自动建目录

`header.Flags |= 0x800` 是中文文件名在 Windows 上不乱码的关键

Go 默认按 UTF-8 写文件名，但旧版 Windows 资源管理器（Win7/Win10 早期版）默认用 GBK 解码，导致中文显示成 .txt。设 header.Flags = 0x800（即 1 ）告诉解压工具：“这名字是 UTF-8 编码的”。macOS/Linux 和新版 Windows（11+）、7-Zip、Bandizip 都认这个标志。

别用 header.Flags = 1 —— 这是老标准，兼容性差；0x800 是 ZIP APPNOTE 6.3.4 明确定义的 UTF-8 标志位
Go 1.22+ 提供了 header.SetUTF8(true)，效果等价，更语义化
如果必须支持 Win7 自带解压器，就得用 golang.org/x/text/encoding/charmap 转 GBK，再清空 Flags，但此时 Linux 下会乱码——没有通用解法，只能按目标环境选
空目录要显式加尾部斜杠：header.Name += "/"，否则很多解压工具识别不了

最常被忽略的不是语法，是资源关闭和路径净化：解压时 file.Open() 返回的 io.ReadCloser 必须 defer rc.Close()，否则几百个 zip 循环处理就会触发 too many open files；压缩时 writer.Close() 漏掉，ZIP 就缺中央目录，连 unzip -l 都列不出来。