修复 SRT 字幕乱码且不丢失原文

如果您的 SRT 字幕显示为 café 而非 café，切勿立即将其直接另存为 UTF-8。请先完整保留一份未作任何改动的原始字节副本，找出能够还原正确文字的解码方式，然后将校验后的文本写入一个单独的新文件中。直接以新编码保存错误字符，只会把错误永久保留下来。

这里的核心差异在于 “合法编码”与“正确文本”的区别。在下文包含两条字幕的初始测试中，一个损坏的文件顺利通过了严格的 UTF-8 校验，且不包含任何替换字符，但其中的法语文本依然是错误的。另一个文件在六个原始字符被替换为 �.

本指南提供了一个 本地 Python 检测与转换工具、可下载的源文件以及一套可复现的测试流程。它专用于文件层面的诊断和显式转码，不提供自动编码检测、视频时间轴同步功能，也不保证能够找回已经彻底丢失的字符。

第一步：明确真正损坏的部分

一个带有 .srt 扩展名的文件仅代表一种字幕格式，并不保证采用某种特定编码。SRT 包含字幕序号、时间戳、正文及分隔符；美国国会图书馆的 SRT 格式档案 将其描述为纯文本，且没有统一的字符编码标准。

请将看到的异常现象作为排查线索，而不要直接以此下定论：

字符与其显示的字形是两回事。Python 的 Unicode 文档说明 将码位与字体渲染出的字形（glyph）区分开来。编辑器中显示正常，说明问题很可能出在播放器端；但这并不能证明安装某种特定字体就一定能解决问题。本文未对任何具体字体或播放器进行测试。

先备份原始字节，再检查解码效果

下载 subtitle_encoding.py 并将其放置在要排查的 SRT 文件同级目录下。运行这些命令只需已安装 Python 3，无需安装任何额外依赖包。本文的本地测试环境为 macOS 上的 Python 3.14.3。如果你的 Windows 环境使用 Python 启动器，请将 py -3 替换为 python3；该环境未经本文测试。

在该文件夹中打开终端。在以下示例中，请将 input.srt 替换为你的实际文件名。若路径中包含空格，请保留引号。

创建一份未作修改的副本

python3 subtitle_encoding.py backup "input.srt" "original-bytes.srt"

目标文件必须尚不存在。该工具会在不进行解码的情况下复制字节，重新读取副本，并输出其 SHA-256 哈希值。它还会拒绝将源路径作为目标路径。即使已生成可用的字幕文件，也请保留此备份。

在不保存任何内容的前提下检查 UTF-8

python3 subtitle_encoding.py inspect "original-bytes.srt"

报告中包含 strict_utf8, utf8_bom、所选的解码方式，以及在解码成功时包含的文本预览和 replacement_characters 计数。其默认文本视图使用的是 utf-8-sig，它可以妥善处理开头的 UTF-8 签名。

• strict_utf8: false 表示这些字节未能通过 UTF-8 校验。但这并 不能 告诉你哪种编码才是正确的。
• strict_utf8: true 表示它们可以作为 UTF-8 进行解码。但这并 不 意味着解码出来的文字是正确的。
• 非零的替换计数意味着选定的解码方式产生了 U+FFFD 字符。在创建新文件之前，请务必先对这些字符进行排查。

检查过程会输出 ASCII 安全的 JSON，这样终端字体就无法掩盖字符的真实身份： \u00e9 代表 é，而 \ufffd 则代表替换字符。要详细检查可疑行，请指定其物理行号——而不是字幕序号：

python3 subtitle_encoding.py inspect "original-bytes.srt" --encoding cp1252 --line 3

这是针对 Windows-1252（即 Python 的 cp1252 编解码器）的只读测试。只有在导出设置或源历史记录支持该选择时才使用它，而不要仅仅因为本示例恰好使用了法语就盲目选用。行报告会标明每个字符的名称并显示其码位； U+20AC 就是欧元符号。

