Go archive/zip 怎样读取自定义压缩方法

Go 的 archive/zip 内置支持 Store 和 Deflate。遇到使用其他方法编号的 ZIP 条目时，直接调用 file.Open() 可能得到 zip.ErrAlgorithm。解决办法不是改文件名，而是先把项目已有的解压器适配成 zip.Decompressor，再在当前 *zip.Reader 上调用 RegisterDecompressor。

先分清内置方法和自定义方法

ZIP 条目在文件头里带有压缩方法编号。archive/zip 已经为 zip.Store 和 zip.Deflate 提供内置实现，其他编号则要由调用方登记解压器。这个登记动作只解决“根据编号找到谁来读”，不会替项目实现压缩算法。

因此排查时先看条目的方法编号，再决定是否需要注册。没有对应解压器时，Open 阶段会落到 zip.ErrAlgorithm；这和 ZIP 文件损坏、校验和错误不是同一类问题。

把项目解压器适配为 Decompressor

官方定义的 zip.Decompressor 是一个函数类型：输入压缩数据流，输出 io.ReadCloser。下面的 newProjectDecoder 代表项目已有的解压实现，文章只展示适配边界，不把某种第三方压缩算法写死在 ZIP 读取层。

package zipsource

import (
    "io"
    "archive/zip"
)

const projectMethod uint16 = 0xCAFE

// newProjectDecoder 由项目的压缩库提供：输入压缩流，返回可读取并可关闭的解压流。
func newProjectDecoder(src io.Reader) (io.ReadCloser, error)

// projectDecompressor 把项目解压器转换成 zip.Decompressor 所需的函数形状。
func projectDecompressor(src io.Reader) io.ReadCloser {
    reader, err := newProjectDecoder(src)
    if err != nil {
        // 中文说明：Decompressor 本身不能返回 error，用一个会返回错误的读取器传递初始化失败。
        return errorReadCloser{err: err}
    }
    return reader
}

type errorReadCloser struct{ err error }

func (e errorReadCloser) Read([]byte) (int, error) { return 0, e.err }

func (e errorReadCloser) Close() error {
    // 中文说明：初始化失败时没有底层资源，关闭动作保持幂等的空操作。
    return nil
}

var _ zip.Decompressor = projectDecompressor

这里特意把初始化错误转成读取阶段错误，是因为 zip.Decompressor 的函数签名没有错误返回值。如果项目解压器能延迟初始化，也可以在第一次 Read 时返回具体错误；关键是不能静默返回空数据。

在 Reader 实例上注册方法编号

拿到 *zip.Reader 后，调用它的 RegisterDecompressor，再去打开条目。注册只影响这一个 Reader，适合把不同来源、不同协议的压缩方法隔离开。

func openProjectEntry(r *zip.Reader, name string) (io.ReadCloser, error) {
    // 中文说明：方法编号必须与 ZIP 条目写入端使用的编号完全一致。
    r.RegisterDecompressor(projectMethod, projectDecompressor)

    for _, file := range r.File {
        if file.Name != name {
            continue
        }
        // 中文说明：Open 会根据条目方法编号选择内置或刚注册的解压器。
        return file.Open()
    }
    return nil, io.ErrUnexpectedEOF
}

示例把注册放在打开条目前，避免读到一半才发现方法表尚未准备好。真实项目通常会把方法注册放进创建 Reader 的工厂函数，并在同一处记录允许的编号，减少调用方漏注册的机会。

打开条目后要完整消费并关闭读取器

注册完成后，调用者不需要直接操作自定义解压器，而是继续使用 zip.File.Open 返回的 io.ReadCloser。这让 ZIP 层和具体算法解耦，也让资源回收责任保持清晰。

func readEntry(dst io.Writer, file *zip.File) error {
    reader, err := file.Open()
    if err != nil {
        // 中文说明：这里可以区分 zip.ErrAlgorithm、格式错误和其他打开失败。
        return err
    }
    defer func() {
        // 中文说明：读取器可能持有解压缓冲区或底层句柄，必须释放它。
        _ = reader.Close()
    }()

    _, err = io.Copy(dst, reader)
    return err
}

如果业务必须把关闭错误作为失败依据，就不要只用匿名 defer 丢弃它，而应使用命名返回值或显式关闭。对于只读内存流，关闭可能没有额外动作；对于真实解压实现，仍应遵守返回值契约。

选择 Reader 级注册还是全局注册

archive/zip 同时提供包级 zip.RegisterDecompressor 和 Reader 级方法。Reader 级注册更容易把方法编号限制在当前数据源，尤其适合多租户、插件或逐步迁移；包级注册则适合整个进程始终采用同一实现的场景。

无论选择哪一种注册方式，解压器本身都要满足并发约束：工厂函数可以被多个 goroutine 同时调用，但每个返回的读取器只交给一个使用者。共享可变配置时，优先在注册前完成构造，避免在 Read 路径里修改全局状态。

常见问题

注册后仍然返回 zip.ErrAlgorithm，通常看哪里？

先核对条目实际方法编号和注册时的 uint16 是否一致，再确认注册发生在同一个 *zip.Reader 上，并且早于 File.Open。

Decompressor 为什么不能直接返回 error？

它的函数类型只返回 io.ReadCloser。初始化错误需要通过返回一个在 Read 时报告错误的读取器传递，或者由项目适配层预先完成不会失败的构造。

Reader 级注册会影响其他 ZIP Reader 吗？

不会。Reader 级方法把注册关系放在当前 Reader 上；如果改用包级注册，影响范围就会上升到同一进程中的其他调用方。

file.Open 返回的读取器一定要 Close 吗？

应当关闭。调用方不需要猜测底层实现是否持有资源，统一按 io.ReadCloser 生命周期处理最稳妥。