Go zip.File.OpenRaw 怎么读取原始压缩数据

zip.File.OpenRaw 用来读取 ZIP 条目未经解压的原始数据。它返回 io.Reader，读出的字节仍按该条目的 Method 编码：zip.Deflate 条目得到的是原始 DEFLATE 数据，zip.Store 条目因为本来不压缩，原始字节才与普通文件内容相同。最直接的写法是调用 OpenRaw 后用 io.Copy 流式写到目标，并用 CompressedSize64 核对读取长度。

官方文档：https://pkg.go.dev/archive/zip

我为什么会需要原始压缩数据

我第一次用到 OpenRaw，不是为了“更快解压”，而是要把一个大 ZIP 中的部分条目转存到内容缓存：缓存需要保存压缩后的载荷，后续再按原压缩方式装回新的 ZIP。如果用普通的 File.Open，数据会先解压；写进新 ZIP 时又要重新压缩，既增加 CPU 消耗，也无法保留原来的压缩字节。

这类场景的共同点是：目标对象就是压缩数据本身，例如计算压缩载荷的哈希、保存原始 DEFLATE 流、分析压缩大小，或者在不改内容的前提下重组 ZIP。若只是读取 JSON、图片或文本的真实内容，仍应优先使用 File.Open。

OpenRaw 返回的到底是什么

官方文档对 OpenRaw 的定义很简洁：返回一个可访问条目内容、但不做解压的 io.Reader。这里的“内容”指 ZIP 条目的数据区载荷，不包括本地文件头、数据描述符和中央目录。返回值也只是 io.Reader，调用方不需要关闭它；真正持有底层 ZIP 文件的是 zip.ReadCloser，它仍要在用完后关闭。

FileHeader.Method 告诉你数据采用哪种压缩方法，CompressedSize64 给出压缩后长度，UncompressedSize64 则是解压后的长度。处理 ZIP64 时应使用这两个 64 位字段，不要依赖已经标为废弃的 32 位大小字段。

最小写法：把一个条目的原始字节流式写出

下面的函数按条目名查找文件，再把原始压缩字节写入指定 io.Writer。它不把整段数据读入内存，适合大条目。为了避免把目录项当普通文件处理，示例会跳过名称以斜杠结尾的目录。

package rawzip

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

func CopyRawEntry(zr *zip.Reader, name string, dst io.Writer) error {
	for _, f := range zr.File {
		if f.Name != name || strings.HasSuffix(f.Name, "/") {
			continue // 只处理目标文件条目，跳过目录
		}

		raw, err := f.OpenRaw()
		if err != nil {
			return fmt.Errorf("打开原始压缩数据 %q: %w", name, err)
		}

		n, err := io.Copy(dst, raw) // 流式复制，避免一次性分配大缓冲区
		if err != nil {
			return fmt.Errorf("复制原始压缩数据 %q: %w", name, err)
		}
		if uint64(n) != f.CompressedSize64 {
			return fmt.Errorf("压缩长度不符：读取=%d，头部=%d", n, f.CompressedSize64)
		}

		return nil
	}

	return fmt.Errorf("ZIP 中没有条目 %q", name)
}

长度核对能发现截断读取或错误的上游包装，但它不等于内容完整性校验。OpenRaw 不解压，也不会像 File.Open 的读取路径那样透明验证解压内容的校验和。如果业务必须确认条目内容有效，应使用 Open 读到 EOF，或在理解格式的前提下自行完成解压与 CRC 校验。

Store 与 Deflate 的差异

最容易误判的地方，是把 OpenRaw 的返回值当成“文件原文”。是否相同取决于压缩方法。

尤其要注意：ZIP 中的 Deflate 条目通常是原始 DEFLATE 流，不是完整的 gzip 文件，也不是带 zlib 头尾的通用流。若你的目标只是获取解压后的内容，不要自己猜包装格式，直接使用 f.Open() 最稳妥。

四种方案怎么选

我后来把选择规则压缩成一句话：先确定最终需要的对象，再选接口。需要普通文件内容就用 Open；需要压缩载荷就用 OpenRaw；要把整个条目原样放进另一个 ZIP，优先用 Writer.Copy；只有在必须用底层 ReaderAt 定位数据区时才考虑 DataOffset。

重组 ZIP：优先使用 Writer.Copy

如果目的只是把源 ZIP 的条目复制到目标 ZIP，Writer.Copy 比手动 OpenRaw + CreateRaw 更直接。官方文档明确说明，它会复制条目的原始形态，绕过解压、重新压缩和验证。