根据实际证据选择编码，而不是依赖初次预览成功

向文件创建者询问实际的导出编码、检查导出应用程序的设置，或与可靠的原始文稿进行比对。仔细核对整篇文件中的带重音符号姓名、标点符号、货币符号以及代表性行。如果你看不懂该语言，即使解码成功，解码器也无法替你完成这项审核。

“ANSI”不够精确，不足以用来选择源编解码器。Windows-1252 和 Latin-1 也不能混为一谈。在提供的实验中，单字节 80 在 € 下解码为 cp1252，但解码出来的却是控制字符 U+0080 下解码为 latin-1。两种操作都能成功执行。只有明确已知的源语言背景，才能告诉我们哪个才是原本想要表达的内容。

其他语言可能会使用不同的旧版编码，但仅凭语言名称本身无法确定具体是哪一种。如果来源历史不明且候选读取结果互不相符，请在转换前停下来，先获取更充分的源文件证据。

仅在源文本确认可读后再进行转换

对于确认是 Windows-1252 编码的源文件，请创建一个单独的 UTF-8 文件：

python3 subtitle_encoding.py convert "original-bytes.srt" "repaired-utf8.srt" --from-encoding cp1252
python3 subtitle_encoding.py inspect "repaired-utf8.srt"

该转换器会以严格模式完整解码源文件，将解码出的文本重新编码为 UTF-8，验证解码输出后的内容与原文完全一致，并回读写入的字节。它不会修改字幕序号、时间戳、对白内容、标签或换行符。即使解码后的文本保持完全一致，新的底层字节序列也可能会有所不同。

它会特意拒绝执行以下操作：

• 覆盖已存在的目标文件；
• 在严格解码出错后继续向下执行；或者
• 写入包含 U+FFFD 的文本，即便该字符本身是刻意保留的。

最后这一项限制偏向保守：该工具无法判断替换字符原本究竟代表什么。为了让命令顺利通过而强行去除它，只会抹除线索，而不是修复文本。Python 的 错误处理文档 解释了为什么 replace 和 ignore 与严格解码截然不同：它们会替换或丢弃有问题的数据。这两种策略都不应该出现在当前这个转换步骤中。

如果发生 I/O 错误，切勿使用失败的输出文件。磁盘上可能会残留未写完的 新 文件；请保留原始文件，并在后续尝试时使用全新的目标文件名。关于该工具的完整行为和使用方法，请参阅 可下载的 README 说明文档.

带有 BOM 的 UTF-8 该如何处理？

UTF-8 BOM 是位于文件开头的字节序列 EF BB BF。Python 的 utf-8-sig 编解码器 会在解码时自动吃掉该签名，并在编码时主动添加它。

对于确认带有 BOM 的 UTF-8 源文件，请使用 --from-encoding utf-8-sig。该工具通常会在不带 BOM 的情况下写入 UTF-8；仅在接收应用程序有明确要求时才添加 --with-bom 。更改 BOM 并不能将 café 转换为 café。本实验并不代表与任何特定播放器、编辑器或上传平台的兼容性。

五个小文件说明了为何仅有 UTF-8 有效性还远远不够

该实验使用了两条完全原创的法文字幕片段。它们并非取自任何电影、客户文件或翻译产品：

1
00:00:01,000 --> 00:00:04,000
Émile dit : « Le prix est de 12,50 €. »

2
00:00:05,000 --> 00:00:08,000
Le café est fermé.

2026 年 9 月 13 日，一个 Python 3.14.3 标准库脚本生成了五种字节表示形式，并将每种形式与该已知源文本进行了对比。这些是确定性的字节和字符串检查，并非翻译质量基准。请将链接的文件保存到本地磁盘，而不要直接复制浏览器中的预览内容：不同的字节本身正是本实验的重点所在。

