字体文件怎么校验完整性？判断损坏与缺字的步骤

周五下午，设计师把字体包拖进系统，AI 里排完版，导出前发现标题里两个字的偏旁是空的，位置留着一个方框。文件是从网盘下的，解压时跳过一次报错，当时没在意。同事用同一款字打开却正常，问题于是落到一句话上：是我这份文件坏了，还是这款字本来就没有这两个字。

这两种情况的处理方式完全相反。文件坏了，重新下一份就行；字库本身缺字，重下一百次也一样。校验的意义就是把“坏了”和“没有”分开，再决定下一步动作。这篇按手动检查、客户端激活、脚本批处理三条路径讲，最后给一套可以固定下来的操作顺序。

一、先分清三种“不完整”

一是文件在传输环节坏了。 下载中断、解压报错、拷贝过程断电，都可能让文件头或表结构缺一截。表现很典型：安装时提示“不是有效的字体文件”，或者装完在软件字体列表里根本找不到这个名字。这类问题改文件名、重装系统都没用，只能换一份文件。

二是字库本身的字符集就小。 标题类字体出于设计定位和制作成本，常常只覆盖常用字，缺字是取舍而不是故障。表现是正文常见字都正常，一碰到生僻字、繁体字、异体字、注音符号或者某些标点，就退回方框。缺字位置往往集中在同一个字区，重复出现，规律明显。

三是文件被裁过。 网页上用的 woff2 通常只保留页面上出现过的字符，一个几 MB 的字库能裁到几十 KB。这类文件放进设计软件必然大面积缺字，但它不是坏文件，是范围被限定过的文件。判断方法很简单：看体积。几 MB 的汉字库裁到几十 KB，基本可以确定是子集。

四是文件没坏，是没生效。 系统里已经装了同名或同 family name 的旧版本，新文件被忽略；或者字体缓存没刷新，软件读到的还是旧的那一份。这种情况重装十次也不解决，得先清缓存，再处理同名冲突。

判断顺序建议固定成三步：能不能被解析、覆盖够不够、有没有真正生效。顺序颠倒，很容易在“反复重装”上耗掉半天，最后发现问题出在缓存上。

二、方案一：不装额外工具，用系统自带能力查

比体积。 字体详情页一般会标注文件大小，下载后对照一下。差几十 KB 属于正常波动，差一半以上就要怀疑下载不完整。

比哈希。 官方如果给了校验值，直接比对。Windows 下用 certutil -hashfile 文件名.ttf SHA256，macOS 下用 shasum -a 256 文件名.ttf。哈希一致说明字节完全一致，文件损坏这一项可以排除。

看字体信息。 Windows 双击文件进预览，macOS 拖进“字体册”看信息面板，重点读三项：完整名称、版本号、支持的字符集与语言。版本号比预期低，说明拿到的是旧版；字符集里写着“西欧”而没有中日韩，说明这份文件本来就不含汉字。

用测试字串试。 这是最贴近实际使用的一步。新建一个文本框，粘一段覆盖度足够宽的测试内容：常用汉字若干、阿拉伯数字、英文大小写、全角与半角标点、书名号与破折号、几个生僻字、常用繁体字。看方框出现在哪个区段。如果方框集中在生僻字，是字库覆盖问题；如果连“的”“一”都出不来，是文件或安装问题。

测试字串建议按项目类型准备两套。日常商稿用常用字加标点就够；做书刊、古籍风版面时，一段繁体与异体字混排的样本更能暴露问题，霞鹜文楷（点击查看字体详情及预览效果）这类基于开源楷体补完的字，简体繁体覆盖都做得比较全，适合拿来对照——同一段文字在它上面正常，在另一款字上出方框，基本可以断定是后者覆盖不足。

放大看轮廓。 把字号拉到足够大，观察笔画有没有断裂、飞点、错位。传输损坏的文件有时能装上，但轮廓数据被截断，放大后能看出残缺。这一步在标题字上尤其值得做，标题字号大，瑕疵藏不住。

清缓存再确认。 前面几步都正常但软件里就是不显示，先清系统字体缓存、退出软件重开，再确认有没有同名字体并存。清缓存的具体路径按系统版本不同，这里不展开，思路是让系统重新读一遍字体目录。

这一条适合谁。 偶尔处理一两个文件、手上没有脚本环境的人。成本几乎为零，能覆盖大部分“这份文件是不是坏了”的疑问。

三、方案二：字由客户端（可免费使用）

如果缺字这件事反复出现，逐份文件校验的效率就很低。把字体来源收进一个入口，本地不再保存和传递字体文件，前面那些损坏、版本混、装不上的问题会一起消失。

