简体中文

视频和字幕·字幕工具包

为什么字幕中的 é 变成 é:文本编码以及浏览器如何解码它们

· 工作原理

字幕 字符编码 浏览器处理

一对字节以两种方式解码,产生一个重音字符或两个不相关的字符
原始 ToolAcre 矢量图

字幕中的 Mojibake 几乎总是编码不匹配。这篇文章解释了字节如何变成字符,为什么 UTF-8 和旧版 Windows 代码页不一致,以及基于浏览器的工具如何解码文件而不将其发送到任何地方。

口音很垃圾,但时机很完美——编码问题是如何出现的

告诉我们,除了角色之外,一切都很好。计时准确,提示顺序正确,文件加载,只有重音字母是错误的。这种组合排除了结构错误,因为无法读取文件的解析器将无法产生正确的计时。错误发生在解析之前,当时将字节序列转换为字符序列。

这也解释了为什么故障经常出现在工作流程的中途而不是源头。在一个编辑器中看起来正确的文件在下一个编辑器中可能看起来是错误的,并且中间没有任何修改。没有任何东西改变它;第二个程序对字节的含义做出了不同的假设。

字节与字符 — 为什么相同的字节可以读为 'é' 或 'é',具体取决于解码器

磁盘上的文件以字节为单位。字符仅在应用编码后才存在,编码是将字节序列映射到字符的表。 UTF-8 表示带重音的拉丁字母,例如两个字节的 e-acute。 Windows-1252 将相同的字母表示为单个字节,并赋予两个 UTF-8 字节完全不同的含义:第一个是带波形符的大写 A,第二个是版权符号。

所以我们熟悉的乱码对并不是腐败。这是对错误表下正确字节的忠实、无损读取。每个字节都幸存下来;只是解释改变了。这就是为什么损坏通常是可逆的,以及为什么值得确定不匹配的方向而不是手动编辑可见字符。

UTF-8,Windows-1252 和朋友 - 编码字幕文件实际上出现在

字幕文件以少量编码出现。 UTF-8 是现代默认值,也是 WebVTT 允许的唯一一个。 Windows-1252 在较旧的西欧工具生成的文件中很常见,其密切相关的 ISO-8859-1 涵盖了大部分相同的内容。来自中欧、西里尔或希腊源的文件出现在相应的 Windows 代码页中,东亚材料还添加了更多。

这些编码都没有在文件中记录自己的身份。 SRT 文件不包含用于写入它的编码的声明,这是整个问题的根源:读者必须决定,并且没有任何权威可以阅读。

字节顺序标记——对于某些玩家来说是一个有用的提示,而对于其他玩家来说则是一个明显的故障

字节顺序标记是一个部分异常。它是文件开头的一个特定字符,如果存在,则表示编码。它对某些玩家有帮助,而在其他玩家中则在第一个字幕索引之前显示为流浪角色,这就是为什么带有一个字幕的文件可能在一个程序中失败而在其他任何地方都可以工作。

解析器在执行其他操作之前将其剥离,因为留在原处的标记会将其自身附加到第一个索引号并花费第一个提示。格式检测的编写也是为了容忍这种情况,因此在标头之前以标记开头的 WebVTT 文件仍会被识别为 WebVTT,而不是被视为 SRT。

浏览器如何在本地解码文件 - TextDecoder API,以及为什么在未声明编码时检测是猜测

当该工具加载文件时,它会调用文件 API 文本方法,并且该方法被指定为解码为 UTF-8。没有编码参数,也没有协商。正确读取确实为 UTF-8 的文件;包含单字节重音字母的 Windows-1252 文件表示无法开始有效 UTF-8 序列的字节,并且解码器会替换替换字符而不是猜测。

这值得了解,因为它改变了症状。读取带有旧表的 UTF-8 文件会产生熟悉的两字符乱码。将旧文件读取为 UTF-8 会生成替换字符,即黑色菱形或空框。解码为 UTF-8 以外的内容需要通过浏览器解码器 API 显式命名编码,而命名是困难的部分:在文件中没有声明的情况下,任何自动选择都是从字节模式推断出来的,这种猜测通常是正确的,有时肯定是错误的。

工作示例:拯救 Windows-1252 文件 — 识别源编码并在转换前将其重新保存为 UTF-8

要挽救旧文件,请在字幕工作之前而不是之后进行转换。在编辑器中打开它,您可以在两侧指定编码,告诉它以 Windows-1252 重新打开文件,并确认重音字符正确显示。如果他们这样做了,那么猜测是正确的。然后将文件显式保存为 UTF-8。

在您可以预测的行上进行验证,而不是在整个文件上进行验证。选择一个包含您知道应该存在的重音的提示,然后在转换后的输出中检查它。首先执行此操作意味着字幕工具接收到的文件的字节已经与其将要采用的编码相匹配,并且转换步骤不会再出错。

这不包括什么 - 文件因两轮错误转换而损坏,其中原始字节已经丢失

经过两次错误转换的文件是另一个问题。如果文件被误读,然后以误读状态保存,则错误的字符将被写为真实字符,并且原始字节不再存在于其中的任何位置。此时无需重新解释,因为该文件现在确实包含乱码文本。

这些情况有时可以通过反转错误编码的确切顺序来恢复,但前提是每个步骤都已知并且没有步骤丢失信息。成为替换字符的字节将永久消失:替换字符是代表解码器无法使用的字节的单个字符,并且它不记录该字节是什么。可靠的修复方法是返回到原始文件。

要点:在转换之前对 UTF-8 进行标准化 — 字幕工具包如何在浏览器中处理您的文件以及为什么 WebVTT 输出根据定义是 UTF-8

在转换任何内容之前对 UTF-8 进行标准化。文件本身没有携带其编码的声明,因此每个打开它的程序都在做出假设,而阻止假设不一致的方法就是使它们全部正确。 WebVTT 根据定义消除了歧义,因为该格式需要 UTF-8,这是将 SRT 转换为 WebVTT 以进行 Web 交付的实际原因之一。

转换在浏览器选项卡中的文件上运行。检查您可以预测重音的行的结果,而不是扫描任何看起来错误的内容,因为在九百个提示中包含少量重音单词的文件很容易签署,而无需检查可能失败的部分。