一个 BOM 引发的字幕转换 Bug
Fixing a bug with byte order marks
最近在整理本地媒体库时，我决定将 SRT 字幕统一转换为 WebVTT 格式以便在 HTML5 视频元素中播放。起初以为转换很简单，结果却踩进了 byte order marks (BOM) 的坑。由于部分 SRT 文件开头带有 UTF-8 BOM，导致我的 Python 脚本无法正确识别并移除序号，最终将 BOM 和序号一起错误地复制到了 WebVTT 文件中。我尝试过手动处理，后来发现使用 encoding="utf-8-sig" 可以优雅地自动跳过 BOM。对于已经生成的错误文件，我利用 ripgrep 配合正则表达式定位问题，并编写脚本批量清洗了数据。这次经历让我深刻体会到，在构建静态网站管理媒体库的过程中，深入理解底层编码细节是多么重要。
这种类型的教训正是我热爱以手工构建的静态网站来管理本地媒体档案的原因——这种低技术含量的方法给了我大量探索底层概念并了解计算机实际工作原理的机会。
HN 评论区
10- flohofwoe
唉，都 21 世纪了，BOM 怎么还阴魂不散？比如，Windows 什么时候才能终于穿越回 20 世纪 90 年代末，把所有东西都切换到 UTF-8？
UTF-8 BOM 尤其荒谬，因为 UTF-8 完全与字节序无关（所以这个
- orangepanda
UTF-8 字节顺序标记”充其量只是个指示文件采用 UTF-8 编码的标志，但猜猜看？在 Windows 生态圈之外，所有文本文件本来都是 UTF-8 的）。
- mr_mitm
> 字节顺序标记（BOM）是零宽无间断空格字符 U+FEFF 在文本文件开头的特殊用法
BOM 不也可以出现在文件的任何位置吗？毕竟文件是可以拼接的。