【工具分享】基于浏览器的ASS字幕字体嵌入子集化工具

outayshy 发表于 2026-5-9 18:59
请问一下，转换前显示需要字体DFKaiSho-Md，但上传DFKaiSho-Md & DFPKaiSho-Md & DFGKaiSho-Md.ttc后网页系 ...

@outayshy 反馈的问题已定位并解决。根据调查，问题源于早期版本的缓存机制，导致浏览器在刷新后仍停留在有问题的1.7版本。该工具目前已更新至2.7版本，中间经历了数十个版本迭代与大量bug修复。解决方案为通过Ctrl+F5强制刷新并清理浏览器缓存来彻底清除缓存数据。

在针对 @outayshy 提供的字幕样本和字体进行测试的过程中，还发现了一个额外的字体问题。该问题不会影响该工具加载子集化字体，仅在用户将部分子集化字体下载到Windows系统后双击打开时会提示"不是有效的字体文件"。问题原因为OS/2表的version字段与实际数据大小不一致，导致Windows无法识别。由于播放器的字体检查机制并不如此严格，所以不会产生实际影响，但该问题已一并修复，使得子集化字体符合更标准的规范。

感谢 @outayshy 提供的字幕样本、字体测试支持，以及反馈过程中的细致调试工作。相关修复已在2.7.1版本中发布。

我们的子集化工具目前主要为字幕制作完成后的嵌入字体环节设计，整个流程是围绕字幕制作工作而构建的。之前群内提到的，如果工作流涉及 MKV 打包，这个工具就很难直接适用，主要原因有两点：

    1. 无法处理多字幕合并：当一个 MKV 包含多集动漫（比如 10 集动漫在一个文件中有 10 个字幕）时，工具无法把这些字幕的字符集合并，生成一个统一的子集化字体。

    2. 缺少独立字体输出：虽然 UI 里有字体下载功能，但那本质上是用于调试字体问题的。工具目前不支持直接输出子集化后的字体文件供 MKV 打包流程使用（字体是嵌入在字幕内，而非独立提供）。

所以我想了解一下大家的实际使用场景：你们对这类"多字幕合并成一个字体"的需求是否比较常见？这会帮我们评估是否值得扩展工具功能。

请问去除子集化是什么意思

jelwell 发表于 2026-6-13 08:11
请问去除子集化是什么意思

就是移除已经嵌入到字幕里的字体，这工具可以将字体嵌入到字幕，也可以将任何已经嵌入字体的字幕还原成普通的字幕。

帖子中"去子集化"是早期称呼，源自论坛，在UI里已经叫做【移除内嵌字体】，你可以试试看哦。

楼主大大，我之前使用时发现一个问题。我在这里提一下，看看你们是否愿意多提供一个选项。

现在有些字幕组本身提供的 MKV 文件里的字体和字幕都是经过子集化的。我提取出来后，像过去那样将子集化字幕逆映射得到原始未子集化字幕后，遇到的一个障碍是有些字幕组使用的字体实在是过于小众了，站内的大合集和找字网等网站里都没有，甚至 Google 也搜不到。

于是，我转而考虑将子集化字体直接嵌入子集化字幕。

然后，我使用你们提供的工具，传入子集化字幕后，在「选择操作」栏里依次勾选「嵌入第三方字体」和「完整嵌入字体」，我预期的是在上传字体文件处可以上传我从 MKV 文件里提取的子集化字体。但是问题出在你们识别出的「待上传」字体列表里还是原始字体的名字。这便无法直接上传子集化字体文件了。

我估计软件是从字幕文件里读取开头的字体映射关系列表得到的原始字体名称。于是，我从子集化字幕里删除映射信息后，再次上传字幕文件，这次便成功了。

但是，我认为当前这样不太好。原因有二：① 费事，即需要一个个打开子集化字幕文件去删除；② 信息丢失，直接删除映射关系虽然能行，但是丢失了映射信息。如果后续如果找到完整的字幕文件，也无法从这个字幕文件重新逆映射回原始字幕了。如果处理后，再把映射信息添加回去，那就还是第一个问题，费事。

