WPS 打开 docx 一片空白？不是没装字体，是嵌入字体作怪

现象

收到一份公文 docx，用 WPS（macOS）打开后，大量汉字变成空白方块/空格——标题和部分正文尤其严重。而发送方（Windows + 方正字库）看着完全正常。

第一反应通常是「我电脑缺字体」——装字体对，但只做这一步不够。

坑一：装了字体还是空白

我先装了方正 GBK 系列（小标宋、仿宋、黑体、楷体），装完打开——还是空白。

这里有个隐藏陷阱：装字体时 WPS 已经开着，它的字体列表是启动时一次性缓存的，不会热刷新。 所以哪怕字体装对了，WPS 仍判定「本地缺字体」，继续用文档里那份坏的嵌入字体渲染。

结论先放这儿：装完字体后，必须彻底退出 WPS 再重开，否则白装。

解包 docx 看真相

docx 本质是个 zip。解包后看 word/fontTable.xml 和 word/fonts/*.odttf，发现作者保存时勾选了「嵌入字体」。内嵌字体是子集（只含文档用到的字符）。逐个解密比对：

内嵌字体	状态	后果
方正仿宋_GBK（正文主体）	字符表登记了 21991 字，但「打、本、研、财、委、社、验、逐、取、以、主」等大量字的字形轮廓是空的（空壳）	正文东一个西一个的空白
方正小标宋_GBK（标题）	子集只有 29 个字，且是从另一份文档（“年度工作情况汇报”之类）带过来的陈旧字符，标题 33 字缺 23 字	标题及撰写说明显示异常
方正黑体_GBK、方正楷体_GBK	完整	正常

关键认知：嵌入字体只负责”把一份字形带过去”，不保证”带的是正确的字形”。 这份文件带过去的字形本身就是残次品，所以接收方无能为力。

技术细节：.odttf 用 fontKey GUID 的前 32 字节异或加密，解密后用 fontTools 读 cmap + glyf 表，就能验证哪些字”有字符映射却无轮廓”——那就是空白的来源。

为什么发送方正常、你空白

OOXML 的渲染规则是：本地装了同名真字体，渲染时优先用本地，文档里嵌的嵌入子集被忽略（嵌入字体只在”接收方没装该字体”时才顶上）。

• 发送方装了完整的方正字库 → 用本地真字体，根本没碰那份坏子集，问题在他机器上完全隐形。
• 你没装（或 WPS 还没识别到）→ 被迫用坏子集 → 空白。

接收方怎么处理（纯 GUI，不碰命令行）

1. 确认字体装对：方正小标宋_GBK、方正仿宋_GBK 等（单位一般有统一办公字体渠道；方正 GBK 个人非商用可在官网下载）。
2. 彻底退出 WPS 再重开（⌘Q 退出程序，不是只关文档）。这一步最关键。
3. 重开后应正常显示，且因用的是本地方正真字体，外观与发送方一致。

若对方也没装字库、你想发一份干净副本：

• 替换字体（最快）：开始 → 替换 → 替换字体，把「方正仿宋_GBK」换成「华文仿宋」（macOS 自带真字体），标题换成「华文宋体」。空白立刻消失，代价是字形变成华文系，但版式/字号不变。
• 剥离内嵌（得原貌）：WPS 文字菜单 → 偏好设置 → 常规与保存 → 取消「将字体嵌入文件」→ 另存为。注意：WPS Mac 有时另存也不剥内嵌，此时命令行脚本最稳（3 秒一份）。

给发送方的建议

• 对方若是同单位（已有方正字库），根本不用嵌字体，直接发即可，对方本地渲染最准。
• 真要嵌，确保字库嵌入权限正常、子集生成完整。否则寄出的是残次品——嵌入字体是”打包寄字形”，不是”显示保险”；寄的是残次品，谁收到都残。

一句话总结

收到带嵌入字体、却显示空白的 docx：先确认字体装对，再彻底退出重开 WPS；WPS 一旦识别到本地方正真字体，会自动旁路那份坏的嵌入子集。规范就是本地优先，卡住的只是字体缓存的刷新。