字幕看起来只是一个纯文本文件，实际使用时却集中了三类麻烦：播放器不认这个格式、字幕和画面对不上、想把内容当文稿用却满屏是时间码。这三件事对应三种完全不同的处理思路，混着试只会浪费时间。下面按「格式 — 时间 — 内容」的顺序把它们拆开讲。
值得先说明的是，本站的三个字幕工具都是纯文本解析，全部在浏览器里用 JavaScript 完成，不需要像音视频工具那样先下载几十兆的处理引擎，几百条字幕的文件基本是瞬间出结果，处理过程中文件也不会离开你的电脑。
一、先认清四种格式的能力边界
字幕格式的差别不在「谁更高级」，而在于它能装下多少信息。
- SRT：结构最简单，一条字幕由序号、
00:00:12,500 --> 00:00:15,000形式的起止时间、一到多行文字组成，时间用逗号分隔毫秒。几乎所有播放器、剪辑软件、视频平台都认它，是最安全的通用选择。 - WebVTT：网页
<track>标签的标准格式，文件必须以WEBVTT开头，时间用点号分隔毫秒，且要求写成00:00:12.500这种带小时位的完整形式。它比 SRT 多了定位与样式的能力，但网页之外的播放器支持度不如 SRT。 - ASS / SSA：信息量最大，带
[Script Info]、[V4+ Styles]、[Events]分段，能定义字体、描边、阴影、逐字卡拉 OK 特效和任意坐标位移。代价是结构复杂，很多轻量播放器只渲染文字而忽略样式。 - LRC：本来是给歌词用的，每行只有一个时间标签
[00:12.50]，没有结束时间，也不支持一条内容内部换行。
这条差异直接决定了转换的方向性：从 SRT 转 ASS 是「补默认样式」，信息不丢；反过来从 ASS 转 SRT 就必须丢掉特效。
二、格式互转：明确会保留什么、会丢什么
字幕格式转换 的处理原则是把任何输入都先归一成「纯文本 + 起止时间」的中间结构，再按目标格式重新序列化。这意味着两件事：
- 源文件里的内联样式会被清理。SRT 里的
<i>、<font color=...>标签，ASS 花括号里的{\pos(...)}、{\k30}之类的特效指令，都不会带到输出里，只留下观众实际读到的那句话。 - 转成 LRC 一定有损失。因为 LRC 只有起始时间，结束时间会被直接丢弃，播放器只能靠「下一行开始」来推断上一行何时消失；同时一条字幕里的换行会被合并。给歌词、播客做时间索引没问题，拿它当正式字幕交付就是自找麻烦。
实操上有个容易忽略的细节：转换成 WebVTT 之后如果网页上字幕不显示，先检查文件是不是被编辑器多加了 BOM 或者首行不是 WEBVTT，这两点都会让浏览器直接放弃解析整份文件。工具输出时已经处理了这两项，但如果你之后又用别的编辑器改过，就要重新确认。
三、编码：打开就是乱码不是文件坏了
国内流传的 SRT 有大量是 GBK / GB18030 编码的，而现在的浏览器、编辑器默认按 UTF-8 读，于是整篇变成「锟斤拷」或者一堆问号。这不是文件损坏，只是解码方式错了。
工具的探测逻辑是：先用严格模式（fatal 模式）按 UTF-8 解码，一旦遇到不合法的字节序列就立刻抛错，这时几乎可以确定是国标编码，于是回退到 GBK 再读一遍。这套办法之所以可靠，是因为 UTF-8 的字节结构非常严格，随机的 GBK 双字节流几乎不可能恰好构成合法 UTF-8。
但它不是万能的，有两种情况需要你手动指定编码：
- 繁体字幕。Big5 编码的字节流有一定概率能通过 UTF-8 严格解码检查，或者被 GBK 解成一串不相干的简体字。看到内容「像中文但完全读不通」，就手动选 Big5。
- 混合编码的拼接文件。有人把两份不同编码的字幕直接首尾粘起来，这种文件任何单一编码都读不全，只能拆开分别处理。
修好编码后再做格式转换，输出统一是 UTF-8，后续所有环节都不会再遇到这个问题。反过来说，如果你先转格式再发现乱码，那就是把乱码固化下来了，必须回到原始文件重做。
四、整体平移：整段一致地早了或晚了
如果字幕从头到尾偏移量都一样——比如开头晚 2 秒，中间晚 2 秒，结尾还是晚 2 秒——那就是单纯的整体偏移，用 字幕时间轴平移 填一个秒数就能解决。
方向很容易填反，记住这个判断：字幕比画面早出现，说明时间码太小，要填正数往后推；字幕比画面晚出现，填负数提前。工具提供 ±0.1s 和 ±1s 的微调按钮，实际使用时建议先找一句台词明确的镜头，粗调到 1 秒内，再用 0.1 秒档细调，人耳对 0.2 秒以内的字幕偏差基本无感。
有一个边界要注意：平移后为负的时间会被截到 00:00:00。如果你提前的量超过了首条字幕原本的起始时间，那条字幕就会被压在开头，预览表格里会明显看到第一行变成零。这时说明提前量给多了，或者问题根本不是整体偏移。
五、帧率换算：越往后越不同步的真正原因
另一种症状是开头对得很准，越往后越飘，到片尾能差出几秒甚至几分钟。这类问题平移解决不了——你把整条时间轴往前推，开头就对不上了。
原因是字幕的时间码来自另一个帧率的片源。影视圈里 23.976 和 29.97 这两个数字不是随手取的，它们精确等于 24000/1001 和 30000/1001，是当年 NTSC 彩色电视为了给色度副载波让出带宽而把帧率降了千分之一的历史遗留。所以：
缩放系数 = 字幕原本帧率 ÷ 视频实际帧率
- 23.976 与 24 之间，系数是 0.999，也就是每秒差 0.001 秒。听起来微不足道，但 1 小时 3600 秒会累积出 3.6 秒，两小时的电影结尾差 7.2 秒，字幕已经明显跑到画面前面去了。
- 29.97 与 30 之间是完全相同的千分之一关系，同样是每小时 3.6 秒。
- 23.976 与 25 之间（电影转 PAL 电视的经典场景）差距要大得多，系数约 0.95904，每小时会累积约 147 秒，接近两分半。这种字幕如果只做平移，前后能差出好几个场景。
操作顺序是先缩放、再平移：勾选按帧率换算，选好「字幕原本对应的帧率」和「视频实际帧率」，工具会把整条时间轴按系数重算，界面上会直接显示算出的六位小数系数；缩放完成后如果开头还差一点，再用偏移量补齐。反过来先平移再缩放，之前调好的偏移会被系数一起缩放掉，等于白做。
判断视频真实帧率有个不用装软件的办法：用支持显示媒体信息的播放器看一眼，或者对同一段素材观察结尾处的漂移方向——字幕越往后越提前，说明字幕帧率低于视频帧率。
六、把字幕变成可读文字稿
字幕文件本身是很好的文稿素材，但直接复制出来每句都带序号和时间码，没法读。字幕转文字稿 做的就是把这层结构剥掉，四个可调项各自解决一类问题：
- 合并成段落：按相邻两条字幕的间隔判断是否属于同一段。讲课、口播这类连贯内容把阈值调大（比如 2 秒以上才断段），能得到接近文章的段落；访谈、问答类调小，才不会把提问和回答混成一段。
- 去掉重复行：双语字幕会把中英文放在同一条里，卡拉 OK 字幕会整句重复多次，这个选项专门处理这两种情况。
- 保留时间戳：在每段前加上时间，做课程笔记或会议记录时非常有用，读到某句想回去看画面可以直接定位。
- 保留条目内换行：默认会把一条字幕内部的换行合并成一句，因为大多数换行只是为了控制屏幕上的显示宽度；但如果原字幕是有意义的分行（比如歌词、诗句），就要勾上它。
四种输入格式都支持，结果可以直接复制或者下载 TXT。需要提醒的是，字幕是「听写结果」，标点密度和书面语习惯差别很大，导出的文稿通常还需要人工过一遍标点和口语词，指望一键得到能发布的文章是不现实的。
常见问题
字幕改完了，怎么把它压进视频里变成硬字幕？
本站的字幕工具只处理字幕文件本身，不做视频画面渲染，所以没有内嵌硬字幕的功能。多数播放器只要把字幕文件和视频文件放在同一目录、改成相同的主文件名，就会自动加载外挂字幕，这比烧进画面更灵活，也不用重新编码。
平移和帧率换算能一次做完吗？
可以，同一次操作里勾选按帧率换算并填写偏移量即可，工具内部固定是先缩放后平移的顺序。但建议分两步确认效果：先只做缩放，看结尾是否对齐了；确认之后再加偏移量调整开头。一次调两个变量，出了问题分不清是哪个的责任。
转换后英文字幕正常，中文变成方框，是编码没修好吗？
方框和乱码是两回事。乱码是字符解码错误，方框通常是显示端缺少能渲染这些汉字的字体，尤其在把字幕当作 ASS 使用时，样式里指定的字体如果本机没有，播放器就会退化成方框。这时改字幕文件没用，要么在播放器里换一个中文字体，要么转成 SRT 让播放器用自己的默认字体渲染。
几万行的字幕文件能处理吗？
可以。字幕解析是纯文本运算，即使几万条也在一秒级完成，真正的限制是预览区只列出前面若干条以避免页面卡顿，剩下的条目仍然会正常参与转换和下载。