其实，你们的工具暂时不提供逆映射服务——不清楚未来是否追加这个功能——，那么完全可以忽略映射关系，就把那些子集化后的字体名称当作现实存在的完整字体来识别和处理即可。我相信这个也不难改，代码里忽略前面的映射信息即可。

特别一提，不清楚楼主是否会修改。对于和我有同样想法的用户，可以使用站内的 assfonts 工具，可以达到我说的效果。

再次感谢楼主和蒙太奇字幕组分享工具，也衷心期待我的意见可以得到认可和采纳！

HanTaNiA 发表于 2026-6-13 13:07
楼主大大，我之前使用时发现一个问题。我在这里提一下，看看你们是否愿意多提供一个选项。

现在有些字幕组 ...

非常感谢你的支持和建议，也请不必那么客气，大家都是热爱影视的朋友，没有这种等级之分。



理解你的问题


你遇到的问题涉及到一个叫做"随机化字体"的技术。让我先解释一下这个背景。字幕组为了防止播放器缓存同名字体导致字符不全，会使用子集化软件对字体进行随机化处理。具体来说，假设原来的字体叫"思源黑体"，随机化后会被改成一个完全不同的名字，比如"YDCSJGAX"（8个随机大写字母或数字）。这样做的目的是欺骗播放器，让它以为遇到了一个全新的字体，从而强制加载新字体。

根据你的描述，我认为你遇到的核心问题是这样的：字幕文件内部需要的是随机化后的字体名称（比如"YDCSJGAX"），但你上传的是原始字体（比如"思源黑体"），工具把它们识别成了两个不同的字体，所以无法成功匹配和嵌入。这对吗？



工具识别字体的方式


我来解释一下工具和播放器是如何识别字体的，这对理解整个问题很重要。

字体文件其实不仅仅是一个文件，它内部包含了许多信息。其中最关键的是一个叫做"name表"的东西。name表就像字体的身份证，记录了这个字体叫什么名字。比如说，一个字体文件可能叫做"SimHei.ttf"（这是文件名），但它的内部name表里写的是"黑体"。播放器在加载字体时，不是根据文件名来识别，而是打开字体文件，读取其内部的name表，然后去匹配字幕里所需要的字体。


那随机化字体是怎样的呢？随机化字体软件在处理字体时，不仅改变了文件名，更重要的是改变了字体内部的name表。比如，原来一个字体的name表叫"思源黑体"，随机化后，软件会把内部的name表也改成"YDCSJGAX"。这样当播放器查找"YDCSJGAX"这个字体时，就能找到这个随机化后的字体。

映射表是什么呢？映射表就是一个记录，用来说明"思源黑体被改成了YDCSJGAX"。这个映射表的作用只是给人类看的，帮助我们理解字体经历了什么变化。工具和播放器在识别字体时基本不依赖映射表，因为它们直接读取字体内部的name表。



现有功能和缺陷


目前工具已经支持识别和嵌入随机化字体。只要你上传的字体内部name表与字幕需求相匹配，工具就能成功识别。比如说，如果字幕内部需要名为"YDCSJGAX"的字体，而你上传的字体文件虽然叫"某个文件名.ttf"，但它的内部name表确实标注为"YDCSJGAX"，那么工具就能成功匹配。工具也支持移除嵌入的字体，并通过映射表进行可逆转换，这样你可以把随机化字体还原成原始字体。

但是，工具目前还不支持用原始字体去匹配随机化后的字体。也就是说，如果字幕内部需要"YDCSJGAX"，而你上传的是原始的"思源黑体"字体，工具就无法自动匹配。要实现这个功能，我们需要在上传时读取字幕里的映射表信息，然后动态修改你上传的原始字体，把它的内部name表从"思源黑体"改成"YDCSJGAX"，这样才能让字幕找到字体。这个功能在技术上是可以实现的，但目前还没有加入工具里，这是我对你需求的理解和猜测。

不过这里值得指出的是，如果字体和映射表都来自同一个字幕文件，它们理应能够匹配。因为字幕内部需要的字体名称是"YDCSJGAX"，从MKV里提取出来的内嵌字体的name表也应该是"YDCSJGAX"，两者相等，映射表的内容就无关紧要了。所以你遇到的问题可能另有原因（下面我再提供第二个猜测，也欢迎你澄清实际需求）。


