用API自动清洗修复SRT/VTT字幕文件

字幕文件是音视频内容不可或缺的组成部分，承载着时间轴与文本的精确对应关系。但在媒体制作与分发的快节奏流程中，字幕文件很容易在处理、存储或传输环节出现损坏——编码错误、格式不一致、文件体积过大，都会让原本整齐的SRT或VTT变得一团糟。对于开发者与独立创作者而言，手动逐行修复既不现实也不经济。

字幕损坏为何频发

SRT（SubRip Subtitle）和VTT（WebVTT）是跨平台使用最广的两种字幕格式。它们结构相似，但各有侧重：SRT更传统，VTT则面向Web场景做了扩展。正因为格式简单、以纯文本为主，它们对编码和换行极为敏感。一次错误的字符集转换、一段被截断的下载，甚至编辑器自动添加的空格，都可能破坏时间轴标记或序号结构。

更隐蔽的问题来自AI应用场景。当模型输出的JSON本身已经是破损的——缺少引号、尾逗号、括号不匹配——下游解析就会失败，字幕数据随之丢失或错位。这类“模型JSON破损”问题在AI驱动的字幕生成流水线中出现频率不低，却常常被当作偶发故障忽略。

SRT（SubRip Subtitle）格式诞生于2000年代初，以纯文本形式记录序号、时间轴和字幕文本，结构极其简单：每个字幕块由序号行、00:00:01,000 --> 00:00:04,000 形式的时间轴行和文本行组成，块与块之间以空行分隔。VTT（WebVTT）则是W3C为HTML5 <track> 元素制定的标准，语法与SRT相似但增加了文件头 WEBVTT、支持CSS样式、区域设置和更丰富的 cue 设置。两者对编码（通常要求UTF-8）和换行符（LF/CRLF）都缺乏自描述能力，解析器一旦遇到BOM头、非UTF-8字节或混合换行，就容易将时间轴行误判为文本，导致整个文件错位。

LLM Dev Utilities API：确定性的修复方案

LLM Dev Utilities API 提供了一条不依赖AI调用的修复路径。它的定位很明确：把字幕清洗、JSON修复、文本压缩到token预算、日志分诊这几件事，做成快速、确定、可重复的工具集。

“不依赖AI调用”是这里最关键的设计取舍。字幕修复本质上是结构化文本的规整问题，用确定性算法处理，意味着同样的输入永远得到同样的输出，不会出现模型幻觉导致的时间轴漂移或文本改写。对于需要批量处理、结果可审计的生产环境，这一点比“智能”更有价值。

请求与响应的基本逻辑

使用方式很直接：把损坏的SRT/VTT文件作为输入发送请求，返回的就是清洗并格式化后的字幕数据，以及相关元信息。可以把它理解为寄修——你寄出破损件，拿回修好的版本，附带处理耗时等说明。

响应的具体内容取决于调用的端点。通常你会拿到干净的字幕文本、处理时间，以及修复过程中是否出现错误等信息。这种“输入破损、输出规整”的模式，适合嵌入现有的字幕处理流水线，作为预处理或后处理环节。

确定性算法在这里指的是不引入概率模型、不依赖外部AI服务，仅通过词法分析、语法规则和状态机对文本进行规整。以JSON修复为例，常见做法包括：补全缺失的引号、移除对象或数组末尾的多余逗号、匹配未闭合的括号、将单引号转换为双引号、对未加引号的键名进行转义等。这类修复的边界清晰——它只保证输出符合JSON语法，不保证语义正确。对字幕文件而言，确定性修复会重新校验序号连续性、时间轴格式（HH:MM:SS,mmm 或 HH:MM:SS.mmm）和空行分隔，但不会改动字幕文本内容本身，因此不会引入模型幻觉。

快速上手示例

API 已在 RapidAPI 上线并提供免费额度，可以直接用 curl 验证。下面这个例子演示的是JSON修复端点，请求体是一段带尾逗号、键名未加引号的破损JSON：

curl -X POST 'https://llm-dev-utilities.p.rapidapi.com/json-repair' \
  -H 'X-RapidAPI-Key: YOUR_RAPIDAPI_KEY' \
  -H 'X-RapidAPI-Host: llm-dev-utilities.p.rapidapi.com' \
  -H 'Content-Type: application/json' \
  -d '{"text":"{name:\"Ann\", age:30,}"}'

免费额度让验证成本几乎为零：先拿真实出错的文件跑一遍，确认修复结果符合预期，再决定是否接入生产流程。对独立开发者来说，这种先试后用的方式降低了试错门槛。

RapidAPI 是一个API聚合市场，开发者通过统一网关调用不同供应商的接口，并使用统一的 X-RapidAPI-Key 请求头进行鉴权。免费额度通常以每月固定请求次数或速率限制的形式提供，适合原型验证和小规模试用。curl 是命令行HTTP客户端，示例中的 -X POST 指定方法，-H 添加请求头，-d 携带请求体。注意示例请求体是 {"text":"{name:\"Ann\", age:30,}"}——外层是合法JSON，内层 text 字段的值是一段破损JSON字符串，这种嵌套结构是为了让API明确接收待修复的原始文本，而不是直接解析外层请求体。

适用场景与取舍

这套工具最适合三类需求：一是批量字幕的格式规整，比如从多个来源汇总的SRT需要统一结构；二是AI生成流水线中的JSON容错，避免模型输出的小瑕疵中断整条链路；三是token预算紧张时的文本压缩。

需要清醒的是，确定性修复擅长处理结构层面的问题，对于语义层面的错误——比如时间轴整体偏移、翻译内容错误——它无能为力。把它当作流水线中的“格式化与容错层”，而不是“内容质量层”，定位才准确。

试用入口： LLM Dev Utilities API 已在 RapidAPI 提供免费额度，在此获取密钥。