Go archive/zip.File.OpenRaw 怎样读取压缩条目的原始数据

在 Go 的 archive/zip 包里，File.OpenRaw() 读取的不是解压后的文件正文，而是 ZIP 条目中保存的原始数据。条目使用 Deflate 时，返回值就是压缩字节；使用 Store 时，原始字节才与未压缩内容相同。

官方地址：https://pkg.go.dev/archive/zip#File.OpenRaw

这意味着 OpenRaw 适合做原样转存、压缩数据分析和条目复制，不适合直接把结果当成普通文本或 JSON 去解析。下面按“读取语义、条目元数据、保存原始流、原样复制”四个部分说明。

先分清 Open 和 OpenRaw 读到的是什么

File.Open() 返回 io.ReadCloser，会透明解压并校验内容；File.OpenRaw() 返回 io.Reader，不做解压。两者面对同一个条目时，读取结果可能完全不同。

还有一个容易忽略的差别：Open 返回的对象需要关闭，OpenRaw 返回的是读取器接口，本身没有关闭方法。但外层的 zip.ReadCloser 仍然要关闭；不能因为原始读取器没有 Close 就省略归档关闭。

先看 FileHeader 里的方法和大小

每个 *zip.File 都嵌入了 FileHeader。其中 Method 表示压缩方法，CompressedSize64 表示压缩后大小，UncompressedSize64 表示解压后大小。读取原始字节时，前者是更直接的容量参考。

package main

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

func main() {
	r, err := zip.OpenReader("assets.zip")
	if err != nil {
		log.Fatal(err)
	}
	defer r.Close() // 释放归档文件；OpenRaw 本身没有 Close 方法

	for _, f := range r.File {
		fmt.Printf("%s method=%d compressed=%d uncompressed=%d\n",
			f.Name, f.Method, f.CompressedSize64, f.UncompressedSize64)
	}
}

不要用文件名后缀推断数据是否压缩，也不要把 CompressedSize64 当作解压后长度。条目可能使用 Store，也可能使用 Deflate；真正的判断入口是 FileHeader.Method 和调用方法。

用 OpenRaw 保存某个条目的原始数据

下面的示例按条目名查找目标文件，再把 OpenRaw 返回的字节流保存到独立文件。示例不解析原始数据，因为 Deflate 条目保存的内容不是可直接阅读的正文。

package main

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

func saveRaw(zipPath, entryName, outputPath string) error {
	r, err := zip.OpenReader(zipPath)
	if err != nil {
		return fmt.Errorf("打开 ZIP 失败: %w", err)
	}
	defer r.Close() // 归档句柄由外层统一释放

	var target *zip.File
	for _, f := range r.File {
		if f.Name == entryName {
			target = f
			break
		}
	}
	if target == nil {
		return fmt.Errorf("找不到条目 %q", entryName)
	}

	raw, err := target.OpenRaw()
	if err != nil {
		return fmt.Errorf("打开原始数据失败: %w", err)
	}
	out, err := os.Create(outputPath)
	if err != nil {
		return fmt.Errorf("创建输出文件失败: %w", err)
	}
	defer out.Close() // 关闭输出文件并把关闭错误留给调用方按需处理

	if _, err := io.Copy(out, raw); err != nil {
		return fmt.Errorf("保存原始数据失败: %w", err)
	}
	return nil
}

func main() {
	if err := saveRaw("assets.zip", "data/config.json", "config.json.raw"); err != nil {
		log.Fatal(err)
	}
}

这段代码得到的是归档内的原始数据副本。若目标条目是 Deflate，config.json.raw 仍然是压缩流；要得到 JSON 文本，应改用 target.Open()，再把返回的 io.ReadCloser 交给 JSON 解码器。

原样复制条目时优先使用 Writer.Copy

如果任务不是“把原始字节单独拿出来”，而是把一个 ZIP 条目完整复制到另一个 ZIP，优先考虑 zip.Writer.Copy。官方文档说明它会绕过解压、重新压缩和校验，直接复制条目的原始形式。

package main

import (
	"archive/zip"
	"fmt"
	"log"
	"os"
)

func copyEntry(srcPath, dstPath, entryName string) error {
	src, err := zip.OpenReader(srcPath)
	if err != nil {
		return fmt.Errorf("打开源 ZIP 失败: %w", err)
	}
	defer src.Close() // 源归档只负责读取，结束后及时关闭

	srcFile, err := findFile(src.File, entryName)
	if err != nil {
		return err
	}

	dst, err := os.Create(dstPath)
	if err != nil {
		return fmt.Errorf("创建目标 ZIP 失败: %w", err)
	}
	defer dst.Close() // 先关闭文件，再由 Writer.Close 写入中央目录

	w := zip.NewWriter(dst)
	if err := w.Copy(srcFile); err != nil {
		return fmt.Errorf("复制条目失败: %w", err)
	}
	if err := w.Close(); err != nil {
		return fmt.Errorf("写入目标 ZIP 失败: %w", err)
	}
	return nil
}

func findFile(files []*zip.File, name string) (*zip.File, error) {
	for _, f := range files {
		if f.Name == name {
			return f, nil
		}
	}
	return nil, fmt.Errorf("找不到条目 %q", name)
}

func main() {
	if err := copyEntry("assets.zip", "backup.zip", "data/config.json"); err != nil {
		log.Fatal(err)
	}
}

Writer.Copy 能同时保留条目的头信息与原始数据，通常比手动组合 OpenRaw、CreateRaw 更不容易把压缩方法、大小或偏移关系弄错。只有在需要读取、变换或审计原始字节时，才直接使用 OpenRaw。

OpenRaw 的边界怎么判断

• 要解析业务内容：使用 Open，因为你需要解压后的字节。
• 要保留压缩形态：使用 OpenRaw，并把输出视为不透明字节流。
• 要把条目复制到另一个 ZIP：优先使用 Writer.Copy，让标准库保留原始形式。
• 要关闭资源：始终关闭 zip.ReadCloser；使用 Open 时额外关闭返回的 io.ReadCloser。
• 要依赖校验和：不要把 OpenRaw 当成校验入口；原始读取路径不会替你完成解压后的内容校验。

一句话总结：OpenRaw 解决的是“拿到 ZIP 里实际存放的那段数据”，Open 解决的是“拿到用户看到的文件内容”。先确定数据层，再选择 API，才不会把压缩流误传给文本解析器。

相关问题

OpenRaw 返回值为什么不是 ReadCloser？

因为它暴露的是归档内的原始读取视图，不负责解压器资源。真正需要关闭的是外层归档；如果使用 Open，则还要关闭解压读取器。

Store 条目也能使用 OpenRaw 吗？

可以。Store 表示不压缩，原始数据通常就是条目正文，但代码仍应依据 Method 和调用目的选择 API。

为什么复制 ZIP 条目不直接 io.Copy(OpenRaw)？

只复制字节还不够，目标 ZIP 还需要与原始数据匹配的条目头信息。完整复制时使用 Writer.Copy 更稳妥。