字幕乱码是怎么回事？
字幕在某个播放器里变成方块、问号或一串乱码，多数人的直觉是"文件坏了"。多数情况下文件没坏，只是编码、换行符或文件头的标记和播放器对不上。按下面的顺序排查，通常能定位，每一步都有明确的判断依据，不用盲试。
先判断：是乱码还是格式错
- 乱码：文字变成方块、问号、歪扭符号，但条数和结构还在——这是编码问题
- 整段错位：序号和时间轴对不上、字幕飞走——这是格式或时间轴问题，不属于乱码
本文只处理前一种。后一种用 字幕规范检查工具 或 字幕清理工具 处理。先把两类分开，排查方向才不会跑偏。
第一步：确认编码，优先 UTF-8 无 BOM
大多数现代播放器和平台默认按 UTF-8 读取。如果文件是 GBK 或带 BOM 的 UTF-8，老播放器就会显示错字。
- 用编辑器把文件另存为"UTF-8（无 BOM）"；用记事本另存时，编码下拉选 UTF-8 而非"UTF-8 with BOM"
- 中文、日文、韩文字幕尤其要保证是 UTF-8，否则一定乱码
- 拿不准当前编码时，用支持编码探测的编辑器（如 VS Code）打开，状态栏会显示文件实际编码，照此另存为目标编码即可
- 转好后用播放器重新打开，看方块是否消失
判断依据：如果整个文件统一变成方块或乱码，而不是个别字符，基本就是编码不对。如果只有中文变成方块、英文正常，说明是中文编码没被识别，问题同样集中在编码而非换行。SmileSub 导出的字幕默认是 UTF-8，跨平台兼容。关于 SRT 的标准写法，见 双语 SRT 格式详解。
第二步：检查换行符
Windows 用 CRLF（\r\n），Unix 和 macOS 用 LF（\n）。极个别老工具只认一种，换行不对会整条粘连。
- 在编辑器里切换显示不可见字符，看换行是 LF 还是 CRLF
- 统一成目标平台要求的那一种，通常 LF 更通用
- 改完保存，重新加载字幕
判断依据：如果字幕条目之间不再分开、整段粘成一团，多半是换行符问题，而不是编码。
第三步：看文件头的 BOM
BOM 是文件开头的几个不可见字节，用来标记编码。多数工具忽略它，但少数播放器会把 BOM 当成正文显示成一串乱码。
- 用十六进制视图或"另存为 UTF-8 无 BOM"去掉它
- 去掉后首条字幕不再多出一串怪字符，即确认是 BOM 问题
- 之后导出都选无 BOM，一劳永逸
判断依据：如果只有第一条字幕前面多出几个怪字符、后面都正常，基本就是 BOM 在作怪。
修复与预防
- 排查顺序固定为：编码 → 换行符 → BOM，先解决最外层、再解决文件头
- 跨系统拷贝（Windows 和 macOS 之间）最容易触发编码和换行符被自动转换，尽量在目标系统里导出
- 统一工作流：保存用 UTF-8 无 BOM、换行用 LF，后续所有环节都省心
- 导出后顺手用播放器和编辑器各开一次，确认中文、日文、韩文都正常显示，再交给下游环节
- 编辑过程里不要中途切换编码：一旦把 UTF-8 文件当 GBK 存过一次，乱码就焊死在内容里，只能回源重导
关于不同字幕格式怎么选，见 字幕格式选择指南。
常见问题
为什么同一个 SRT 有的播放器正常有的乱码？
多半是编码或 BOM 的差异。播放器对 UTF-8 和 BOM 的处理不一致，统一成 UTF-8 无 BOM 通常两边都正常。
换行符真的会影响显示吗？
大多数现代软件都能兼容两种换行符，但个别老工具或嵌入式播放器只认一种，会导致条目粘连或时间轴错乱，值得排查。
怎么从源头避免乱码？
保存和导出都选 UTF-8 无 BOM，换行用 LF，避免在不同系统间来回拷贝时被动转换。用在线工具导出的字幕已按此标准处理。