TTF vs OTF vs WOFF2：字体格式大比拼
这三种格式的简史
TrueType (TTF) 诞生于 1989 年，是 Apple 和 Microsoft 合作的产物。他们的目标是让操作系统能直接控制字体渲染，从而摆脱对 Adobe PostScript 授权的依赖。一个 TTF 文件将字形轮廓存储为二次贝塞尔曲线，并把所有信息——字形度量、Hinting 指令、字距调整表——都打包进一个二进制文件里。在 90 年代的大部分时间里，它都是 Windows 和 macOS 上无可争议的桌面字体之王。 接着，OpenType (OTF) 在 1996 年问世，由 Microsoft 开发，Adobe 很快也加入其中。OpenType 并没有从零开始，而是巧妙地扩展了 TrueType 容器。一个 OTF 文件既可以使用 TrueType 的二次曲线，也可以使用 Adobe 的三次 PostScript 曲线（CFF 轮廓），这就是为什么你会看到“基于 CFF 的 OTF”这种说法。更重要的是，该格式引入了一套强大的布局表——GSUB 和 GPOS——从而解锁了连字、小型大写字母、花体字和上下文替换等特性。一个为阿拉伯语等复杂文种设计的精密 OTF 字体，可能包含数千条字形替换规则。 WOFF2 (Web Open Font Format 2) 则完全是另一码事。它在 2018 年被 W3C 批准为推荐标准，它不是一种新的轮廓格式，而是一种超高效的压缩封装格式。它接收一个现有的 TTF 或 OTF 文件，应用 Brotli 压缩和一种特殊的字体感知预处理步骤，最终输出的文件通常要小 30-50%。WOFF2 是专为 Web 传输而生的。浏览器会动态解压它，所以它甚至从未接触过你的操作系统字体管理器。理解这个区别——轮廓格式 vs. 传输格式——是掌握如何使用它们的关键。
文件大小与压缩：真正重要的数据
原始文件大小直接影响到你的痛点：页面加载时间、应用包大小和 CDN 带宽成本。我们来看一些具体数字。像 Source Sans Pro Regular 这样中等复杂度的拉丁字体，作为 TTF 文件大约有 260 KB。而使用更高效 CFF 轮廓的 OTF 版本大约是 155 KB。这是因为 CFF 的三次曲线通常能用比 TrueType 的二次曲线更少的点来描述形状，导致基于 CFF 的 OTF 在拉丁文种中要小 20-40%。现在，把同样的字体转换为 WOFF2，你会得到一个大约 75 KB 的文件。这比原始的 TTF 文件减少了整整 71%。 对于 CJK（中日韩）字体，情况就不同了。一个全覆盖的 CJK TTF 字体，比如 Noto Sans CJK SC，大小可能膨胀到 20 MB 以上。WOFF2 压缩有帮助，也许能把它降到 13-15 MB，但这并非万能药。对于超大字体，真正的解决方案是子集化（subsetting），这是一个与简单格式转换不同的过程。单靠 WOFF2 无法拯救一个拥有 65,000 个字形的字体。 至于 WOFF（版本 1），它基本上已经是老古董了。它使用 zlib 压缩，并已被 WOFF2 完全取代。根据 caniuse.com 的数据，WOFF2 的支持率早在 2024 年就达到了全球用户的 97% 以上，覆盖了所有你关心的现代浏览器。唯一的“钉子户”是那些仍在使用 Internet Explorer 11 的老旧嵌入式浏览器或信息亭。对于任何新的 Web 项目，WOFF2 不仅是最佳选择，更是唯一明智的选择。
OpenType 特性：OTF 真正超越 TTF 的地方
一款好的 OTF 和 TTF 之间最重要的技术区别在于能否使用高级的 OpenType 布局特性。虽然理论上两种文件类型都可以包含必要的 GSUB（字形替换）和 GPOS（字形定位）表，但专业的字体厂商几乎只在他们的 OTF 版本中构建丰富的特性集。在现实世界里，好东西都在 OTF 里。 这些特性具体有什么用？连字（Ligatures）会将像“fi”和“fl”这样的常见序列替换为单个精心设计的字形，以防止碰撞。任意连字（Discretionary ligatures）更进一步，巧妙地组合像“ct”或“Th”这样的字母对，增添书法般的韵味。小型大写字母（Small caps）会用光学上调整过尺寸的较小版本替换全高大写字母——这些是重新绘制的字形，而不仅仅是缩小了的字母。旧式数字（Oldstyle figures）让你得到带有上伸部和下伸部的数字，使它们能优美地融入一行文本中。像 Minion Pro 这样的字体，单个 OTF 文件可能包含超过 1700 个字形和几十种这样的特性，标记为 'onum'、'smcp'、'calt'、'swsh' 和 'hist'。 在 CSS 中，你可以通过 `font-feature-settings: 'onum' 1;` 或 `font-variant-numeric: oldstyle-nums;` 来启用它们。在 Adobe InDesign 中，你可以在“文字”>“OpenType”菜单下找到它们。即使是 Microsoft Word 365，在高级字体对话框中也有一些支持，尽管不如 Adobe 的工具全面。 一个没有这些表的 TTF 文件，无论在哪个应用程序中，都无法提供这些功能。如果你的设计依赖于标准的小型大写字母、上下文替换，或是像阿拉伯文或梵文那样需要复杂塑形的文种，那么 OTF 就不再是偏好问题，而是一个硬性要求。
字体提示 (Hinting) 与渲染：桌面与屏幕环境的差异
字体提示（Hinting）是字体文件内部的一组指令，用于调整字形轮廓，使其在屏幕上以小字号显示时看起来清晰锐利。任何曾费力看过模糊的 12px 文本的人都懂渲染不佳的痛苦；Hinting 就是解药。没有它，小写字母 'n' 的一个竖笔画可能是一像素宽，而另一个是两像素，造成难看、不均匀的外观。好的 Hinting 能将这些笔画对齐到像素网格上。 TTF 字体以其手动的 TrueType Hinting 而闻名，这是一种复杂的字节码语言，让设计师能够对每个像素进行精细控制。这是一项极其耗费人力的工作——一个像 Arial 这样经过完全手动 Hinting 的字体代表了数百小时的劳动。在早期使用 GDI 渲染器的 Windows 系统上，这种付出回报巨大。 基于 CFF 的 OTF 字体使用更简单的 PostScript Hinting。在 macOS 上，由于其渲染器长期以来基本忽略 Hinting，这种差异无关紧要。在 Windows 上，ClearType 渲染器（自 Vista 以来的默认设置）已大大缩小了差距。而在高 DPI 显示器上——基本上是任何现代手机或“视网膜”屏幕——Hinting 变得几乎无关紧要。像素点实在太小了，以至于那些网格对齐问题根本不会出现。 WOFF2 并没有改变 Hinting 的状况；它只是保留了它所压缩的原始字体中的 Hinting 数据。如果你转换一个经过良好 Hinting 的 TTF，这些提示会一并保留下来。实际的结论是？如果你的主要用户使用的是非高清的 Windows 显示器，并且你显示的文本小于 16px，那么一个手动 Hinting 的 TTF 仍然有可见的优势。对于在现代硬件上的网页应用，这种差异几乎不可能被察觉。
何时使用何种格式：实用决策指南
对于桌面安装——在你的操作系统、设计应用或办公套件中——你需要 TTF 或 OTF。Windows 和 macOS 都原生支持这两种格式，Linux 发行版也是如此。决定取决于你的需求。如果你是一名设计师，需要在 InDesign 中使用连字、花体字和其他高级排版功能，那你想要的是 OTF。如果你是一名 IT 管理员，要在一大批 Windows 机器上部署公司字体，那么一个经过 Hinting 的 TTF 通常是更安全、兼容性更好的选择。 Web 传输很简单：用 WOFF2。就这样。你的 CSS `@font-face` 声明应该总是将 WOFF2 列在首位：`src: url('font.woff2') format('woff2'), url('font.woff') format('woff');`。在网页上直接提供原始的 TTF 或 OTF 文件简直是性能上的犯罪。你强迫用户下载比必要多 2-3 倍的数据。如果你看到一个老旧主题的样式表中引用了 .ttf 文件，把它换成 WOFF2 是一个快速简单的性能提升方法。 移动应用是另一回事。iOS 和 Android 都在应用包内原生使用 TTF 和 OTF 文件；它们都不会为此目的使用 WOFF2，因为它是一个仅用于浏览器的传输格式。Flutter 应用将 TTF 或 OTF 打包在 assets 目录中，并在 `pubspec.yaml` 中声明，React Native 也遵循类似的模式。 游戏引擎有自己的偏好。Unity 的 TextMeshPro 使用 OTF 和 TTF 来生成其字体资源。Unreal Engine 的导入器更喜欢 TTF。两者都不能直接导入 WOFF2 文件，所以如果你只有 WOFF2，你需要先把它转换回 TTF 或 OTF。
使用 CocoConvert 进行格式转换
需要在这些格式之间切换吗？CocoConvert 处理最关键的转换路径：TTF 到 WOFF2、OTF 到 WOFF2、WOFF2 到 TTF，甚至 OTF 到 TTF。我们的处理过程由 `fonttools` 驱动，这是 Google Fonts 也在使用的行业标准 Python 库。这确保了你转换后的文件符合标准，并且像 GSUB、GPOS、名称记录和 Hinting 数据这样的 OpenType 表得以保留。 要创建一个适合网页的字体，只需在我们的字体转换页面上传你的 .ttf 文件，选择 WOFF2 作为输出，然后点击转换。一个典型的拉丁字体在几秒钟内就能处理完毕。生成的 WOFF2 文件保留了原始文件的所有度量和布局特性，默认情况下不会删减任何内容。 当然，CocoConvert 并非万能。它不进行子集化（subsetting）。如果你转换一个 20 MB 的 CJK 字体，你会得到一个压缩后的 13 MB 的 WOFF2 文件，而不是一个只包含你需要字符的 50 KB 的精简文件。要实现后者，你需要像 `pyftsubset` 这样的专用工具。CocoConvert 也不会修改授权元数据。如果一个字体的嵌入标志（fsType）限制其在网页上使用，这个标志在转换后的文件中仍然存在。请记住：转换字体格式并不会改变它的授权许可。如果你没有在网页上使用某款字体的权利，将其转换为 WOFF2 并不会使其合法化。 当你发现一个网页字体并需要将其安装到桌面使用时，将 WOFF2 转换回 TTF 非常有用。解压是无损的，这意味着生成的 TTF 文件的轮廓数据与原始来源的字节完全相同。转换过程会干净地逆转任何 WOFF2 特有的优化，给你一个完全可用的桌面文件。
总结：告别纠结，轻松选择正确格式
我们来拨开迷雾，直奔主题。这三种格式并非可以互换的替代品，而是用于不同工作的不同工具。 TTF 是万能适配器。所有处理字体的平台都能应对 TTF。当你需要最大兼容性、目标是旧的 Windows 环境（其特定的 Hinting 在那里能大放异彩），或者当游戏引擎等工具指定要求时，它就是正确的选择。它的主要弱点是文件大小比基于 CFF 的 OTF 更大，并且通常缺少高级排版功能。 OTF 是专业人士进行桌面工作的首选。当字体厂商为严肃的设计工作销售字体时，你想要的就是 OTF 版本。它包含完整的 OpenType 特性集，其 CFF 轮廓很紧凑，并且所有现代设计应用都支持它。它唯一的真正缺点是对于网页传输来说太臃肿了。通过 HTTP 提供原始 OTF 文件纯属浪费带宽。 WOFF2 只为一件事而生：网页。它不是一种新型字体，只是为浏览器巧妙压缩的现有字体。在你的 `@font-face` 规则中使用 WOFF2。永远如此。保留原始的 TTF 或 OTF 作为源文件，但将 WOFF2 视为一次性的、为传输而优化的资源。 这里是任何新项目的简单工作流程：从字体厂商那里获取高质量的 OTF 字体。使用 CocoConvert 为你的网站创建一个 WOFF2 版本。保留原始的 OTF 用于任何印刷或设计工作。如果你某天只有一个 WOFF2 文件却需要在桌面上使用它，就把它转换回 TTF。就是这么简单直接。