Go archive/zip FileHeader Method 怎样区分存储和压缩条目

我们直接通过Go标准库`archive/zip`中`FileHeader`结构体自带的`Method`字段，就能快速区分zip归档里的条目是未压缩的存储模式，还是经过压缩处理的模式。

zip规范里明确定义了不同压缩算法对应的枚举值，Go标准库已经把这些值封装到了对应常量中，直接判断`FileHeader.Method`的取值就能得到结果，不需要自行解析文件头做额外计算。

我第一次需要按 ZIP 条目做路由时，误把 FileHeader.Method 当成“文件格式”来理解，看到数值变化就想按 TXT、JSON、图片分别处理。后来才发现它描述的是压缩方法：0 是 Store，8 是 Deflate。真正读取文件内容时，普通业务代码应该让 File.Open 负责透明解压和校验；只有需要保留原始压缩字节时，才使用 File.OpenRaw。

判断 ZIP 条目是否压缩，看 FileHeader.Method；读取可用内容优先用 File.Open，不要根据 Method 自己拼解压流程。

我后来把 Method 当成了什么

archive/zip 的 FileHeader 描述的是 ZIP 中的一个条目。它的 Name 是条目名称，CompressedSize64 和 UncompressedSize64 是尺寸信息，而 Method 只表示压缩方法，不表示文件内部是 CSV、JSON 还是 PNG。

标准库目前把常用方法定义成两个常量：

• zip.Store 的值是 0，表示不压缩，条目内容直接存储。
• zip.Deflate 的值是 8，表示使用 DEFLATE 压缩。

所以一个名为 config.json 的条目可能是 Store，也可能是 Deflate；文件名后缀和 Method 是两件不同的事。

先打印 Method，再决定怎样观察条目

我现在排查 ZIP 文件时，会先把方法名打印出来，但不会把它当成必须手工解压的信号。下面这个示例只做条目识别和正常读取，适合导入、预览、解包等常规任务。

package main

import (
	"archive/zip"
	"fmt"
	"io"
)

func main() {
	reader, err := zip.OpenReader("assets.zip")
	if err != nil {
		// 打开失败通常说明文件不是合法 ZIP，或读取底层文件时发生错误。
		panic(err)
	}
	defer func() {
		// ReadCloser 仍然持有文件资源，结束时要把关闭错误单独处理。
		if err := reader.Close(); err != nil {
			fmt.Println("关闭 ZIP 失败:", err)
		}
	}()

	for _, entry := range reader.File {
		methodName := "未知方法"
		switch entry.Method {
		case zip.Store:
			methodName = "Store（不压缩）"
		case zip.Deflate:
			methodName = "Deflate（压缩）"
		}
		fmt.Printf("%s: method=%d %s\n", entry.Name, entry.Method, methodName)

		body, err := entry.Open()
		if err != nil {
			// 不支持的压缩方法会在打开内容时暴露，不能只看文件名猜测。
			fmt.Println("打开条目失败:", err)
			continue
		}
		data, readErr := io.ReadAll(body)
		closeErr := body.Close()
		if readErr != nil {
			// Read 阶段可能发现内容损坏或校验不通过。
			fmt.Println("读取条目失败:", readErr)
			continue
		}
		if closeErr != nil {
			// 关闭错误也要保留，避免把资源问题悄悄吞掉。
			fmt.Println("关闭条目失败:", closeErr)
			continue
		}
		fmt.Println("解压后字节数:", len(data))
	}
}

这里最重要的是顺序：先看 Method 便于日志和策略判断，再把内容读取交给 Open。即使是 Store，调用 Open 也没有问题；它只是跳过实际的解压步骤，统一返回可读内容。

File.Open 与 File.OpenRaw 的分界

这两个方法看起来只差一个 Raw，实际语义完全不同：

我在做归档转存时才会考虑 OpenRaw。如果目标是“拿到文件内容”，使用它反而容易把 Deflate 数据当成文本，最后得到一串无法解析的字节。

需要原始字节时，别忘了 Method 仍然有效

OpenRaw 不会解压，所以调用方仍要依据 Method 决定后续处理。下面示例只展示边界，不实现一套新的 ZIP 解码器。

func readRaw(entry *zip.File) ([]byte, error) {
	raw, err := entry.OpenRaw()
	if err != nil {
		// OpenRaw 本身只负责取得原始读取器，错误仍然要向上返回。
		return nil, err
	}

	data, readErr := io.ReadAll(raw)
	if readErr != nil {
		// 原始读取失败时不要把不完整的数据交给后续压缩处理器。
		return nil, readErr
	}

	switch entry.Method {
	case zip.Store:
		// Store 没有压缩层，原始数据就是条目内容。
		return data, nil
	case zip.Deflate:
		// Deflate 的原始数据还需要由对应解压器处理，不能直接转成字符串。
		return data, nil
	default:
		// 未识别的方法交给上层决定是否注册自定义解压器。
		return nil, fmt.Errorf("不支持的 ZIP 压缩方法: %d", entry.Method)
	}
}

如果只是想读取 Deflate 条目，不要复制这段分支去手写解压；使用 File.Open 更稳妥。只有在做原始归档复制、压缩层分析或需要接入自定义处理链时，OpenRaw 才值得出现。

我会特别留意的几个边界

1. 未知 Method 不等于未知文件格式。它表示压缩算法编号未知。标准库内置 Store 与 Deflate，也支持通过 Reader.RegisterDecompressor 注册自定义解压器。
2. 不要用 32 位尺寸字段做大文件判断。FileHeader 同时提供 32 位和 64 位尺寸，ZIP64 条目应优先看 CompressedSize64 与 UncompressedSize64。
3. 不要把读到 EOF 当作唯一成功信号。File.Open 的读取过程还承担校验，读取错误要保留，不能只检查已经读出了多少字节。
4. 条目资源也要关闭。entry.Open() 返回的是 io.ReadCloser，循环读取大量条目时，延迟到整个函数末尾再关闭可能造成资源积压。

这套判断适合谁

如果你是在做 ZIP 导入、文件预览、归档扫描或解包服务，记住“Method 是压缩方法，Open 是正常内容入口”就足够覆盖大多数场景。若你在实现归档转发、原始数据备份或自定义压缩算法接入，再把 OpenRaw 和 RegisterDecompressor 纳入设计。

对我来说，最实用的改动不是多写一个压缩判断，而是把统一读取入口固定成 Open，把 Method 只用于日志、策略和异常解释。这样 Store、Deflate 和未来接入的自定义方法不会把业务解析层搅在一起。

相关问题

FileHeader.Method 为 0 是不是文件为空？

不是。0 表示 Store，即不压缩；条目仍然可以有正常内容，也可以是空文件。

为什么不直接读取 File 的字段判断文件类型？

因为 ZIP 条目只描述归档层信息。JSON、图片等内部格式需要根据内容或文件名处理，不能由压缩方法推断。

什么时候必须使用 OpenRaw？

当你明确需要归档里保存的原始压缩字节，并准备自行处理对应 Method 时使用。普通内容读取优先使用 Open。