论字幕字体子集化真正需求

HanTaNiA 发表于 2026-7-3 23:20
@蒙太奇字幕组

真的非常非常感谢你写了那么多，这对我（小p）意义重大。

我先说说自己的探索过程吧。

子集化技术在中文字幕圈已经有 10 年历史了，但我是新手。一开始根本没打算研究它，直到为了把那个 24MB 的《至尊马蒂》字幕压缩下来才被迫学的，那是我们特效师 NickCollect 做的精致图形指令特效。坦白说，欧美翻译组和日漫字幕组就像两个平行宇宙，交集很少。日漫组很在意字体优化，但欧美翻译组往往就用系统默认字体撑完整部电影，根本没这个需求。

通过做这个项目，我结识了不少日漫字幕组的朋友，也真正见识到了差距。我们做出的 24MB 字幕曾经觉得是 ASS 字幕里数一数二的作品，直到看到日漫组做出 160MB 的字幕才明白什么叫一山更比一山高。原来我们自以为的"精致特效"在这边可能只能算垫底水平。

这也解释了为什么我一开始做得那么不专业，我是完全从欧美翻译组的需求出发的。不知道用户真正想要什么，也不理解为什么要批量转换（欧美翻译组一天也产不出一个字幕啊）。后来收到反馈才加上了批量功能。

同样的问题出现在随机化字体名上。我一开始完全不理解其他工具为什么要这么做。后来有幸和 @海马体插座、@YuriLy、AmusementClub 字幕组的开发者讨论，才明白了原理和用途。这让我在 2.6+ 版本加入了随机化支持，也算是和整个生态看齐了。所以我很感谢这些开发者在整个工具期间的帮助和支持，他们有些现在已经成了朋友。

这里我得坦白一件事。我之前在工具帖回复时说"随机化基本上是为了修补播放器的错误，不应该算标准做法"。前半句是所有用这个技术的开发者告诉我的原因，但现在我觉得情况更复杂。

播放器从来没预料过会收到不完整的字体。它的逻辑很简单：收到"思源黑体"就缓存下来，下次再见到"思源黑体"就直接用缓存的版本，不会重新加载。这对完整字体来说完全合理。但当它遇到的是不完整的子集字体时，它并不知道缺字是不正常的，对它来说，这就像英文字体没有中文字符一样，很正常。

所以才出现了这个矛盾：子集化作为一个创新的解决方案，却无意中激发了播放器的缓存问题。随机化字体名其实就是为了"骗"播放器，让它以为遇到了新字体，从而强制重新加载。但这样做的代价是大量重复的字体被装进内存里，还要修改字幕，还要防止映射关系丢失，虽然这些都不是问题，但说实话不够优雅。

说白了，无论是其他子集化开发者坚信的"填播放器的坑"还是我说的"修补子集化的发明"，我都不是很满意这个方案，越补越复杂。这也是为什么 UI 里对随机化还在用大红色警告，我对这个方向从一开始本身就有疑虑。

最近我越来越怀疑，这些不优雅的修补是否反映了子集化这个思路本身是一种错误？这些质疑想法也是无形促成了这个帖子。



----------

注意，本帖子中“欧美翻译组”指的是中文字幕组，那些把欧美影视内容翻译成中文的字幕组，比如我们“蒙太奇字幕组”。

在本帖其他地方还有欧美字幕社区、fansub，指的是英文字幕组，那些英文日漫字幕组，把日漫内容翻译成英文，我和他们交流过，他们对子集化兴趣不大，甚至质疑这个技术作用和价值。

不过整体来说，以上两个“欧美字幕组”无论是英译中文组还是日漫英文组对“字幕子集化”需求都很少。

首先，我想说的是，想放弃就放弃吧，不要有任何愧疚感和罪恶感。——我个人是不倾向于用「放弃」这种字眼的，但是既然你用了，我也就沿用了。

非常感谢你的理解。我想那个工具会进入维护阶段，继续提供支持和修复错误，但应该不会再计划新功能了。目前的功能已经基本完善，满足了我认识的所有人的需求，继续加功能反而可能占用我在未来项目上的精力。

至于下一个项目，我正在开发自动合并官方中英文字幕的功能，这对欧美字幕组（翻译欧美影视到中文）来说几乎是必备的。之前这个问题无法用机器完美解决，要么只能靠 AI 来合并，要么就是机器合并加费力人工修改。

我花了大约 10 个月松散研究，终于把核心算法搞透了。现在它可以离线本地计算，实现近乎完美的双语合并。等开发完成后，它不仅能合并中英文字幕，还能处理任何语言的双语组合，比如中日双语或其他语言配对，对日漫字幕组应该也有帮助。这会是我的下一个项目和优先事项。

我想，我们都不会否认的一点是，这个论坛的使用者里，多的是深谙技术原理的大佬，不仅远高于我，也大概率远高于你。但是他们鲜有评论的意愿。

