字体文件检查实战:读懂 TTF/OTF/WOFF 里的字体信息

接手别人交付的字体包,最常见的麻烦不是字体丑,而是搞不清手里这个文件到底是什么。文件名写着 Brand-Bold.ttf,真正装进系统后却显示成另一个名字;CSS 里写了 font-family: BrandSans,浏览器却悄悄回退到默认黑体。要避开这些坑,得先把字体文件里的元数据读出来看清楚。

字体文件里到底存了哪些信息

TTF 和 OTF 本质上是 sfnt 容器,里面按"表"组织数据。和我们排查关系最大的是 name 表,它存着一组带编号的字符串:字族名(family)、子族名(subfamily,通常是 Regular / Bold / Italic)、完整名称(full name)、PostScript 名、版本字符串,还有版权和商标声明。除此之外,head 表里的 units per em 决定坐标精度,maxp 表里的 glyph count 告诉你这个文件收了多少字形,table list 则列出文件包含的全部表。

这些字段里,最容易被忽视又最爱出问题的是 PostScript 名。设计工具、PDF 内嵌、部分字体加载流程都按它来认字体,它和文件名几乎从不一致。文件名你能随便改,内部的 family 名和 PostScript 名却写死在字体里。

读一个真实字体文件能看到什么

举个我实际跑过的例子。一个标着 SourceHan-Medium.otf 的文件,读出来的字段大致是这样:容器格式 OTF(CFF),字族名 Source Han Sans SC,子族 Medium,完整名称 Source Han Sans SC Medium,PostScript 名 SourceHanSansSC-Medium,版本 Version 2.004,units per em 1000,字形数约 65535,表清单里能看到 CFF、name、cmap、GSUB、GPOS 等。

光这几行就解决了三个问题:CSS 里该写的 font-family 是 Source Han Sans SC 而不是文件名;它是思源黑体的简体子集而非全 CJK,字形数和 cmap 决定了它支不支持你要用的生僻字;版本号 2.004 可以和团队记录里的其它副本比对,确认没人塞了个旧版进来。

确认授权和支持的字符集

字体检查器不替你做授权判定,这点要先说清楚:它只读技术元数据,真正的许可范围仍要看你和字体厂商签的协议。但 name 表里的版权与商标字符串能帮你定位"这字体到底是谁家的、哪个版本",再去对照授权文件就快多了。

字符集这一块,字形数量加 cmap 表能给出一个粗判断:几百个字形多半是纯西文字体,上万个字形才可能覆盖中文常用字。真要确认某个具体汉字是否被收录,还得看 cmap 的映射,但字形总数已经能帮你第一时间把"明显不够用"的字体筛掉。

网页字体优化怎么用得上

做 web 字体优化时,这些信息是规划子集化和加载策略的前提。我自己的习惯是:在把字体丢进仓库前,先用字体文件检查器把内部名称、字重、字形数全导成 CSV,和授权来源、文件哈希一起存档。这样后面写 @font-face 时直接照内部 family 名填,不会再出现声明和实际名称对不上、浏览器静默 fallback 的情况。

字形数还能反推子集化的收益:一个上万字形的中文字体,如果页面只用到几百个汉字,subset 后体积能砍掉九成以上,这是首屏字体优化里回报最高的一步。

本地解析,字体不上传

字体文件常常带授权限制,不该随便传到第三方服务器。这个工具把字体表的解析全部放在浏览器里完成,CSV 也在本地生成,字体文件本身不会离开你的电脑。配合记录来源,建议同时把每个字体文件的哈希也存一份,用文件哈希计算器生成,日后排查"这是不是同一个文件"就有据可查。

把字体文件当成会变化的资产来管理,而不是丢进 fonts/ 就不管,出问题的概率会低很多。先看清内部信息,再决定怎么用,这一步省下的返工时间,远比读一遍元数据花的几秒钟多。

---

Made by Toolora · Updated 2026-06-13