跨字幕映射的限制


你的问题还涉及到另一个更复杂的情况。想象一下这样的场景：你有一个字幕需要"YDCSJGAX"字体，通过映射表你知道它实际上是"思源黑体"。但你手上没有思源黑体，反而从另一个随机化字幕里下载了一份思源黑体的随机化字体，这份字体的随机名字恰好是"GCUSGU5S"。

此刻你无法把"GCUSGU5S"字体当作"YDCSJGAX"上传到你的字幕里。虽然作为人类，我们一眼就能看出"GCUSGU5S和YDCSJGAX都等于思源黑体"，但工具处理字幕时是按照每个字幕为单位来处理的，它不知道跨字幕的映射关系。

这就涉及到一个更宏大的功能设想，即实现跨字幕分组处理，从而让工具具备更强的智能识别能力。这个建议确实曾有人在社区提出过（见32楼），但由于涉及的变数非常多，这类功能可能并不会作为优先考虑事项。



关于再次子集化的建议


这里还要补充一个重要的建议。如果"GCUSGU5S"和"YDCSJGAX"这两份字体都已经是子集化的字体，那么它们的内部大概率存在字符缺失。在这种情况下，再次对这些已子集化的字体进行子集化是不建议的。

为什么呢？子集化的过程是不可逆的失真。打个比方，这就像是在剥洋葱。每次剥洋葱时，你都会失去一层洋葱，整个洋葱就变小了。如果你一层一层地剥下去，最后的洋葱一定比最开始的洋葱小很多。字体也是一样的原理，每一次子集化都是一个失真过程，字体会失去一些原有的字符信息，这是无法恢复的。

理想的情况是这样的：假设你有一个固定大小的盒子（代表字幕所需的字符集），你把洋葱剥到恰好能填满这个盒子，不多不少，这样就实现了完美的子集化。但问题在于，每个字幕的盒子尺寸都不一样，所需的字符集大小各不相同。如果你从一个小盒子剥下来的洋葱去填一个大盒子，原本被剥掉的那些字符就无法补回来，盒子里就会出现缺字的情况。这是物理上无法解决的问题。



后续建议

如果我对你的问题理解有误，或者你觉得我遗漏了什么重要的信息，欢迎提供具体的字幕文件、字体文件示例以及字幕中的字体映射表内容，这样我能更准确地诊断问题。


关于你提到的两种场景：


原始字体映射到新的随机名称：把原始字体放入新的盒子时，只要有映射表指定新盒子的名字，这个技术完全可以实现。如果有需求，我们可以考虑加入。已子集化字体复用到其他字幕：把已经剥好的洋葱放入其他盒子时，我们真的不希望实现这个功能，因为失真是无法复原的，只会造成更多失真。

另外，工具已经实现了"随机化字体识别"和"移除字体时自动还原映射关系"的功能，欢迎测试！

再次感谢你详细的描述和建设性的建议，这对改进工具很有帮助。

蒙太奇字幕组 发表于 2026-6-13 18:35
非常感谢你的支持和建议，也请不必那么客气，大家都是热爱影视的朋友，没有这种等级之分。

感谢回复，麻烦你格式规范地打了这么多字。

但是你真的误解我的意思了，你上面科普的内容我都知道，我正是在拥有上面知识的前提下更进一步了。

我自认为上面的描述已经足够清晰。我本来需要用具体文件举例的，但是我怕随便附上字幕文件，违反到字幕组的分发规则，就没有这么做。

下面我将举例并必要时附图说明。

正如我所说，我理想的情况是得到一份原始字幕文件，里面包含对「Aa方萌」这个确实存在的字体的直接引用，而不是引用其子集化版本。

但是，字幕组只提供了 MKV 文件，我只能从其中提取到子集化字幕和子集化字体。因此，我的想法是：直接将子集化字体嵌入子集化字幕。

---------------------------------------------------------------------
可能有些绕，我们来剖析一下。

通常来说，或者说按照这个工具的设计流程，为了得到一个「子集化字幕+嵌入子集化字体」的字幕，我们需要有两个东西：原始字体文件 和 原始字幕文件 。