是的，我非常认同。这篇帖子里的 @op200、@shadows 等几位，他们的工具做得真的很棒，也给了我很多建议，不管是在帖子里还是开发期间。他们的代码甚至启发过我的思路，我特别感谢他们。当然也感谢那些没有回复但一直在关注的朋友们。

——「愧疚」是因为我在担心，是否是因为在上个帖子里，我的反馈被视为让你不好受的「负面」的一部分，以及我因为近半个月没有上论坛，没有在第一时间回复你的小更新，让你有些期待并受挫了。

不是啦。Bug 反馈是真正有意义的。你的反馈非常建设性，我求之不得，因为这说明有人在实际使用工具，愿意花时间和精力帮改善项目。那对我来说最宝贵。

我说的负面反馈是另两种情况。一种是我邀请一些人试用后，他们对工具的冷眼评价。另一种是在欧美字幕社区（特别是日漫翻译到英文的社区）遇到的不理解和质疑。这类反馈比 bug 反馈多得多，而真正的认可几乎没有，所以那时我就逐渐觉得这个工具可能没什么实际用处。

-------

最后非常非常感谢说了那么多，真的，真的非常感谢，能得到这样的认可以及这个帖子中无数朋友对子集化技术的支持，让我真正重拾了对子集化的信念。

HanTaNiA 发表于 2026-7-3 23:50
作为有「动画收藏」需求的人，我和T大（tonyhsie）一样，都是在本地安装了大量字体的人，我更多使用的是外 ...

就你的实际使用需求来说，这也是我质疑这个技术是否有价值的原因之一。大部分自我管理字幕和字体的人，大概率不会用到子集化技术。我也确实相信，安装完整字体（无论是劫持方案还是真的安装）在长期来看都比子集化技术更有优势。

㈠ 我有时需要改动字幕的文本内容而新字恰好不在子集化字体里

这个确实是子集化技术的诟病。做完一个子集化字幕后，如果要改动就必须重新子集化。但既然能重新子集化，说明电脑大概率已经有了该字体，那为什么还要子集化呢？这就间接否定了子集化的存在意义。实际上只有字幕组那种需要分发字幕、又不想附带字体包的情况才会用到子集化。但这样做导致看字幕的人无法修改，因为改了就会缺字，这正是你经历的事。你找到字体后，电脑里就有了完整字体，还需要再次子集化吗？所以这就是我认为子集化本质上是伪需求的一个重要原因。

以及 ㈡ 「子集化工具的处理不当」或「字体嵌入字幕」这两件事对于播放器来说具有更大的错误处理概率。前者随着我越看越多，这一需求愈发显著；后者我暂时还没有遇到实例。

"子集化工具的处理不当"具体遇到了什么错误呢？能具体解释下吗？你的反馈对工具的改善很有帮助。

私以为，「子集化字体」能最大发挥作用的场景是下列因素的叠加：① 追求软字幕、② 看完即删，阅后即焚、③ 只看不改，即没有自己修改字幕文本的需求、④ 译文语种是中日韩这种含有大量符号的语言……重要性依次递减。

完全认同这个判断。

"子集化工具的处理不当"具体遇到了什么错误呢？能具体解释下吗？你的反馈对工具的改善很有帮助。

暂时还没有遇到错误啦。

这里可能算是我的行文语病，当然也可以怪罪于自然语言的歧义性（(*^_^*)）。

前者随着我越看越多，这一需求愈发显著；后者我暂时还没有遇到实例。

这里面的前者指的是 ㈠ ，而后者指的是 ㈡ ，也就是「子集化工具的处理不当」或「字体嵌入字幕」这两件事有可能造成的问题，但我还没遇到过。

现在很少打开电脑，习惯了平板上连接nas的Webdav看视频了。 动画里有很多屏字用来传递信息，OPED中演职员表也常会选用特殊字体或者有特效，字幕为了融入画面实现更好观感，也会加入很多特效。移动端看视频，选择内封的MKV格式感觉体验是最好的，其次ass格式支持度也还可以。但因为CJK字体体积太大了，动辄十几MB，全部打包到ass或者mkv占用太多体积了，所以感觉动画这边子集化是刚需，至少我用平板看视频感觉是这样。另外我一般是压制组视频搭配字幕组字幕，压制组视频要做种不能随便改，为了保证字幕效果只能外挂子集化的ass或者mks。 个人更喜欢mks格式，无奈支持的客户端太少了。

蒙太奇字幕组 发表于 2026-7-4 01:48
这确实是一个非常好的理由，其实我一开始也这样想的，可以确保电视上显示效果一致，直到我知道其实那些 ...

主要是我本人并不喜欢再次封装压制，太麻烦了，还得多一步处理，特别是压制一不小心还可能破坏大佬精心处理的视频参数，而外挂子集化ass字幕反而能比较简单的增添删改，且封装字体比封装视频简单多了，要是封装成MKV文件还得重新封装替换，并且我个人不喜欢动原视频文件，因为我动画党还想帮忙分流上传分享，只是外挂制造子集化字幕刚好能同时满足我的这些个要求

