Go x/image/riff ChunkID 怎样筛选 WAVE 数据块

用 Go 读取 WAVE 文件时，真正用于筛选数据块的不是一个名为 ChunkID 的独立类型，而是 riff.Reader.Next 返回的 FourCC 值。最小做法是先用 riff.NewReader 确认根类型为 WAVE，然后循环调用 Next，把返回的 chunkID 与 riff.FourCC{'d', 'a', 't', 'a'} 或 riff.FourCC{'f', 'm', 't', ' '} 比较。

官方文档：https://pkg.go.dev/golang.org/x/image/riff

筛选 WAVE 数据块的关键是把“根类型检查”和“块 ID 比较”分成两层：formType 只判断这是不是 WAVE，chunkID 才决定当前块是 fmt 、data 还是其它块。拿到不需要的块后，先把它的 chunkData 消费掉，再读取下一块，避免把当前块的边界问题带进后续判断。

先分清 WAVE 根类型和 ChunkID

RIFF 流由一系列块组成，每个块都有 4 字节类型、4 字节长度、数据和必要的填充。golang.org/x/image/riff 用 FourCC 表示四字符代码，用 Reader 从底层 io.Reader 读取这些块。

NewReader 返回两个核心值：formType 是 RIFF 根类型，WAVE 文件通常是 WAVE；返回的 *riff.Reader 则负责继续读取块。之后每次 Next 返回 chunkID、chunkLen 和 chunkData。因此标题里说的 ChunkID，在代码中应理解为这个返回的 FourCC。

用 NewReader 先保护输入边界

不要一进入循环就假设输入是 WAVE。先判断 formType，可以把“不是 RIFF”“RIFF 根类型不是 WAVE”和“块读取失败”分开处理。下面的函数只负责找 data 块，并把目标块复制到内存；示例没有把未知块当作目标数据。

package wave

import (
    "fmt"
    "io"

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

var (
    // FourCC 必须保留 WAVE 块 ID 的第四个空格。
    fmtChunk  = riff.FourCC{'f', 'm', 't', ' '}
    dataChunk = riff.FourCC{'d', 'a', 't', 'a'}
)

// ReadDataChunk 只接受 WAVE，并返回第一个 data 块的内容。
func ReadDataChunk(src io.Reader) ([]byte, error) {
    formType, chunks, err := riff.NewReader(src)
    if err != nil {
        return nil, fmt.Errorf("读取 RIFF 头失败: %w", err)
    }
    if formType != (riff.FourCC{'W', 'A', 'V', 'E'}) {
        return nil, fmt.Errorf("不支持的 RIFF 根类型: %s", formType)
    }

    for {
        chunkID, chunkLen, chunkData, err := chunks.Next()
        if err == io.EOF {
            return nil, fmt.Errorf("WAVE 中没有 data 块")
        }
        if err != nil {
            return nil, fmt.Errorf("读取块 %s 失败: %w", chunkID, err)
        }

        switch chunkID {
        case fmtChunk:
            // fmt 只做识别示例；不需要时仍要消费当前数据流。
            if _, err := io.Copy(io.Discard, chunkData); err != nil {
                return nil, fmt.Errorf("跳过 fmt 块失败: %w", err)
            }
        case dataChunk:
            // chunkLen 来自块头，读取前可按业务上限拒绝过大的输入。
            if chunkLen > 64

这里的比较有两个容易遗漏的细节：fmt 的最后一位是空格，不能写成三个字符；WAVE 是根类型，不应拿它和块 ID 混在同一层判断。

用 ChunkID 筛选目标块，而不是猜块顺序

WAVE 中常见 fmt 和 data，但扩展块、列表块或应用自定义块可能出现在它们之间。可靠的筛选方式是比较 chunkID，而不是假定“第二块一定是 data”。

如果只想读取 fmt 的头部，可以在匹配后按格式定义读取有限字节；如果要读取音频负载，则匹配 data 后再决定是流式处理还是按上限读取。对 LIST 这类嵌套块，应根据文档调用 riff.NewListReader，不要把它的内容直接当成普通音频采样数据。

为什么跳过块也要消费 chunkData

官方文档明确说明：Next 返回的 io.Reader 在下一次调用 Next 后会失效；即使前一个块的数据还没有读完，也可以调用下一次 Next。这让调用者拥有跳过能力，但也意味着不应继续使用旧的 chunkData，更不能把它保存到循环外异步读取。

工程上可以把“跳过当前块”统一写成 io.Copy(io.Discard, chunkData)，这样审计时很容易看出边界已经被消费。若业务只读取目标块，遇到未知块仍要处理复制错误；输入截断、长度异常或底层读取错误都应保留，而不是悄悄当作正常结束。

对于不可信的大文件，chunkLen 不等于必须一次性分配的内存大小。可以采用业务上限、io.LimitReader 或直接把 chunkData 交给流式解码器。上限应由业务决定，不能把示例中的 64 MiB 当作所有 WAVE 的标准限制。

把筛选逻辑当成输入安全边界

这不是把普通音频文件当攻击样本，而是提醒代码审查时把 RIFF 的可变长度字段当作外部输入。安全威胁建模可以落到四个资产：容器类型判断、块边界、读取内存、错误日志。对应的风险控制如下：

发布前可以快速复查的清单

• 是否检查了 NewReader 返回的 formType，而不是只看文件扩展名？
• 是否用带空格的 fmt 和准确的 data FourCC 比较？
• 是否允许扩展块出现在目标块前面，而不是依赖固定顺序？
• 跳过未知块时，是否消费了当前 chunkData 并保留了复制错误？
• 是否对外部 chunkLen 设定了业务上限，避免无界内存增长？
• 是否在下一次 Next 后停止使用旧的 chunkData？

归纳起来，ChunkID 筛选 WAVE 数据块就是一条清晰的边界链：formType 先确认容器，chunkID 再确认块，chunkLen 约束读取规模，chunkData 只在当前块生命周期内使用。按这四层写代码，既能覆盖扩展块，也能让错误处理和安全审查有明确落点。

相关问题

为什么 fmt 后面必须有空格？

FourCC 固定为四字节，WAVE 的格式块 ID 是三个字母加一个空格。少写一个空格会导致比较永远不匹配。

chunkData 能否保存起来稍后再读？

不建议。文档说明下一次 Next 后前一个数据流会失效；需要延后处理时，应在当前块生命周期内复制到自己的缓冲或交给自己的流式处理器。

遇到 LIST 应该怎样处理？

先把它识别为列表块，再按 riff.NewListReader 读取列表类型与子块；不要把列表块直接当成 data 音频负载。