Go x/image/riff NewReader 怎样识别 RIFF 表单类型

如果你要从一个 io.Reader 判断 RIFF 流属于 AVI、WAVE 还是其他表单，直接调用 riff.NewReader：它先读取并确认前四个字节是 RIFF，再读取 RIFF 块中的四字节 form type，最后返回一个可以继续读取 chunk 的 *riff.Reader。因此，form type 是容器用途标识，不是文件扩展名，也不是后续每个 chunk 的 ID。

官方文档入口：https://pkg.go.dev/golang.org/x/image/riff。下面按“确认输入边界、识别 form type、选择分支、消费 chunk、封装入口”的顺序展开；文章只讨论 RIFF 结构读取，不把 x/image/riff 当成完整的 AVI、WAVE 或 WEBP 解码器。

最小可用判断是：formType, reader, err := riff.NewReader(src)。先处理 err，再按四字节 formType 选择业务分支，最后通过返回的 reader.Next() 读取 chunk；不要把 form type 和 chunk ID 混在一个判断里。

先分清 RIFF 标识、form type 与 chunk ID

RIFF 流的开头可以理解为一个容器头：四个字节的 RIFF 说明这是 RIFF 数据，接着是四字节长度字段，再接着是 form type，例如 AVI 或 WAVE。进入数据区后，每个 chunk 又有自己的四字节 chunk ID、四字节长度和数据。

这三个标识承担不同职责：

官方包把 RIFF 流描述为一组 chunk；每个 chunk 的头部包含四字节类型和四字节长度，数据通过 io.Reader 暴露。这个设计让调用方可以先知道块类型和长度，再决定读取、跳过或递归处理。

让 NewReader 从流头返回 form type

NewReader 接收任意 io.Reader，所以文件、网络响应体或内存缓冲区都可以作为输入。实现会先读取八字节头：前四字节必须是 RIFF，后四字节按小端序解释为 RIFF 块长度，然后把后续数据交给内部的 LIST 读取逻辑。LIST 读取逻辑再取出前四字节，作为返回的 form type。

这意味着短输入和非 RIFF 输入应该在入口处失败，而不是等到遍历 chunk 时才猜测失败原因。form type 是 [4]byte 形式的 riff.FourCC；比较时要把它当成四字节代码，保留像 AVI 末尾空格这样的实际字节。

package main

import (
    "fmt"
    "io"

    "golang.org/x/image/riff"
)

// readFormType 只负责识别 RIFF 的整体表单，不读取具体 chunk 内容。
func readFormType(src io.Reader) (riff.FourCC, *riff.Reader, error) {
    // NewReader 会检查 RIFF 头，并把 form type 交给调用方。
    formType, chunks, err := riff.NewReader(src)
    if err != nil {
        return riff.FourCC{}, nil, fmt.Errorf("读取 RIFF 头失败: %w", err)
    }

    // WAVE 是四字节代码；比较时不要把它当成文件扩展名。
    if formType == (riff.FourCC{'W', 'A', 'V', 'E'}) {
        fmt.Println("识别到 WAVE 表单")
    }
    return formType, chunks, nil
}

这个函数没有把整个输入读进内存，也没有根据文件名判断格式。对于 bytes.Reader、os.File 或 HTTP body，只要它们满足 io.Reader，都可以沿用同一个入口。注意：代码中的输出只是分支示意，不表示本文已经运行了某个本地样本。

根据 form type 选择后续解析分支

识别 form type 后，业务层才知道后续应采用哪种 chunk 解释规则。比如 WAVE 表示音频容器，AVI 表示视频容器；两者都使用 RIFF 的外层组织方式，但内部 chunk 的语义并不相同。不要因为都能调用 Next，就把一个表单中的 chunk ID 解释成另一个表单的字段。

// dispatchForm 根据整体表单选择专用解析器。
func dispatchForm(formType riff.FourCC, chunks *riff.Reader) error {
    switch formType {
    case riff.FourCC{'W', 'A', 'V', 'E'}:
        // WAVE 分支只交给 WAVE 语义层处理，避免跨表单猜字段。
        return readWaveChunks(chunks)
    case riff.FourCC{'A', 'V', 'I', ' '}:
        // AVI 的末尾空格也是 FourCC 的一部分，不能省略。
        return readAVIChunks(chunks)
    default:
        // 未知表单仍可由通用层列出 chunk，但不应伪装成已知格式。
        return fmt.Errorf("不支持的 RIFF form type: %q", formType)
    }
}

// 这两个函数代表业务解析层；具体实现应按对应表单规范解释 chunk。
func readWaveChunks(*riff.Reader) error { return nil }
func readAVIChunks(*riff.Reader) error  { return nil }