做法。 下载字由客户端，免费领取试用会员，在客户端里搜到需要的字体后激活，PS / AI / Office 等软件里就能直接按字体名调用，本机不用安装字体文件。校验逻辑从“查文件”变成“查字”：在客户端的预览框里输入项目要用的字串，能不能正常显示一眼可见，不必先装再试错。

覆盖范围。 客户端累计收录 10500 多款字体，其中 3600 多款免费商用字体不限量使用，590 多款会员商用字体可授权商用。做长文排版时，思源黑体（点击查看字体详情及预览效果）这类七档字重、简繁覆盖完整的字，缺字概率低，适合当基准字；需要可变调节的标题，可以看阿里妈妈方圆体（点击查看字体详情及预览效果），它在端正与圆润之间连续变化，同一款字不同字重的显示效果能在预览里直接比对。

它解决的是哪一层问题。 传输损坏和版本混淆基本归零，因为文件由平台侧管理，本地不落地；字符覆盖则可以在激活前就看到。界面与文档方向可以拿 MiSans（点击查看字体详情及预览效果）试一段中英混排，数字、单位符号和标点的对齐情况在预览里就能判断，不必先装到系统里再逐个软件验证。它不能解决的是文件层面的深度排查，比如你要确认某个第三方文件的表结构是否完整，那仍然是脚本的活。

适合谁。 多台设备切换、跨 Windows 与 macOS 协作、不常接触字体文件的人；以及内容团队里由非设计岗自己改稿的场景。离线或内网环境使用前，先确认客户端的联网要求，避免装好了却激活不了。

四、方案三：用脚本做批量校验

手上字体文件成百上千，或者要给素材库做一次体检，手动点开显然不现实。Python 的 fontTools 是常用选择，几行代码就能把关键指标读出来。

先确认能解析。 用 TTFont(路径) 打开文件，解析失败会直接抛异常，这一步等于做了结构完整性初筛。能打开，说明 sfnt 表目录基本完整。

再查必需表。 一款可用的中文字体通常要有 head、hhea、maxp、cmap、name、OS/2、post，以及 glyf 或 CFF 之一。缺 cmap 意味着字符到字形的映射没了，装上也打不出字；缺 name 则字体名会显示异常。把这些表名做成检查清单，缺一项就标记出来。

接着数字符覆盖。 用 getBestCmap() 取到码位到字形名的映射，长度就是可映射的字符数。这个数字比“文件多大”有用得多。同名字体不同版本之间对比字符数，能看出拿到的到底是新版还是旧版。

抽样验证具体码位。 字符总数达标不代表你要的字都有。把项目常用的字、品牌名里的字、生僻字逐个查一遍，确认码位在映射表里，且指向的不是 .notdef。这一步能精准回答“为什么只有这两个字是方框”。

最后导出成表。 把文件名、family name、版本号、字符数、文件字节数写成 CSV，与官方清单逐行比对。有了这张表，哪份文件可疑、哪份重复、哪份是旧版，一眼能看出来。变量字体还要多看一眼 fvar 表里的轴数量与取值范围，轴缺失说明这份文件是静态版本。

这一条适合谁。 有技术同事、字体资产上规模、需要定期体检的团队。一次写好脚本，往后每批入库跑一遍，成本会摊得很薄。

五、操作步骤

1. 先记录来源：从哪个页面下载、下载时间、页面标注的文件大小与版本号。
2. 对比体积与哈希，排除传输损坏。
3. 打开字体信息面板，读完整名称、版本号、字符集范围。
4. 用覆盖常用字、标点、数字、生僻字、繁体的测试字串排一段文字，定位方框出现的区段。
5. 判断方框是集中在生僻字区（覆盖问题），还是从头一个字开始（文件或安装问题）。
6. 若是安装问题，清字体缓存、处理同名字体冲突，再重启软件确认。
7. 若是覆盖问题且项目必须用到那些字，换一款字符集更完整的字，或改用客户端激活后预览确认。
8. 批量场景把这套判断写成脚本，输出 CSV 台账，按批次复核。

六、小结

校验完整性不是一件事，是三件事的合并：文件是否完整、字符是否覆盖、安装是否生效。三条路径对应三种规模——偶发问题用系统自带能力手动查，日常高频用字把来源收进字由客户端，资产成规模就上脚本做批量体检。

一条经验值得记住：先看体积和哈希，再看字符映射，最后才怀疑安装环境。这个顺序能挡掉大部分无效折腾。真正需要逐字确认的，往往不是文件坏了，而是这款字本来就没打算做那么多字。