有用户反馈，上传的SRT字幕文件在播放器里能正常加载，时间轴也对得上，但中文字幕全部显示为问号或方块。遇到这种情况，很多人第一反应是播放器不支持中文，于是反复更换播放器测试，结果问题依旧。实际上，字幕能加载说明文件结构没有大问题，中文变成问号或方块，绝大多数情况指向字符编码环节。与其在播放器上反复试错，不如按下面的顺序逐层核对。
第一层，核对文件本身的编码声明。SRT是纯文本格式，文件保存时使用什么编码，直接决定中文能否被正确识别。常见的UTF-8兼容性最好，GBK在部分旧环境中仍在使用，两者混用就会出现乱码。更隐蔽的是BOM标记，带BOM的UTF-8文件在部分解析器中会把BOM当成正文内容，导致第一行字幕异常。识别方法并不复杂，用文本编辑器打开文件，查看编码显示状态，或者用十六进制工具看文件开头是否有EF BB BF字节。如果开头存在这三个字节，而加载链路没有处理BOM，就应当另存为无BOM的UTF-8再测试。
第二层，核对字幕加载链路的编码转换。文件编码正确，不代表读取和解析环节也正确。服务端读取文件时如果按默认编码处理，可能把UTF-8内容当成其他编码解读；前端解析时如果又做了一次转换，两次处理叠加就会产生乱码。核对方法是分段验证：先确认服务端读取后的内容是否与源文件一致，再确认前端拿到的字符串是否正常。两端使用统一的编码约定，是避免这类问题的基本做法。如果链路中有一环没有明确指定编码，就应当补上，而不是依赖运行环境的默认值。
第三层，核对时间轴与文本是否分离正常。有些文件编码本身没有问题，但格式存在异常，比如时间轴行与文本行之间缺少空行、序号重复或换行符不统一，解析器在切分时把文本截断，表现出来也像乱码。这类情况容易被误判为编码问题。核对时可以先用简单的文本编辑器查看原始内容，确认每条字幕的序号、时间轴、文本三段结构完整，再观察换行符是LF还是CRLF。格式异常的文件即使编码正确，也可能在解析后出现残缺字符。
日常维护中，可以整理一份字幕文件上线前的检查清单：确认文件编码为UTF-8，确认是否带BOM并按需去除，确认换行符统一，确认时间轴格式规范，最后在目标播放器中实际预览一遍中文显示效果。这几步花不了多少时间，却能挡住大部分低级问题。
更进一步的做法，是在上传环节建立格式白名单和提示文案。明确告知用户推荐使用UTF-8编码的SRT文件，对不符合要求的文件给出具体提示，而不是笼统报错。it数运在网站维护实践中也遵循这样的思路：把能提前说明的规则写清楚，把能自动检查的环节前置，减少用户反复上传、反复沟通的成本。字幕乱码看似是小问题，背后反映的是文件处理链路是否清晰。把编码、BOM、换行符这几个关键点固定下来，同类问题就会明显减少。
