编码错配：UTF-8 的文件被当成旧编码读
最常见的场景是字幕以 UTF-8 保存，播放器却按本地的 GBK 或 Latin-1 解码。中文字符由多个字节组成，解码方用错了表，就会把同一串字节拼成完全不相干的字，屏幕上于是出现成片的乱码字符。反过来，旧编码文件被当作 UTF-8 读取，也会散出替换符或方块。
为什么视频字幕会乱码
为什么视频字幕会乱码，答案通常不在画面里，而躲在两个看不见的地方：字幕文件用哪套字符编码保存，播放器又用哪套编码去读它。两套规则一旦不一致，屏幕上就会出现问号、方块或成串的怪异字母。下面这份目录把常见成因拆成一格一格的“展签”，配上乱码长相速查与逐步修复流程，方便你对照自己的文件逐项排除。
- 现象
- 字幕中文变成问号、方框、拉丁乱码或整行错位
- 高发格式
- SRT、ASS/SSA、VTT 等纯文本字幕
- 关键变量
- 文件编码、字节顺序标记、播放器默认编码、字体覆盖
- 排查顺序
- 先看乱码长相，再改播放器编码，最后重存文件
乱码从哪里来
字节顺序标记在开头悄悄做手脚
有些编辑器给 UTF-8 文件加了字节顺序标记。这个标记本身无害，但部分播放器或字幕渲染组件不会跳过它，结果第一个字幕条目的时间轴或首行文字被顶坏，看起来就像开头几条字幕集体错乱。
字体缺字：编码对了，字形却找不到
编码正确、文件也读得通，但字幕仍显示方框，这往往是字体缺字。某些字幕样式指定了并不存在于当前系统的字体，或字体本身不含对应汉字，渲染时就以空心方块或占位符号顶替。换一门覆盖更全的字体通常立刻见效。
转码与合并环节的二次损伤
把字幕封装进容器、重新压制视频，或用工具批量转换格式时，如果转码链条上没有声明编码，工具可能按猜测的默认值重写文件。原本正常的字幕经过一进一出，反而被写成了另一种编码，问题就这样被“制造”出来。
播放器与系统的区域设置不一致
不同播放器的默认字幕编码各异，有的跟随系统区域设置，有的固定使用通用编码。同一份字幕在这个播放器里正常，换到另一个同款软件的另一台机器上就乱掉，多数属于这类默认值差异。
乱码长相速查
先记住屏幕上的样子，再回头找对应的处理办法，往往比盲目试编码快得多。
整句问号或连续“？”典型的多字节中文被单字节编码逐字节解码，优先检查播放器是否被设成了拉丁编码。
空心方块、豆腐块编码多半正确，问题落在字体缺字或样式指定的字体未被安装。
成串的拉丁字母与重音符号UTF-8 字节被按旧编码解释，属于编码错配的经典形态。
出现“”或零星怪符号解码时遇到无法识别的字节而被替换，常见于混合编码或损坏文件。
只有开头几条异常多半是字节顺序标记顶坏了首条时间轴或首行文本。
提示：同一份文件在不同设备上表现不同，说明问题在读取端；多台设备都一样，则更可能是文件本身被写成了不合适的编码。
逐步修复流程
- 确认文件类型。用纯文本编辑器打开字幕，先判断它是 SRT、ASS/SSA 还是 VTT，不同格式的头部结构不同，改错位置会带来新问题。
- 试切播放器编码。在播放器的字幕设置里把编码从自动改为明确的一项，依次尝试通用编码与本地旧编码，观察哪一项让画面恢复正常，这一步不动文件，最安全。
- 查看真实编码。用支持显示编码的编辑器打开字幕，看状态栏标注的是哪种编码，与播放器当前设置对照，找出错配的那一侧。
- 统一后另存。确定目标编码后，用“另存为”重新保存字幕，不要直接在原文件上反复覆盖，便于出问题时回退。
- 处理字节顺序标记。如果异常集中在开头几条，尝试以“无 BOM”的方式保存，或换一个不写出标记的编辑器。
- 检查字体与样式。若乱码表现为方块，打开字幕样式，把字体替换为系统中确实存在、覆盖范围更广的字体，再刷新字幕。
- 回放验证。重新载入字幕，随机抽查开头、中间、结尾各若干条，确认时间轴与文字同时正常，再保存最终版本。
常见问答
- 为什么同一份字幕在手机上正常，在电脑上却乱码？
- 两台设备读取字幕时采用的默认编码不同。手机端可能默认按通用编码解释，电脑端却沿用本地旧编码，于是同一串字节被解成了两种结果。把两端都改为同一编码即可。
- 改编码会不会破坏时间轴？
- 只改变文字编码不会影响时间轴数字，但若中途改动文件头或加入字节顺序标记，首条时间轴可能被顶坏。因此建议先备份，再另行保存。
- 字幕显示方块也是乱码吗？
- 方块更多是字体层面的问题：编码读对了，但指定字体缺少对应字形，渲染时只能以方块占位。替换字体通常即可解决。
- 视频压制之后字幕才乱，应该先查哪一步？
- 优先回想压制或转码时是否声明过编码与字幕格式。转码工具若按默认值重写字幕，就可能引入新的编码，检查工具的编码选项并重新输出一次。
- ASS 字幕比 SRT 更容易出问题吗？
- ASS 带有样式与特效字段，结构更复杂，编辑器或渲染组件对文件头的处理差异更容易放大问题，但成因仍是编码、标记与字体这三类。