这其中干的事自然包括以下三步：
① 程序从头到尾扫描原始字幕文件的每一行，识别出引用的每种原始字体只使用了哪些字符；
② 只从原始字体文件中提取出使用的字符以构造新的字体文件（也就是字体文件的子集化）；
③ 最后将原始字幕文件里的引用名称改成子集化后的标识，并嵌入上一步中构造得到的子集化字体文件。
这用你们的工具，或者 assfonts 等其他工具都能做到。

我当然能够从子集化字幕里的映射关系中看出原始字体是什么。但是正如我所说的，有些时候，字幕组用的字体过于小众，我难以获取原始字体文件，手头上只有经过子集化的字体文件。这意味着我至多只能通过逆映射得到原始字幕文件，但是因为没有原始字体文件，无法按照上面的流程走一遍。

——但是，这本身就很多余不是吗？就算我找到了原始字体文件，我也是只用到子集化字体文件里的那些字符，那为什么不直接骗过工具，完全就把子集化字体文件当作完整的字体文件，把子集化字幕当作原始字幕，然后直接把子集化字体嵌入子集化字幕呢？

这个想法很不错吧？也很自然吧？更重要的是，它是可行的！正如我上一条回复所说，我使用站内的 assfonts 工具成功做到了这一点！只需要在操作时，把这个提供的子集化字幕当作原始字幕，把提供的子集化字体文件当作完整的字体文件。

这对应在你们的工具里，那就是在我上一条回复说的，依次勾选「嵌入第三方字体」→「完整嵌入字体」。然后系统应当识别说，检测到使用了某字体（通常来说，这里的标识应当是随机化字符，而不是原始的「Aa方萌」），然后让我上传这个标识为随机化字符的字体文件，而不是让我上传「Aa方萌」文件。
---------------------------------------------------------------------

让我们回到这个例子。

打开子集化字幕，上面有映射关系列表，如下所示：

…………
; Font Subset: ZJ64TSXU - Aa油画棒
; Font Subset: FACAS56I - Aa方萌

如上，对该字体进行子集化映射，得到的子集化字体的标识是「FACAS561」。

而我也确实从 MKV 文件里提取得到了对应的子集化字体文件「Aa方萌.0.FACAS56I.ttf」。再说一次，我完全知道我在干什么，我知道引用时看的不是操作系统（或者说文件系统）层面的文件名，而是字体文件内部的某种标识——我只是不清楚具体的术语，按照你上面的说法，似乎叫「name 表」？不过现在这不重要——，且这个标识可以通过双击这个文件，进入字体安装界面，从「字体名称」那一栏里知道。要引用该字体时，我们正是通过该标识来称呼它。

然后，让我们上传这个子集化字幕文件至你们的工具，并依次勾选「嵌入第三方字体」→「完整嵌入字体」。如果就我们剖析的结果达成共识后，我们应当期待下面让我们上传的字体文件的标识是什么呢？

——是的，它应当是「FACAS561」。因为我们是把子集化的字体当作了一个现实中确实存在（更技术地说，被注册了专利）的完整字体，这个字体就叫做「FACAS561」。

但是，让我们看看你们工具让我上传的字体的标识是什么？如下图所示。


即使我试图上传子集化字体文件（「Aa方萌.0.FACAS56I.ttf」），也会在回报未匹配——当然如此。如下图所示。


不应该如此，是吧？我希望至此，我已经清晰地传达出意思了。

再多说一点，正如我上个回复所说，问题出在了：你们的程序，对于我们上面描述的这种情况（需求）下，不必要地去解析了映射信息，并暴露出原始字体标识，但多做了这一步反而坏了事。

---------------------------------------------------------------------

不知不觉，叽里咕噜说了一大堆。希望我表达清楚了，如果有语言不通顺的地方，还请谅解！

为了方便你们直观地亲自跑一下上面的例子，也为了方便你们改进后——如果你们愿意的话——进行测试，我这次附带上只留下必要信息的子集化字幕文件（包含对「FACAS561」字体的引用）和子集化字体（「Aa方萌.0.FACAS56I.ttf」）。前者我删得只使用了 10 个字符，后者依旧是包含 24 个字符，不过如果理解了上面所说的，这些都不重要，重点是标识为何。

