简历应该以 PDF 还是 Word 文件发送？

简短的回答

大型系统两种格式都接受。除非招聘启事要求 PDF，否则 Word 文件是更稳妥的选择，因为它把您的文字存储为普通字母，别无其他。如果您确实要发送 PDF，请用文字处理软件中的“另存为 PDF”来生成，而不要把网页打印成 PDF。区别不在于 PDF 的外观，而在于您看到的字母背后存储的是什么。

系统厂商自己怎么说

这些软件背后的公司彼此意见不一。Textkernel 的解析器内嵌于许多此类系统之中，它对基于其产品进行开发的公司说：“如果您想尽量减少转换问题，就不要使用 PDF 文档”，并补充说“PDF 是一个有缺陷的标准，常常掩盖底层文本的问题”（Textkernel，入门指南 （在新标签页中打开））。Greenhouse 是使用最广泛的系统之一，它在自己的帮助页面上对求职者说的恰恰相反：“上传 PDF 以获得最佳效果”（Greenhouse，MyGreenhouse 常见问题 （在新标签页中打开））。Indeed 的职业指南则持中间立场：使用 PDF 时，“无法保证雇主使用的 ATS 能够查看和扫描您的简历”（Indeed 职业指南 （在新标签页中打开））。

在其他方面，它们的意见都一致。

PDF 里面有什么

Word 文件把您的简历存储为文本：按顺序排列的字母，以及围绕它们的格式。PDF 存储的东西更接近一幅图画。对每个字母，它记录要画哪个形状、画在哪里，另外还有一张小小的对照表，告诉程序每个形状代表哪些字母。解析器读取 PDF 时，读的是这张对照表，而不是形状。

连字是用一个形状取代两三个字母。在许多字体中，f 和 i 挨在一起会显得别扭，所以字体为 fi 准备了一个现成的形状，为 fl 准备了另一个，为 ffi 也准备了一个。Unicode 是为每种语言的每个字符编号的标准，它甚至为这些连字分配了单独的编码（Unicode, Alphabetic Presentation Forms （在新标签页中打开））。这是否要紧，完全取决于对照表说形状背后是什么：是普通字母 f、f 和 i，还是代表 ffi 的单个编码。

测试

2026年10月7日，我为一位名叫“Alex Fictional”的虚构办公室经理制作了一份简历，里面塞满了29个容易产生连字的词：Office、Officer、efficient、certified、workflow、Affinity、Staffing、traffic、specifications、Qualifications 等等。我用三种方式把它转换成 PDF：在 Microsoft Word（Windows 版 Microsoft 365）中“另存为 PDF”，在 Google Docs 中“下载为 PDF”，以及在 Chrome 浏览器中“打印为 PDF”，许多网页版简历制作工具就是这样生成文件的。我在 Chrome 中使用了八种字体，在 Word 中使用了 Calibri 和 Aptos，在 Google Docs 中使用了 Calibri、Arial 和 Georgia。

然后，我把每个文件中的文本读出两次，一次用会把特殊字符还原为字母的读取程序（Adapt to Success 就是这样做的），一次用完全按存储原样读取文本的程序，并逐一搜索这29个词。

我没有测试的：Mac 上的 Word、Canva 和其他在线简历制作工具，以及那些真正的系统本身，因为它们需要雇主账户。所以本文告诉您的是文件里有什么，而不是某个特定的 ATS 会如何处理这些文件。

我的发现

Jerry 提议用一个大大的“Office”来展示有无连字的区别，下图就是这样做的，我只补充了一样东西：形状背后存储的字母。

* 一份只含其中六个词的较短测试文档。使用 Word 的默认设置时，根本没有绘制任何连字。

有三点值得注意。第一，Jerry 是对的：在 Word 中开启连字后，连字确实会进入 PDF，连体形状就在那里。第二，Word 在这个形状背后存储的是普通字母，所以我试过的每个读取程序都仍然找到了这些词。第三，Chrome 画出的形状完全相同，但在其背后存储的是单个 ffi 字符。在 Calibri 文件中，按存储原样读取文本的程序只找到了29个词中的3个。

下面是读取程序从这两个文件中实际得到的文本，展示的是同一个差异，每个连字字符都标在方框里：