func CopySelected(srcPath, dstPath string, keep map[string]bool) (err error) {
	src, err := zip.OpenReader(srcPath)
	if err != nil {
		return fmt.Errorf("打开源 ZIP: %w", err)
	}
	defer src.Close() // 释放源文件句柄

	dst, err := os.Create(dstPath)
	if err != nil {
		return fmt.Errorf("创建目标 ZIP: %w", err)
	}
	defer func() {
		if closeErr := dst.Close(); err == nil {
			err = closeErr // 保留关闭目标文件时的错误
		}
	}()

	zw := zip.NewWriter(dst)
	defer func() {
		if closeErr := zw.Close(); err == nil {
			err = closeErr // 写入中央目录后才算完整 ZIP
		}
	}()

	for _, f := range src.File {
		if !keep[f.Name] {
			continue
		}
		if err := zw.Copy(f); err != nil {
			return fmt.Errorf("复制条目 %q: %w", f.Name, err)
		}
	}

	return nil
}

Writer.Copy 的代价同样来自“原样”：它不会替你重新验证内容。如果源 ZIP 不可信，而业务要求验证每个条目，应先用 Open 完整读取并验证，再按目标策略重新写入。省掉解压和重压缩适合可信输入、归档拆分和结构重组，不适合把验证步骤悄悄省略。

什么时候手动使用 CreateRaw

当你已经拿到原始压缩流，但需要调整条目名称或可控地构造目标头部时，可以使用 CreateRaw。传给它的数据不会再次压缩，所以 FileHeader 中的 Method、CRC32、压缩前后大小必须与原始流匹配。先复制一份头部值，再修改必要字段，可以避免让目标 Writer 长期引用源对象的嵌入头部。

func CopyRawAs(zw *zip.Writer, src *zip.File, newName string) error {
	raw, err := src.OpenRaw()
	if err != nil {
		return fmt.Errorf("打开原始数据: %w", err)
	}

	header := src.FileHeader // 复制头部值，保留 Method、CRC32 和大小
	header.Name = newName    // 只修改目标条目名

	dst, err := zw.CreateRaw(&header)
	if err != nil {
		return fmt.Errorf("创建原始条目: %w", err)
	}

	n, err := io.Copy(dst, raw) // 写入已压缩字节，不会二次压缩
	if err != nil {
		return fmt.Errorf("写入原始条目: %w", err)
	}
	if uint64(n) != header.CompressedSize64 {
		return fmt.Errorf("原始数据长度不符：%d", n)
	}

	return nil
}

如果只是无修改复制，仍优先 Writer.Copy，因为它表达的意图更直接，也减少调用方手动维护头部一致性的机会。

不适用情况与安全边界

• 要解析文本、JSON 或图片：使用 File.Open，不要把压缩字节交给普通解析器。
• 要验证文件内容：读取解压流到 EOF，让标准库完成正常解压路径；OpenRaw 本身不替你做内容验证。
• 输入 ZIP 不可信：复制原始形态会保留源条目的问题。必要时先验证再重写。
• 把条目名写到磁盘：不要直接拼接 f.Name；应独立检查路径是否为本地、安全且落在目标目录内。
• 只想复制 ZIP 条目：优先 Writer.Copy，不要先导出原始流再绕一圈。
• 需要随机访问底层数据区：再考虑 DataOffset，并用 CompressedSize64 限定读取范围。

常见问题

OpenRaw 返回的数据需要 Close 吗？

返回类型是 io.Reader，没有单独的 Close。通过 zip.OpenReader 打开的底层 ZIP 文件仍要关闭，并且应保证在读取原始流期间它保持可用。

可以用 io.ReadAll 读取吗？

可以，但会按压缩后大小一次性占用内存。小条目调试时可用；生产代码处理未知或大条目时，优先用 io.Copy 流式写入。

为什么 OpenRaw 后的字节不能直接用 flate.NewReader 之外的 gzip.Reader？

ZIP 的 Deflate 条目保存的是原始 DEFLATE 数据，不是带 gzip 文件头和尾部的 gzip 格式。若只想要文件内容，直接调用 File.Open，避免手动匹配包装层。

OpenRaw 会返回 ZIP 本地文件头吗？

不会。它返回条目数据载荷。需要底层位置时可查看 DataOffset，但本地文件头、数据区和目录结构应按不同对象处理。

对我来说，OpenRaw 最有价值的地方不是“比 Open 更高级”，而是让压缩载荷成为一个可直接流式处理的对象。只要先明确最终要的是普通内容、原始压缩流、目标 ZIP 条目还是底层偏移，这几个 API 的选择就很清楚。