每个副本都保留了完全相同的两个时间戳字符串。正确转换后的文件与 UTF-8 原文件在字节层面完全一致。两个受损的 UTF-8 文件则证明了一个范围更窄但很有用的结论：无论是合法的编码格式还是未变动的时间戳，都无法证明字幕文本本身的正确性。而且，时间戳一致也丝毫不代表这条虚构的字幕轨能与真实视频对齐匹配。

若要自行复现这五个文件，请下载 reproduce.py ，并在运行时指定一个尚不存在的目录名称：

python3 reproduce.py encoding-experiment

该脚本会写入测试固件以及一个 results.json ，其中包含完整文本、转换过程、哈希值、运行环境版本及断言信息。你可以将其与 记录的实验结果进行对比；生成时间戳会有所不同。相关脚本和教学原始文件均采用 MIT 许可证.

本地转换器检查还测试了拒绝覆盖现有输出、拒绝源路径、错误编解码器失败、拒绝 U+FFFD、保留 CRLF 换行符以及显式 BOM 输出等情况。这些检查旨在验证该工具的文件处理行为，并不测试播放器渲染效果、真实媒体的时间对齐或 BookTranslator 的翻译表现。

如果乱码字符已经被保存

已保存的乱码：调查确切的损坏过程

我们的乱码副本经历了一条已知的损坏链：原始 UTF-8 字节被错误地用 Windows-1252 解码，随后这些错误的字符又被保存为 UTF-8。其结果包含了 café 以及损坏的欧元符号序列 €.

由于这种特定的转换并没有丢失任何字节，复现脚本可以将其逆转：先将错误文本重新通过 cp1252进行编码，然后再将生成的字节解码为 UTF-8。该脚本还会将恢复出的文本与原文进行比对验证。

这仅能证明 这一特定已知链条是可行的，绝不意味着可以对所有 SRT 文件盲目套用通用的“乱码修复”操作。文件可能包含合法的特殊字符、混合的乱码历史，或者已经被先前的修复尝试篡改过的文本。应尽可能优先使用未受改动的源文件和常规转换流程。如果只剩下已保存的乱码文件，请务必妥善保留该副本，并在另一份副本上尝试逆向转换之前，彻底查明乱码产生的具体原因。

保存的替换字符：此处根本没有编码丢失的字母

测试样本中的数据丢失，是因为将 Windows-1252 字节以 UTF-8 方式解码（并启用了替换功能），随后保存了结果。原本不同的字符全都变成了同一个 � 标记。保存下来的标记本身并不包含足够的信息来辨别原先位置上具体是哪个字符。

不要将这种情况与仅仅在某个应用中 看到 � 混淆。只要原始字节保持未动，采用正确的解码方式仍有可能恢复文本——就像我们处理 Windows-1252 源文件那样。在断定数据丢失之前，请务必先检查源文件。

如果手中仅剩的副本确实已将缺失文本替换成了 U+FFFD 或字面意义上的问号，请重新导出或重新获取一份干净的源文件，或者根据可靠资料进行人工校对。普通的问号也可能是正当的标点符号；仅凭它的存在不能说明任何问题。大语言模型给出的合理补全只是猜测，并不等于找回了文件原本的数据。

确认源文本真正可读——而不仅是命令行执行成功

在确认修复好的文件可用之前，请将代表性的词语和符号与可信源文本进行比对，确认字幕序号和时间戳行未受影响，并在后续要使用它的播放器或应用中打开 新文件 。该脚本的作用仅是保留解码后的文本，它既不是 SRT 语法验证工具，也不是播放验收测试。

如果您现在已经能正常看懂字幕，且无需翻译成其他语言，那么任务就已经完成了。如果您需要配合视频进行实际试听校对或进一步编辑，这篇 字幕软件对比 详细介绍了不同工具各自的分工与定位。

只有当源文本准确无误——且您确实需要其他语言版本时——再进入 BookTranslator 字幕翻译器 以及 AI 字幕翻译工作流。请将编码修复、文本翻译和最终轨道试看视为互不相同的独立环节。任何一个环节完成，都不能作为其他环节同样成功的保证。