Go oggvorbis 怎样从Vorbis注释中读取曲目信息

Go 的 oggvorbis 可以通过 GetCommentHeader(io.Reader) 读取 Vorbis 注释头，再从返回的 Comments []string 中提取 TITLE、ARTIST、ALBUM 等字段。若已经创建了播放器使用的 Reader，则直接调用它的 CommentHeader()。注释不是现成的单值字典，字段名大小写不敏感，同一字段也可以出现多次。

项目官方仓库：https://github.com/jfreymuth/oggvorbis

下文按 oggvorbis v1.0.5 的接口和源码说明，不宣称这是最新版本；业务解析代码为原创示例，未作为本机运行结果展示。

我会先区分标签扫描和音频播放

如果要为一批 Ogg/Vorbis 文件制作曲库列表，我会先把“读取标题作者”和“解码整段音频”拆开考虑。列表只需要文本标签，不必为了获得曲名而调用 ReadAll，把全部 PCM 样本留在内存。这里讨论的是任务选择，不是吞吐量测试，也没有实际性能测量结论。

v1.0.5 的 GetCommentHeader 在内部读取前两个 Vorbis 头包；NewReader 除了读取三个头包，还会初始化音频缓冲。因此二者的用途和输入消耗不能混为一谈。若 Reader 已经创建成功，就使用它携带的注释，不要从当前文件偏移再构造一个注释读取过程。

把注释保留为可重复的字段集合

返回的 vorbis.CommentHeader 包含 Vendor 和 Comments 两个字段。Vendor 描述编码器厂商信息，不能当作歌手名；Comments 才是需要按字段解析的原始字符串列表。我的存储选择会是 map[string][]string，而不是会覆盖重复值的 map[string]string。

例如原创示意条目 TITLE=雨窗练习、ARTIST=独奏者甲 和 artist=协作者乙，应形成一个标题值和两个 ARTIST 值。字段名统一为大写只是应用内部索引约定，不应该顺手把中文标题、作者名或其他字段值一起改写。

拆分时只认第一个等号。像 DESCRIPTION=take=alternate，值应保留为 take=alternate。规范规定字段值使用 UTF-8，字段名限定在特定 ASCII 范围内且不区分大小写；重复字段是允许的。不要用不带限制的字符串分割后只取第二段。

从文件读取标题、作者和专辑

下面把文件读取与字段归一封装到同一个小包中。函数保留全部能识别的键，因而不会只为 TITLE 工作；缺少等号或字段名不符合约定的条目放到 Skipped，供调用方按需求记录。它是业务层处理策略，不声称替代完整的格式检查。

package trackmeta

import (
    "fmt"
    "os"
    "strings"

    "github.com/jfreymuth/oggvorbis"
)

type Tags struct {
    Vendor  string
    Fields  map[string][]string
    Skipped []string
}

// normalize保留重复键和完整值，不把异常条目冒充正常字段。
func normalize(comments []string) (map[string][]string, []string) {
    fields := make(map[string][]string)
    var skipped []string
    for _, line := range comments {
        // 只按第一个等号拆分，后续等号仍属于值。
        i := strings.IndexByte(line, '=')
        if i  0x7d || key[j] == '=' {
                valid = false
                break
            }
        }
        if !valid {
            skipped = append(skipped, line)
            continue
        }
        key = strings.ToUpper(key)
        fields[key] = append(fields[key], value)
    }
    return fields, skipped
}

// ReadTags拥有文件句柄，只提取注释，不把音频全部读入内存。
func ReadTags(path string) (result Tags, err error) {
    f, err := os.Open(path)
    if err != nil {
        return result, fmt.Errorf("打开音频: %w", err)
    }
    defer func() {
        // 保留首要读取错误；读取成功时报告关闭错误。
        if closeErr := f.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("关闭音频: %w", closeErr)
        }
    }()
    header, err := oggvorbis.GetCommentHeader(f)
    if err != nil {
        return result, fmt.Errorf("读取Vorbis注释: %w", err)
    }
    result.Vendor = header.Vendor
    result.Fields, result.Skipped = normalize(header.Comments)
    return result, nil
}

调用方在 ReadTags(path) 返回无错误后，可以分别读取 tags.Fields["TITLE"]、tags.Fields["ARTIST"]、tags.Fields["ALBUM"] 和 tags.Fields["TRACKNUMBER"]。这些结果都是字符串切片；标题只显示一个值还是保留多个值，应由界面规则明确决定。

这个例子不自动去掉值两侧空白，也不把 TRACKNUMBER 强制转换成整数。这样的选择保留了原始文本语义；若业务另有规范，可以在展示或入库映射时实施，并保留原值便于排查。示例中的 Skipped 还可能包含用户提供的文本，日志输出应遵守应用自己的长度和隐私限制。

我不会把标签缺失当成解码失败

标准列出的常见字段并非强制要求：文件有有效的注释头，但没有 TITLE，完全可能发生。相反，GetCommentHeader 返回错误，说明这次注释提取没有成功，不能把它悄悄改成“未知标题”再当正常记录导入。

对我来说，把原始标签与展示标题分成两个字段更容易维护。例如页面为了可读性采用文件名作为标题时，不必把文件名写回 tags.Fields["TITLE"]。这样以后补录标签时，仍能区分来源，而不是猜某个标题究竟来自文件还是来自程序默认值。

接入曲库时先观察这些边界

我会优先观察解析错误数、缺失常用字段的数量、重复值保留情况和被跳过条目的数量，而不是先给出“更快”的结论。这些指标用来了解自己的资料，不能直接推断库或文件一定有问题。

读取注释后还能从同一个输入继续创建Reader吗？不要直接这样做。GetCommentHeader 会推进输入，Ogg 解析还可能缓存已读取的数据；输入当前位置并不保证适合作为另一个解析器的起点。本地文件可以重新打开，或明确回到文件起点后再创建 Reader；不可寻址的输入应事先设计读取方式。若本来就要播放，直接从已有 Reader 获取注释通常更合适。

文件扩展名是.ogg就一定适用吗？不能仅凭扩展名判断。oggvorbis 面向 Ogg/Vorbis，不是所有 Ogg 容器内容的通用解码器。注释能读取成功也不证明后续全部音频数据都完整。

标签内容可以直接拼进HTML吗？不应把外部文本当成可信 HTML。使用模板的默认转义或页面文本节点显示，不直接拼接到标签、路径或命令里。文件上传和内存额度同样需要由应用控制；本示例没有把任意大小输入的资源限制一并实现。

这套写法适合需要读取歌名、作者、专辑的简单曲库和索引服务。需要修改标签、处理复杂容器组合或保证整段音频可播放时，应另外选择对应能力，不能把注释读取接口当作全功能音频管理方案。

参考资料：oggvorbis接口文档；v1.0.5辅助函数源码；v1.0.5 Reader源码；CommentHeader数据类型；Xiph Vorbis注释规范。