说句公道话，Chrome 还会在 PDF 中一个可选的附加字段里存储真实字母，我试过的读取程序中就有一个找到了全部29个词。雇主系统内部的读取程序是否也会这样做，这才是问题的关键。

哪些程序会把它还原成字母

Mozilla 的 pdf.js 运行在 Firefox 和 Adapt to Success 内部，它默认进行规范化，只有开发者将其关闭时才会停止（pdf.js 源代码 （在新标签页中打开））。许多服务器系统使用的 Apache PDFBox 会对读取的每一行进行规范化，并附注说明它会“将单个‘fi’连字转换为‘f’和‘i’”（Apache PDFBox 源代码 （在新标签页中打开））。PyMuPDF 是开发者用 Python 构建简历解析器时的热门选择，它默认的做法正好相反：连字“以原始形式传递给应用程序”（PyMuPDF 文档 （在新标签页中打开））。Sensible 是一家以从 PDF 中提取数据为业的公司，它提醒自己的用户：“即使渲染出的文档看起来没问题，提取出的文本中仍可能存在连字”（Sensible，连字 （在新标签页中打开））。

某个雇主的系统内部用的是其中哪一种，您从外部是看不到的。说到底，这才是优先选择一种根本不会出现这个问题的文件的真正理由。

被绊倒的不只是软件

屏幕阅读器读取的是同一个文本层。Minnesota IT Services 测试了用 Adobe InDesign 和 Adobe Illustrator 制作的含连字的 PDF。来自 Illustrator 以及旧版 InDesign 的文件存在字符编码错误，而测试中最新版本的 InDesign 则没有。在一个来自 Illustrator 的测试文件中，JAWS 屏幕阅读器把“coffee”读成了“Coee”，把“flavor”读成了“avor”（Minnesota IT Services，2021 （在新标签页中打开））。英国交通部（Department for Transport）给员工的指南说，连字“可能导致无障碍问题，尤其是对屏幕阅读器而言”，并要求员工在 Word 中把“连字”设置为“无”（Department for Transport，2025 （在新标签页中打开））。两者都与简历无关，但使用屏幕阅读器的招聘人员也是以同样的方式读您的简历。

Word 文件也会出问题

这一切并不意味着 Word 文件天生就安全。上面厂商清单上的几乎每一项都与文件类型无关：表格、放着您电话号码的文本框，或者双栏模板，在 Word 中造成的麻烦与在 PDF 中一样。设有密码保护的 Word 文件和被锁定的 PDF 一样必定失败。把姓名放在文本框里的 Word 文件，可能比一份干净的 PDF 还糟。

我自己的简历在软件眼中是什么样子

写这篇文章之前，我把投那些申请时用的简历放进同样的读取程序里跑了一遍。那是一份用 Calibri 字体、从 Word 保存的 PDF，里面完全没有连字字符，所以连字从来不是我的问题。排版才是。两个读取程序以两种不同的顺序读取了同一个文件。pdf.js（Firefox 和 Adapt to Success 内部的读取程序）先读的是我页脚里的页码“Side 1 af 2”（丹麦语的“第1页，共2页”，留在了一份英文简历的页脚里），接着读侧栏里的 Ambitions 栏和我的联系方式，最后才读到我的名字。Xpdf 的 pdftotext 先读到我的名字，却把 Ambitions 栏塞进了我工作经历的中间，夹在两份工作之间。同一个文件，两个不同的故事，而哪一个都不是我设计的样子。

这对您意味着什么

除非招聘启事要求 PDF，否则就发送 Word。如果您需要 PDF，请用 Word 中的“另存为 PDF”或 Google Docs 中的“下载”来生成，而不要把网页或在线简历制作工具的预览打印成 PDF。无论发送哪一种，都要保持排版简单：单栏、真正的标题、联系方式放在页面正文里。文件类型远不如文件里的内容重要。

一条评论能做到什么

Jerry 的评论花了我一天时间，而这是本系列到目前为止花得最值的一天。问题其实从来不是 PDF 还是 Word，而是您看到的字母背后藏着什么，而这一点谁也无法单凭看页面来检查。