简介：这份资源面向在 Ubuntu 系统下使用 WPS 办公软件、却频繁遇到字体缺失提示的用户，尤其是需要处理含特殊符号文档的办公与排版人群。当 WPS 弹出缺少 Symbol、Wingdings、Wingdings 2、Wingdings 3 等字体的警告时，文档中的符号与图形往往显示为问号或空缺，该字体集正是为补齐这一缺口而整理。压缩包共收录 129 个文件，以 128 个 TTF 字体文件和 1 个 install.sh 安装脚本为主，整体约 58.08MB，字体文件覆盖多种符号与西文字形，脚本则用于批量写入系统字体目录。目前已有 1434 人学习下载，说明该问题在 Ubuntu 与 WPS 组合中较为普遍。使用者解压后进入 ttf-wps-fonts 目录执行脚本即可完成安装，无需逐个手动添加字体，能较快恢复文档符号的正常显示，减少排版返工，适合作为 Ubuntu 下 WPS 字体环境的常备补充包。
1. Ubuntu 下 WPS 字体缺失：从满屏方块到正常显示的排查路径
在 Ubuntu 上打开一份别人发来的文档，标题、正文全变成方块或问号，第一反应往往是“WPS 又崩了”。其实多数情况下不是 WPS 本身的问题，而是系统里根本没有文档指定的那几款字体。WPS 在 Linux 下走的是系统字体回退链路，一旦找不到对应字体，就会用默认字体硬顶，遇到中文字体缺失时直接渲染成方块。这个标题要解决的就是：在 Ubuntu 系统下，WPS 软件提示字体缺失、文档显示异常时，怎么定位缺了哪些字体、怎么补齐、怎么让 WPS 重新认到。适合两类人：一是刚在 Ubuntu 上装完 WPS 发现中文显示不正常的新手，二是需要批量处理文档、对排版还原度有要求的办公用户。下面按“先看清缺什么，再决定补什么”的顺序拆开讲。
2. 先搞清楚 WPS 到底缺了哪些字体：定位与诊断
2.1 从 WPS 的字体替换提示反查缺失项
WPS 打开文档时如果字体缺失，通常会在顶部或弹窗里给出替换提示，列出“原字体”和“替换为”。但弹窗一闪而过，或者只显示一部分。更稳的做法是直接看文档里用了哪些字体。用 Python 的python-docx或docx2txt可以快速提取 docx 中引用的字体名，先拿到一份“需求清单”。
# extract_fonts.py # 用途：从 docx 中提取所有 run 级别引用的字体名，去重后输出 from docx import Document from docx.oxml.ns import qn def get_run_fonts(run): """读取 run 的字体设置，包括 ascii、eastAsia、hAnsi 三类""" fonts = set() rPr = run._element.rPr if rPr is not None: rFonts = rPr.find(qn('w:rFonts')) if rFonts is not None: for attr in ['w:ascii', 'w:eastAsia', 'w:hAnsi', 'w:cs']: val = rFonts.get(qn(attr)) if val: fonts.add(val) return fonts doc = Document('sample.docx') all_fonts = set() for para in doc.paragraphs: for run in para.runs: all_fonts |= get_run_fonts(run) # 表格里的文字也要扫 for table in doc.tables: for row in table.rows: for cell in row.cells: for para in cell.paragraphs: for run in para.runs: all_fonts |= get_run_fonts(run) for f in sorted(all_fonts): print(f)这段脚本的关键点在于w:rFonts节点，它下面有ascii、eastAsia、hAnsi、cs四个属性，分别对应西文、中文、复杂文本等场景。很多人只查ascii，结果漏掉中文字体。跑完拿到字体列表后，再和系统已装字体做差集，就知道缺哪些了。
2.2 用 fc-list 和 fc-match 确认系统字体现状
拿到文档需要的字体名后，下一步是看系统里有没有。fc-list列出所有已装字体，fc-match则模拟一次字体匹配，告诉你“如果请求某个字体，系统实际会给什么”。
# 列出所有中文字体（按 family 去重） fc-list :lang=zh family | sort -u # 检查某个具体字体是否存在，比如宋体 fc-list | grep -i "simsun" # 模拟匹配：请求“宋体”，看系统实际返回什么 fc-match "宋体" fc-match "SimSun" fc-match "Times New Roman"fc-match的输出格式是“实际字体文件: 实际 family 名”。如果请求“宋体”却返回“DejaVu Sans”，说明系统里没有宋体，WPS 就会用 DejaVu 去渲染中文，方块基本跑不掉。这里有个细节：中文字体在 fontconfig 里往往有多个别名，比如“宋体”可能对应SimSun、NSimSun、Songti SC等，fc-match要分别试。
2.3 判断是“缺字体”还是“字体被禁用”
有时候字体文件明明在/usr/share/fonts下，WPS 却还是提示缺失。常见原因是字体缓存没更新，或者字体文件权限不对，再或者 fontconfig 的配置文件里把某类字体排除了。先跑一遍缓存重建：
# 重建用户级和系统级字体缓存 fc-cache -fv # 查看某个字体文件是否被 fontconfig 识别 fc-scan /usr/share/fonts/truetype/custom/yourfont.ttf如果fc-scan能读出 family 名，但fc-list里没有，多半是缓存路径没覆盖到。检查/etc/fonts/fonts.conf里的<dir>列表，确认你的字体目录在扫描范围内。这一步能排除掉“文件在但系统不认”的玄学问题。
3. 补齐字体：从 Windows 字体迁移到开源替代
3.1 从已有 Windows 环境提取字体文件
最直接的办法是把 Windows 系统里的字体复制过来。Windows 字体主要在C:\Windows\Fonts下，常见的中文字体包括：
| 字体文件 | 对应字体名 | 用途 |
|---|---|---|
| simsun.ttc | 宋体 / SimSun | 正文中文 |
| simhei.ttf | 黑体 / SimHei | 标题中文 |
| msyh.ttc | 微软雅黑 / Microsoft YaHei | 界面与正文 |
| simkai.ttf | 楷体 / KaiTi | 特殊排版 |
| simfang.ttf | 仿宋 / FangSong | 公文排版 |
| times.ttf | Times New Roman | 西文正文 |
| arial.ttf | Arial | 西文标题 |
复制时注意.ttc是字体集合，一个文件里可能包含多个字体，直接拷到 Ubuntu 的字体目录即可。建议单独建一个目录，比如/usr/share/fonts/wps-fonts/，避免和系统自带字体混在一起，后续排查方便。
# 创建专用字体目录 sudo mkdir -p /usr/share/fonts/wps-fonts # 假设字体文件已经放在 ~/fonts-backup 下 sudo cp ~/fonts-backup/*.ttf ~/fonts-backup/*.ttc /usr/share/fonts/wps-fonts/ # 修正权限，保证所有用户可读 sudo chmod 644 /usr/share/fonts/wps-fonts/* sudo chown root:root /usr/share/fonts/wps-fonts/* # 重建缓存 sudo fc-cache -fv权限这一步别省。如果字体文件是 600，WPS 以普通用户运行时读不到，表现就是“明明装了却还是方块”。chmod 644是血泪经验，很多人卡在这里。
3.2 用开源字体做合规替代
如果手头没有 Windows 环境，或者不想直接迁移商业字体，可以用开源中文字体做映射替代。常见组合是：
- 思源黑体（Source Han Sans / Noto Sans CJK）替代微软雅黑、黑体
- 思源宋体（Source Han Serif / Noto Serif CJK）替代宋体
- 文泉驿系列作为补充
安装后，通过 fontconfig 的别名配置，让系统在请求“宋体”时自动回退到思源宋体。这样文档里的字体名不用改，WPS 也能正常渲染。
<!-- /etc/fonts/conf.d/99-wps-fallback.conf --> <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <!-- 把常见 Windows 中文字体名映射到开源字体 --> <match target="pattern"> <test name="family"><string>SimSun</string></test> <edit name="family" mode="assign" binding="strong"> <string>Noto Serif CJK SC</string> </edit> </match> <match target="pattern"> <test name="family"><string>宋体</string></test> <edit name="family" mode="assign" binding="strong"> <string>Noto Serif CJK SC</string> </edit> </match> <match target="pattern"> <test name="family"><string>Microsoft YaHei</string></test> <edit name="family" mode="assign" binding="strong"> <string>Noto Sans CJK SC</string> </edit> </match> <match target="pattern"> <test name="family"><string>微软雅黑</string></test> <edit name="family" mode="assign" binding="strong"> <string>Noto Sans CJK SC</string> </edit> </match> </fontconfig>配置里binding="strong"表示强制替换，优先级最高。改完执行fc-cache -fv，再用fc-match "宋体"验证，应该返回 Noto Serif CJK SC。这种做法的好处是合规、可批量部署，缺点是部分精细排版（比如特定字重、特殊符号）和原字体仍有差异，正式公文场景要谨慎。
3.3 让 WPS 重新加载字体
字体装好后，WPS 不一定立刻认到。最稳妥的是完全退出 WPS 进程再重启，包括后台的wpscloudsvr之类。
# 查看当前 WPS 相关进程 ps aux | grep -i wps # 全部结束（注意保存文档） pkill -f wps # 重新启动 wps如果重启后仍不认，检查 WPS 的字体缓存目录。WPS 在用户目录下可能有自己的缓存，路径通常在~/.local/share/Kingsoft/或~/.config/Kingsoft/下。删掉缓存目录再启动，让它重新扫描系统字体。
# 备份后清理 WPS 缓存（路径以实际安装为准） mv ~/.local/share/Kingsoft ~/.local/share/Kingsoft.bak wps这一步相当于给 WPS 一次“后悔药”，让它忘掉旧的字体列表重新来。
4. 避坑与常见问题排查
4.1 装了字体但 WPS 里还是方块
现象：fc-list能看到字体，fc-match也正常，但 WPS 打开文档依旧方块。 原因：WPS 进程在字体安装前就已启动，或者字体缓存没刷新到 WPS 能读到的层级。 解决：先fc-cache -fv，再彻底杀掉 WPS 所有进程（包括托盘进程），重新启动。仍不行就清理 WPS 用户缓存目录。
4.2 字体名对不上导致回退失效
现象：配置了别名映射，但fc-match "宋体"返回的还是默认字体。 原因：fontconfig 配置文件名排序问题，或者family名写错。中文字体名在不同文件里可能是“宋体”“SimSun”“NSimSun”，要逐个测。 解决：把配置文件命名为99-开头保证最后加载，用fc-match逐个验证别名，必要时在配置里同时写多个<test>。
4.3 权限问题导致普通用户读不到字体
现象：root 下fc-list能看到，普通用户看不到。 原因：字体文件权限是 600 或目录权限是 700。 解决：chmod 644字体文件，chmod 755字体目录，确保o+r和o+x。
4.4 .ttc 字体集合只识别出第一个字体
现象：复制了simsun.ttc，但系统里只出现一个字体名。 原因：部分旧版 fontconfig 对 ttc 支持不完整，或者 WPS 只读了第一个 face。 解决：用fc-scan确认 ttc 里包含几个 face；如果确实只认一个，可以用fonttools把 ttc 拆成多个 ttf 再安装。
# 用 fonttools 查看 ttc 包含的字体 python3 -c "from fontTools.ttLib import TTCollection; ttc=TTCollection('simsun.ttc'); print([f['name'].getDebugName(1) for f in ttc.fonts])"4.5 文档里嵌入了字体但 WPS 不调用
现象：docx 里嵌入了字体子集，但 WPS 仍提示缺失。 原因：WPS Linux 版对嵌入式字体的支持有限，很多版本不解析w:embedRegular等节点。 解决：不要依赖嵌入字体，直接在系统层补齐对应字体，或者用 LibreOffice 先转换一遍再打开。
5. 批量验证与长期维护：把字体问题挡在打开文档之前
单次修好不算完，办公场景里文档是持续来的，今天补了宋体，明天可能来一份用方正字体的。更省事的做法是建一个“字体预检”脚本，在打开文档前先跑一遍，把缺失字体列出来，再决定是补字体还是做映射。
#!/bin/bash # check_fonts.sh # 用法：./check_fonts.sh sample.docx # 输出：文档引用但系统缺失的字体列表 DOC="$1" if [ -z "$DOC" ]; then echo "用法: $0 <docx文件>" exit 1 fi # 提取文档字体（依赖前面的 extract_fonts.py） FONTS=$(python3 extract_fonts.py "$DOC") echo "文档引用的字体：" echo "$FONTS" echo "---" echo "系统缺失的字体：" while IFS= read -r font; do [ -z "$font" ] && continue # fc-match 返回的实际 family 如果和请求不一致，视为缺失 MATCHED=$(fc-match "$font" family 2>/dev/null | head -1) if [ "$MATCHED" != "$font" ]; then echo "缺失: $font -> 实际匹配: $MATCHED" fi done <<< "$FONTS"这个脚本的逻辑是：对每个文档字体名调fc-match，如果返回的 family 和请求名不一致，就说明系统没有精确匹配，WPS 会走回退。把输出结果攒起来，就能形成一份“常用缺失字体清单”，后续一次性补齐。
长期维护上，我一般会做三件事。第一，把常用字体目录/usr/share/fonts/wps-fonts/做成一个可同步的包，换机器时直接拷过去再fc-cache -fv。第二，把 fontconfig 别名配置纳入版本管理，新装系统时直接软链到/etc/fonts/conf.d/。第三，定期跑一次fc-cache -fv并检查fc-list :lang=zh的输出，确认中文字体数量没有异常减少。这套习惯坚持下来，WPS 字体缺失基本不会再成为打开文档时的意外。希望帮到你。
本文还有配套的精品资源，点击获取