这里的核心是边界分工：NewReader 只帮你识别 RIFF 外层并创建 chunk reader，不替你判断业务是否支持某个 form type。未知类型可以选择列出通用 chunk，也可以明确返回“不支持”；关键是不要静默套用错误的表单规则。

用 Reader.Next 消费 chunk 并处理边界

返回的 *riff.Reader 通过 Next 给出 chunkID、chunkLen、chunkData 和错误。没有更多 chunk 时，错误是 io.EOF；其他错误则表示头部不足、数据不足、长度越界或 padding 缺失等输入问题。

还有一个容易忽略的约束：下一次调用 Next 后，前一次返回的 chunkData 会失效。实现会在进入下一块前自动排空上一块尚未读取的数据，所以调用方不应把旧 reader 保存到下一轮继续使用。

package riffscan

import (
    "fmt"
    "io"

    "golang.org/x/image/riff"
)

// scanChunks 只展示通用 chunk 扫描，不解释具体表单字段。
func scanChunks(reader *riff.Reader) error {
    for {
        chunkID, chunkLen, chunkData, err := reader.Next()
        if err == io.EOF {
            // EOF 表示当前 RIFF 数据区正常遍历结束。
            return nil
        }
        if err != nil {
            return fmt.Errorf("读取 chunk 头失败: %w", err)
        }

        // 业务只需要元数据时可以先记录 ID 和长度，再按需读取数据。
        fmt.Printf("chunk=%q length=%d\n", chunkID, chunkLen)
        if _, err := io.Copy(io.Discard, chunkData); err != nil {
            return fmt.Errorf("读取 chunk %q 失败: %w", chunkID, err)
        }
    }
}

示例主动消费了 chunkData，这样下一轮 Next 的行为更直观。官方实现即使发现上一块没有读完，也会尝试排空；但显式消费便于控制错误发生的位置，也避免把大块数据误读进内存。奇数长度 chunk 还会占用一个 padding 字节，这属于 RIFF 对齐规则，不应把它当成下一块的头部。

把流式读取封装成可复用入口

在项目里可以把 form type 和通用扫描拆开：第一层只负责建立 RIFF reader，第二层负责支持矩阵，第三层才解释具体 chunk。这样文件输入、网络输入和测试缓冲区都共用同一套边界处理。

package riffscan

import (
    "fmt"
    "io"

    "golang.org/x/image/riff"
)

// Inspect 识别 RIFF 表单并返回每个 chunk 的 ID 与长度。
func Inspect(src io.Reader) (riff.FourCC, []ChunkInfo, error) {
    formType, reader, err := riff.NewReader(src)
    if err != nil {
        return riff.FourCC{}, nil, fmt.Errorf("建立 RIFF reader 失败: %w", err)
    }

    var result []ChunkInfo
    for {
        id, length, data, err := reader.Next()
        if err == io.EOF {
            return formType, result, nil
        }
        if err != nil {
            return riff.FourCC{}, nil, fmt.Errorf("扫描 form %q 失败: %w", formType, err)
        }
        // 只保留索引信息，及时消费数据，避免把 chunk 全部缓存到内存。
        if _, err := io.Copy(io.Discard, data); err != nil {
            return riff.FourCC{}, nil, fmt.Errorf("消费 chunk %q 失败: %w", id, err)
        }
        result = append(result, ChunkInfo{ID: id, Length: length})
    }
}

// ChunkInfo 是通用索引，不代表任何具体表单字段。
type ChunkInfo struct {
    ID     riff.FourCC
    Length uint32
}

封装时要保留错误上下文，但不要把未知 form type 当成格式损坏；“能读 RIFF 外层”和“业务支持该表单”是两件事。若上层需要读取 chunk 内容，应在当前 Next 返回后完成，或复制到自己的缓冲区后再进入下一轮。

常见误区与速查表

NewReader 会自动解析 WAVE 字段吗？不会。它只返回 form type 和通用 chunk reader，WAVE 字段仍要由上层按 WAVE 规则解释。

为什么 form type 里有空格？FourCC 固定四字节，像 AVI 的末尾空格就是实际组成部分，比较时不能裁剪。

能不能用 NewReader 判断任意二进制文件？不能。它只接受符合 RIFF 头部约定的输入；非 RIFF 或头部不完整时应按错误处理。

把任务拆开后，识别 RIFF 表单并不复杂：NewReader 负责外层头和 form type，Reader.Next 负责 chunk 边界，业务解析器负责具体表单语义。只要坚持这三层分工，就能在文件、网络流和测试输入之间复用同一套读取流程。