milkfans 发表于 2026-7-4 11:57
现在很少打开电脑，习惯了平板上连接nas的Webdav看视频了。 动画里有很多屏字用来传递信息，OPED中演职员表 ...

@SAOKiller

主要是我本人并不喜欢再次封装压制，太麻烦了，还得多一步处理，特别是压制一不小心还可能破坏大佬精心处理的视频参数，而外挂子集化ass字幕反而能比较简单的增添删改，且封装字体比封装视频简单多了，要是封装成MKV文件还得重新封装替换，并且我个人不喜欢动原视频文件，因为我动画党还想帮忙分流上传分享，只是外挂制造子集化字幕刚好能同时满足我的这些个要求

中文圈观看欧美影视观众里，很多人其实不会特意去处理 MKV 打包文件，通常要么直接看压制好的成品视频（MP4/MKV），要么下载原始视频再配外挂字幕。起初我也是按照这个思路理解日漫字幕组的，所以工具一开始没有兼容 MKV 打包工作流，只专注于输出整理好的外挂字幕。直到 2.6+ 之后，我才了解到实际需求和预想不太一样，在日漫圈里，MKV 打包反而非常常见，后来到 2.8+ 才终于补上了对 MKV 工作流的支持。

反过来说，两位继续保留原始 MKV，并搭配外挂字幕的做法，其实也很贴近我最初对日漫观众使用习惯的理解。

也感谢两位的解释。对我来说，日漫圈一直还比较陌生，所以有些事情会先入为主地按照自己的理解去判断，实际情况其实和我想的很不一样。哪怕都是“视频 + 字幕”，不同圈子的使用方式也可能差别很大。这篇帖子整体很有意义，不仅解答了我的几个疑问，也帮我澄清了不少之前的困惑。

英文的字幕組會經常把完整的字體一起壓入mkv呢，他們的字符更少所以根本無所謂吧，對於他們來説需要的就只有固定字體這一個需求，所以每一集mkv都會有同樣的字體被壓在裏面也説不定。現在的各種日本動畫的字幕會有著oped時的字幕的字體需要和工作人員名單的字體差不多這樣的需求，還有各畫面内文字需要翻譯的時候也會去找與畫面内日文相似的中文字體，但可能那個畫面就出現一次卻需要下一整個字體，所以需要子集化，這樣就只會有極其少的字的字體就不會出現多餘數據的情況，這是在想辦法將外嵌字幕做的和内嵌字幕差不多嗎。因爲日文漢字有和中文漢字有完全相同的字存在，而翻譯歐美影視的字幕組可能會因爲那邊的文字和漢字差別太多所以不需要特別的字體也可以有很好的觀看體驗。看一些雙語字幕的日文漢字就會發現日文的漢字被以一些中文的字體顯示，子集化這樣節省的固定字體可以使一些播放器不會使用默認的中文字體來顯示日文漢字吧

子集化还是为了提升观看体验并减少查找字体，安装字体或者嵌入mkv这种麻烦事吧，我自己整理资源遇到的无非就这几个问题。我觉得子集化最好的体验，还是和 Jellyfin 这类媒体服务器集成，通过插件动态处理会更合适。我的日常主力只有 Jellyfin，所以就写了相关插件和后端来优化体验(均未公开)。后端统一管理字体库，并提供字幕处理接口，让插件和后端配合处理。字幕不用提前处理，只要正常入库、字体库里有对应字体，就能直接播放。而且字体库越完善，后面缺字体的情况也会越少，还能够维持多平台观看体验 (我觉得追求跨平台显示一致性是没有必要的 虽然在我这里大多数情况下字幕渲染都没有问题 我觉得在便利 可编辑性 跨平台体验三者找一个平衡点就可以了)。这套东西也用了两三年了，对我个人来说应该算是目前的最佳实践

    “表面上看是为了缩小体积。比如把思源黑体从 20MB 压到 1MB，嵌入到字幕里，确实赚到了。但这个账一旦算到多个字幕的维度，就彻底反转了”这个说法也只是在一定范围内没问题，但是再多一层呢？当作品够多的时候，需要的字体越来越多，也会达到很恐怖的体积，会再次反转。比如我的硬盘里大概260部作品，我特意把这些字幕用到的字体全部搜集了一下，去重之后，也有八九个g的大小。作为对比全部子集化的8k+外挂字幕也就这个体积，内封mkv之后体积还会被进一步压缩，总体占用反而更小。
       这些字体除了字幕组和论坛里的字体包，还有很多来自于完整的字体包、字加、以及各种网站上一个一个找，非常费心费力，很多还不一定能完美还原字幕组的效果。这是我有心这么去做，但大多数人 根本不会去攒一个50多g的字体包，然后每次播放的时候用小工具临时加载或者用mpv挂载字体文件夹。
       抛开体积，在jellyfin里没有子集化的字幕播放经常有问题，或者我把视频分享给朋友的时候也不想再教他们一遍怎么还原字幕效果，子集化一劳永逸。所以我是非常支持字幕组直接发布子集化字幕的，我自己也完成了几乎所有字幕的子集化。