test_example.zip (11.42 KB, 下载次数: 3)

2026-6-13 23:06 上传

点击文件名下载附件

再次感谢你们的分享，以及愿意看我的啰嗦反馈。希望不会彼此双方不会感到厌烦~

HanTaNiA 发表于 2026-6-13 23:07
感谢回复，麻烦你格式规范地打了这么多字。

但是你真的误解我的意思了，你上面科普的内容我都知道，我正 ...

前面是我的理解错误还请见谅，非常非常感谢提供示例文件和如此详细的解释。

我现在理解了，实际上我前面解释的也不正确，我之前说“如果字体和映射表都来自同一个字幕文件，它们理应能够匹配。”也是不对的，之前引入了读取字体映射表在转换前，还误以为这个功能是你期待添加的功能，忘记之前已经添加了，正是这个在 2.6.X 刻意引入的功能导致你无法导入随机化字体。

实际上现在处理流程是：上传字幕，如果存在映射表则把它解析为原始字体，然后要求用户上传完整的原始字体，然后可以选择进行随机化或者只是嵌入。

但是映射表在这里是一个阻碍，它只识别转换后的Aa方萌，而忘记加上FACAS56I字体，这样上传FACAS56I字体自然不匹配。这属于设计时没有考虑的错误。

不过我还是希望继续保留当前的这种上传字幕后把映射表逆向得到原始字体，方便人们添加原始字体重新子集化，对于你的需求，我也会加入支持原始字体“Aa方萌”的同时，也支持映射表另外一头的FACAS56I字体，因为他们在这个案例中都是相等的，并且使用完整字体或者使用FACAS56I字体都不会导致缺字。

我会在未来几天修复这个问题，也非常感谢你那么耐心的指出和纠正，这样的反馈非常棒，非常有意义和具有建设性，真的感谢感谢。

蒙太奇字幕组 发表于 2026-6-14 01:50
前面是我的理解错误还请见谅，非常非常感谢提供示例文件和如此详细的解释。

我现在理解了，实际上我前 ...

是的，我在第二次回复中特意强调了这是对于我提到的这一种需求：

问题出在了：你们的程序，对于我们上面描述的这种情况（需求）下，不必要地去解析了映射信息，并暴露出原始字体标识，但多做了这一步反而坏了事。

我明白你说的：

希望继续保留当前的这种上传字幕后把映射表逆向得到原始字体，方便人们添加原始字体重新子集化

这一希望是合理的，毕竟我明白这个工具的主要还是给字幕组使用的，而「子集化」比「字体嵌入」是更加普遍的做法，所以完全可以想象如果有嵌入字体的想法，这个场景很大可能是：已经持有子集化字幕+本地持有完整字体文件。因此，由程序主动逆映射出原始字体，并要求上传原始字体文件就很自然了。

我正是清楚这一功能背后的场景预设，才没有否定你们的做法，而是在第一次回复开头说到

看看你们是否愿意多提供一个选项

所以你本不用解释这一点的，只是晚上写了好久，有些累了，感觉表达出重点内容即可。文字本来就多，如果写太多主要意图以外的东西，就更不易读了。



嘛，总之，看来我们算是同频了。Lucky~

感谢你的回复，不用急着马上修正，要好好休息哦~

工具已更新至 2.7.2 版本。

原计划和其他功能建议一起积累到 2.8 发布，但在 @HanTaNiA 的详细说明下，意识到修复实现其实很简单，所以快速推出了这个小更新。

具体修复内容：
1、随机化字体现在支持两种上传方式。既可以上传随机化前的原始字体，也可以上传随机化映射表中的随机字体。原始字体保持完整不失真，随机字体只要处理的工具正确也不应该失真，两种方式完全等价，并且在UI也会在映射后的随机化字体写上映射前的随机字体信息，比如图中FACAS56I。



2、移除了【补全 ASCII 字符】的默认勾选。经过充分的播放器兼容性测试，这个选项导致问题的概率极低，无需默认启用，可以最大化节省嵌入字体的体积。

特别感谢 @HanTaNiA 的细致反馈和关键建议，这些贡献非常宝贵！

页面刷新后，右下角显示 2.7.2 即代表更新成功。