PDF转换深度指南：从扫描件OCR到转曲与批量处理

前阵子帮同事处理一份 PDF 转 Word 的文档，她的需求一句话就能说清：把 PDF 里那段带排版的文字变成可编辑内容。结果她连着试了三个在线转换网站，来回折腾半个多小时，最后从 Word 复制出来的内容，标题层级全乱了，表格线跑偏，页脚还混进了正文。我过去看了一眼源文件才发现，那份 PDF 根本是扫描图片，没有文字层，普通转换工具转一百遍也很难还原出能编辑的 Word。类似的情况我见了太多次。不管是 pdf转word、pdf转图片、网页打印成 PDF，还是 pdf转曲 这类印前操作，大家搜“PDF 转换其他格式”时，经常把问题想得过于简单。这篇就按实际使用场景把这些转换需求拆开讲，说说每一步背后的判断逻辑、工具选型，以及真正能落地的做法。适合整理合同的办公族、处理印刷文件的排版人员，也包括需要批量解析 PDF 的开发者参考。

1. 先想清楚要把 PDF 变成什么，再决定怎么转

1.1 转换需求其实分四种，别上来就选工具

我接过的 PDF 转换咨询里，至少有九成的人第一步就走错了：他们不判断源文件是什么类型，也不问最终用途是什么，张嘴就是“帮我转一下”。可 PDF 转出来的东西是完全不同的，它可以是 Word、Excel、图片、HTML、纯文本，也可以是印刷文件。不同目标对应着完全不同的技术路线。

日常需求大致能分成四类。第一类是“还原编辑”，也就是你希望把 PDF 变成一个能继续改排版的 Word 或 Excel 文件，这类最看重版式还原度。第二类是“内容提取”，你不需要保留原来的页边距和分页，只需要正文文字、表格数据或里面的图片，这类更看重解析精度和格式干净度。第三类是“交付印刷”，比如把文字转曲、按指定纸张重新打印成 PDF，或者为了发给印刷厂而压缩到指定大小。第四类是“网页存档”，把在线文档或网页内容固化成 PDF，这类通常被称为“从页面打印成 PDF”，但它本质上和打印机驱动的行为有关，和传统 PDF 编辑器没什么关系。

搞清楚类别以后，才轮到选工具。还原编辑类需求首选对排版引擎吃得透的软件，比如 Adobe Acrobat 或 WPS 这类办公套件里的转换功能；内容提取类需求则可以交给命令行工具和开发库，比如 pdfplumber、PyMuPDF、Poppler 系列；印刷交付类要关注的是字体和色彩，而不是编辑能力；网页存档类需要处理的是浏览器打印引擎的 CSS 兼容性和纸张设置。没有一堆万能工具，只有一个最贴合你场景的工具。

1.2 在线工具很快，但我不建议你拿它处理三类文件

在线 PDF 转换站点确实方便，不需要安装软件，拖进去就能转。但我在实际使用中越来越谨慎，主要原因不是效果好不好的问题，而是隐私风险。你上传的 PDF 内容会经过对方的服务器，即便是加密传输，服务方也会有完整的文件副本，有的站点还会在服务器上保留几个小时甚至更久。用于学习资料、无版权要求的公开文档，问题不大，但合同、标书、身份证扫描件、内部技术资料这类东西，我劝你不要轻易上传。

本地处理方案其实没有想象中那么复杂。办公场景装一个 Adobe Acrobat Pro 或者 WPS，就能覆盖大部分 PDF 和 Office 文档互转需求。开发者场景更简单，电脑上装 Python、Poppler 或 Ghostscript 等开源工具，一条命令就能完成批量转换。我经常遇到客户说“某某在线工具把这个 PDF 转出来字体全变了”，折腾半天还不如本地用 Acrobat 两分钟完成。这不是能力差异，而是很多在线工具为节省带宽，会把图片质量、字体嵌入策略压到最低，转换效果自然就没保障。

2. 办公里的常见互换：PDF 与 Word/Excel 怎么转才不乱版

2.1 PDF 转 Word 的三种路径，分别适合什么情况

先说最普遍的场景，PDF 转 Word。很多人对这条路有误解，认为 PDF 转 Word 就是一键“翻译”，不管什么源文件都应该能转出和原稿几乎一致的文档。实际上，要让 Word 里的内容和 PDF 里看起来相同，取决于原始 PDF 的构造方式。如果你的 PDF 是 Word、WPS 或 LaTeX 直接导出的，通常包含文本层、字体子集和基础排版信息，转回 Word 会有较高的还原度。如果你的 PDF 来自扫描仪或手机拍照，它本质上是一张大图片，必须先做 OCR 识别，再用识别结果重建文档，这完全是另一套流程。

我实际测试下来，有三条比较靠谱的路径：

第一条，用 Word 或 WPS 直接打开 PDF 文件。Word 2013 以后内置了一个 PDF 转换引擎，可以直接把 PDF 打开并转换成可编辑的 Word 文档。好处是免费，不需要额外装软件；坏处是遇到分栏页面、文本框和复杂表格时，版式错乱率比较高。适合那些只有两三个页面的简单文字型 PDF，不牵涉复杂排版。WPS 的逻辑类似，但它在中文文档处理上稍好一些，比较适合中文 PDF 和表格较多的材料。

第二条，用 Adobe Acrobat Pro 的“导出 PDF”功能。Acrobat 导出的 Word 对页眉页脚、图片位置、字体样式的保留程度比 Word 自身打开要好很多。我在处理几十页的政府公文或学术文献时，首选就是 Acrobat，因为它会尽量保持页面结构。缺点是软件正版价格不低，而且如果你的 PDF 是扫描件，Acrobat 也救不了你，必须在导出前先运行 OCR 文字识别，让文件拥有文本层，再执行导出。

第三条，用命令行工具自动批量转换。比如 LibreOffice 自带的 soffice 命令可以对 PDF 做有限转换，Windows 桌面版也能用，适合批量任务。大多数场景下效果没有 Acrobat 好，但对“我要把 50 个 PDF 里的纯文字页面批量提取出来”这种需求来说，这是唯一现实的选择。常用命令是：

bash复制soffice --headless --convert-to docx "输入文件.pdf"

不过这个命令对复杂版面支持有限，转出来的 docx 可能出现分页位置漂移，需要后期微调。

2.2 扫描版 PDF 转 Word 的必经之路：OCR 识别

如果你拿到的一份 PDF 是从复印机上扫出来的，页面上的文字无法用鼠标选中，那就别浪费时间试各种转换插件了，先做 OCR。

OCR 的完整链条不是简单“识别文字”，而是先对页面做倾斜校正、去噪和增强，再把图像上每个字的形状识别为文本，最后生成一层不可见的文本放到 PDF 图片底下，这个过程叫“生成文本层”或“OCR 后处理”。生成文本层以后再打开 PDF，文字可以被搜索、被选中，这也就为后续转 Word 打好了基础。

处理中文扫描文档时，我比较推荐这样一组流程。如果你已经装了 Adobe Acrobat，直接在“扫描与 OCR”功能里选“识别文本”，语言选“简体中文”，输出格式通常建议选“可搜索的图像”，这样文字在后面可选中，同时保留原始扫描外观。如果只做文字提取、不要原图底下的扫描痕迹，也可以选“编辑的图像上的文本”，让 Acrobat 直接用识别出的文字重建页面，但这个选项对被裁切、模糊或不清晰的原稿很不友好，容易产生大量识别错误。

开源场景下，我常用 PaddleOCR 配合 PyMuPDF 自己做文本层，从实际操作看，PaddleOCR 对中文印刷体识别效果相当好。整个流程大致是：先用 PyMuPDF 按 300 DPI 把 PDF 渲染成图片，然后用 PaddleOCR 识别，再把识别结果按坐标写回 PDF。过程中最容易被忽略的是，识别前一定要把页面调正。倾斜超过两度的扫描页，中文长句识别准确率会明显下降，尤其是竖排文字和带下划线的文字，错别字会突然增多。每页渲染 DPI 我建议统一用 300，再低会导致小字号汉字笔画糊在一起，再高对识别准确率的提升并不明显，反而让处理速度翻倍下降。

2.3 PDF 转 Excel，别用 PDF 转 Word 的路线硬解

把 PDF 里的表格转成 Excel，是另一个经常被误解的场景。很多人先转 Word，再从 Word 里复制表格到 Excel。结果通常是，文字倒是能复制，但单元格合并、行高、列宽全乱了，有的表格线在 PDF 里明明闭合，到 Excel 里却断成一截一截的。

更靠谱的做法是直接用能输出表格结构的转换工具。Adobe Acrobat 里的“导出 Excel”功能，对规则表格的识别能力相当不错，它会尽量还原单元格边框、合并区域和数据类型。如果表格不规则，比如表头跨页、单元格内嵌图片、大量合并单元格嵌套，Acrobat 也不保证完美，但至少会保留行列逻辑，后面手动调整的代价会小很多。

假如 PDF 的表格是扫描图片，又没有 Acrobat，那需要 OCR 表格级别识别工具。专业一点的可以看 ABBYY FineReader，它能识别单元格结构并输出可编辑 Excel。开发者也可以用 Python 生态里的 camelot-py 或 pdfplumber 抽取结构化表格。pdfplumber 的 extract_table 方法对无边框表格效果一般，但对带明显网格线的表格提取准确率不错；camelot 则在页面上有复杂合并单元格时更容易出错，需要根据页面特性和视觉提示做调参。我实际处理过一份 30 多页的扫描财务报表，也是走 OCR 加规则修正的老路，半天时间只处理了八成准确率，所以这里必须提前说清楚：凡是涉及扫描表格的转换，建议把预期放在“半自动提取后人工复核”上，而不是期待完全不需要人工干预。

如果你面对的需求恰好是反向的，比如要把 Excel 或 Word 转成 PDF，那就容易多了，Office 软件本身就有“另存为 PDF”选项。这里唯一要提醒的是，直接另存的 PDF 里默认文字是可选中的，如果你只是想给别人看看最终效果，又担心对方改内容，那就需要后续做压缩、权限限制，甚至转曲处理，这一步才是最容易踩雷的。

3. 网页打印、PDF 转曲和纸张设置里的那些坑

3.1 网页打印成 PDF：不是按 Ctrl+P 就能完美搞定的

“Web 页面 PDF 打印”看起来是浏览器自带功能，实际操作中有很多细节决定了打印结果能不能用。最典型的例子是，很多人想把 CSDN 文章或在线资料存成 PDF，直接按 Ctrl+P，在打印机里选“另存为 PDF”，结果打印出来黑底白字、背景图片全丢、代码块被截断、导航栏也混进了正文。

问题根源在于浏览器打印时默认不打印背景图形，也不加载某些异步样式。遇到这类页面，打印设置里需要打开“更多设置”，勾选“背景图形”选项，大多数浏览器的效果会有明显改善。如果文件内容宽度超出 A4 纸范围，比如两栏布局、宽表格，可以先把缩放比例调整到“适合页面宽度”，再检查打印预览，确保没有横向裁切。

把网页打印成 PDF 时还有一个容易被忽视的问题是页面分页。网页内容高度是连续的，浏览器打印时会按纸质页面高度把内容切断，如果恰好从一段代码、表格标题或一个图片中间切断，打印结果会非常难看。解决办法是尽量在生成 PDF 之前先手动检查分页预览，如果预览里显示代码块被切开，可以尝试在浏览器里切换“打印背景图形”，或者用无干扰模式（如 Reader Mode / 沉浸式阅读器）减少页面元素，让核心文章内容占据正常的线性流。

另外，“网页中的 PDF 怎么下载”和“网页打印成 PDF”是不同的困扰。如果浏览器地址栏直接打开了一个 .pdf 文件，这时在页面上按 Ctrl+S 或找浏览器右上角的下载图标，通常就能把原版 PDF 下载到本地。如果你保存下来的只是整个浏览器窗口快照，那多半是按了 Ctrl+P 而不是常规下载，这类文件后续不能编辑文字，会把原本带文本层的 PDF 变成图片型 PDF，需要特别注意。

3.2 PDF 转曲到底是做什么，什么时候必须做

先解释一个概念：转曲，严谨说法叫“文字创建轮廓”，意思是把 PDF 里的文本字形信息转换成可缩放的矢量轮廓。完成转曲以后，文字看起来和原来差不多，但本质已经从字符编码变成了图形线条。这样做的好处是，无论对方电脑里有没有安装源文件用到的字体，打开时都不会发生字体替换。

印刷和广告输出行业对转曲的需求特别大。比如文件里用了某一款特殊字体，你发 PDF 给印刷厂时没有正确嵌入字体子集，对方打开后可能自动替换成相似字体，导致字重变化、换行位置偏移，甚至中英文标点错乱。为了避免这种事故，很多印刷厂会要求最终交付的 PDF 必须先转曲。

实际操作上，Adobe Acrobat 本身没有直接提供“一键全文转曲”的菜单，最常见的做法是借助 Adobe Illustrator 或 CorelDRAW 这类矢量软件。以 Illustrator 为例，用它的“打开”功能选择 PDF 文件，会弹出一个导入对话框，选“单个 PDF 页面”或“所有页面”，打开后再按 Ctrl+A 全选所有对象，使用“文字”菜单里的“创建轮廓”功能即可。创建完轮廓以后建议比对一遍页面边距，因为个别文本在转曲过程中会因为字库的轮廓差异产生轻微宽度变化，尤其是斜体和带下划线的文字。转曲后再另存为 PDF，同时勾选“保留 Illustrator 编辑能力”会生成大体积文件，可交给印刷厂，如果不需要二次编辑，导出成普通 PDF 即可。

转曲是双向不可逆的操作。一旦转曲，原来的文字层就永久消失了，文档里的文字将不能被搜索、不能被复制，也不能再利用 PDF 阅读器做注释提取。所以一定记得，转曲前保存一份原始 PDF 的备份，不要直接覆盖原文件。我之前处理品牌手册时，就是忘了保留原始文件，几个月后客户要改一句话，已转曲版本只能重排整个页面，教训非常深刻。

3.3 Microsoft Print to PDF 自定义纸张尺寸操作

遇到要用“Microsoft Print to PDF”打印非标准尺寸纸张的情况，很多人找不到小票纸、长条纸或其他自定义尺寸的选项，因为虚拟打印机的默认纸张列表只有 A3、A4、Letter 等常见规格。这个问题的解决办法可以在 Windows 的打印服务器属性里创建自定义纸张。

先打开“控制面板”里的“设备和打印机”，或者直接在 Windows 设置里搜“打印机和扫描仪”。在打印机列表上方有一个“打印服务器属性”链接，点击进入，勾选“创建新表单”，给表单起一个容易辨认的名字，比如“送货单 140x100mm”，然后在下方输入宽度和高度。注意单位可以切换，但一定要明确毫米还是英寸，我见过有人把 100mm 输成 100 英寸，打印出来的文档大得离谱。

创建新表单后，回到“Microsoft Print to PDF”打印机的“打印首选项”里，在纸张大小选项卡中找到刚才创建的表单，选定并应用。这一步之后，Ctrl+P 打印时的页面大小下拉框里就会出现你新建的尺寸。但不同 Windows 版本对自定义表单的可见性有差异，如果打印首选项里还是看不到新表单，可能需要先勾选这台打印机的“支持该纸张大小”属性，或在打印服务器属性窗口里给 Microsoft Print to PDF 分配这个表单。说白了，这个操作有两处入口，一个是系统层面建表单，另一个是驱动层面允许调用，两者缺一不可。

这类需求常伴随另一个现象：从 CAD 图纸里插入签名文字，转成 PDF 后签名名字周围出现一个矩形框。这通常不是 PDF 转换器额外做了处理，而是 CAD 源文件里文字后面带着背景遮罩或字段底色。CAD 里的单行文字如果开启了“背景遮罩”，打印到 PDF 时会默认把文字区域罩成一个白色或半透明底框；这种边界框被 PDF 渲染引擎识别后，就成了你看到的矩形线框。解决办法是回到 CAD 源文件，把文字的“背景遮罩”关闭，或者把签名文字改成多行文字、取消背景填充，再重新输出 PDF。如果签字名是用 OLE 对象嵌入，也会在 PDF 中留下一个明显的嵌入框，一般需要转成图片格式再插入，才能彻底去除框线。

3.4 PDF 打印成实体纸时，先检查“字体嵌入”和“色彩模式”

交付打印店时，除了文件大小和页面尺寸，最容易翻车的两个点分别是字体嵌入和色彩模式。PDF 中文字体如果没有完全嵌入，打印店电脑一旦缺少对应字体，小字部分很可能变成乱码或出现缺字。检查方式很简单：用 Acrobat Pro 打开 PDF，在“打印制作”菜单里找到“预检”，运行“Acrobat PDF 检查”，看列表中是否存在“未嵌入的字体”警告。如果存在，最稳妥的办法是用原文档编辑软件重新导出 PDF，并在导出设置里选择“嵌入所有字体”。

色彩模式方面也需要提前问一句：你交付的文件是否要用于四色印刷？如果是，建议将文档里的颜色从 RGB 模式转到 CMYK 模式。很多人会觉得在屏幕上看着没问题就行，但印刷机的色彩引擎和屏幕色彩空间完全不同，RGB 颜色在印刷时会经过转换，容易出现饱和度下降、色调偏灰的问题。这一步通常在排版软件里做，PDF 转换工具本身不会自动修改源文件颜色模式，需要在印前检查时把可能出问题的页面挑出来单独处理。

4. 开发者的批量工具箱：Python 解析、提图与提取内容

4.1 把 PDF 整个页面转成图片，关键参数是 DPI

开发者偶尔会接到“把 PDF 每页导出成 JPG/PNG”的需求，比如做 PDF 预览图、存档缩略图或接入第三方系统。用 Python 处理这类任务时，我常用 PyMuPDF，也就是 fitz 模块。它的速度比 Adobe 的批处理快得多，对常见的 PDF 渲染引擎支持比较稳定。下面是一个最小可运行示例：

python复制import fitz

doc = fitz.open("示例.pdf")
for page_index in range(len(doc)):
    page = doc[page_index]
    pix = page.get_pixmap(dpi=200)
    pix.save(f"page_{page_index + 1}.png")

这里最核心的参数是 DPI。屏幕预览用 150~200 DPI 就足够，如果用于印刷或后续做 OCR，建议至少 300 DPI。A4 纸在 300 DPI 下换算出来的像素宽度约为 2480 像素，当你把图片放到屏幕上却觉得文件很大时，不要下意识去降分辨率，先确认图片的实际用途再做取舍。渲染时也要注意页面本身带旋转，PyMuPDF 会自动处理页面的旋转角度，直接输出的像素和纸张方向是一致的。如果你拿到的是扫描版 PDF，png 格式可能比 jpg 更适合做 OCR 输入，因为 png 是无损格式，不会给文字边缘带来额外的压缩噪声。

4.2 从 PDF 里提取图片，先分清“要原图”还是“要页面截图”

另一个高频需求是从 PDF 中提取图片，这个需求比很多办公软件用户想象的复杂。严格说，PDF 里的图片资源是“嵌入对象”，可以通过读取 PDF 的 xref 索引把原始图片直接抽取出来。但很多 PDF 在排版时会对图片做旋转、裁切或透明叠加，直接抽取出的原图可能带有裁切框之外的像素，或者方向不对，甚至抽出来的图片被拆分成了几个不同通道的碎片。

如果只是要内容可用的图片，我更推荐先渲染整页，再从渲染结果里裁剪出目标图片区域。这个方式虽然损失部分像素精度，但保证看到的就是页面上实际呈现的内容。如果你确信 PDF 里的图片是原样嵌入、没有旋转裁切，用 PyMuPDF 的原图抽取是最省事的：

python复制import fitz

doc = fitz.open("示例.pdf")
for page_index in range(len(doc)):
    page = doc[page_index]
    for img_info in page.get_images(full=True):
        xref = img_info[0]
        base_image = doc.extract_image(xref)
        image_bytes = base_image["image"]
        ext = base_image["ext"]
        filename = f"page{page_index + 1}_img{xref}.{ext}"
        with open(filename, "wb") as f:
            f.write(image_bytes)

命令行用户也可以直接使用 Poppler 里的 pdfimages，命令是：

bash复制pdfimages -all 示例.pdf output_prefix

它会按页序和索引生成图片文件，-all 表示尽量保留原始图像格式，不自动转成 PNG。需要说明的是，命令行抽出来的原始图片有可能与文档里显示的图片有明显差异，因为 PDF 页面显示的是“渲染后的合成结果”，而抽取资源拿到的是“入库前的原始素材”。尤其是页面做了透明混合时，前者和后者的差异会非常明显。

4.3 PDF 解析文本时，为什么复制出来的内容总是“乱掉”

除了提图，开发者的另一个头疼问题是 PDF 解析出的文本顺序错乱。不同于 TXT 或 HTML，PDF 本身不包含任何语义级的段落结构，它只告诉渲染引擎“这个字符放在哪个坐标上”。因此，文字在一行里的显示顺序是明确的，但同样出现在页面上的两篇文章分栏，哪边先读、哪些内容是页眉、哪些是正文，解析器往往只能按对象排放顺序输出，结果就会变成一段中间夹杂着页眉页脚的连续文本流。

处理时我习惯分成几条路线。如果 PDF 是文字型文件，且文字顺序没有被刻意打乱，用 PyMuPDF 的 page.get_text("text") 提取比较快。如果需要保留更精细的排版位置，比如按坐标生成标注或做自定义版式分析，可以用 pdfplumber，它对每个字符的 top、x0、x1 等坐标暴露得很完整，适合做表格抽取或关键字定位。如果文本是字体编码错乱的旧印刷文件，pdfminer.six 是老牌底层方案，能处理很多非标准字体编码，但速度比较慢，也需要额外做字符编码映射。

如果你发现提取出的文字里夹了很多奇怪的“方框”或乱码，先别急着换库，大概率是源 PDF 使用了非标准编码或字体子集。这时候最直接的选择是转向 OCR，跳过文字层，直接从渲染图上识别内容。OCR 的缺点是需要额外部署识别组件，但它在“文本层不可用”时的兜底能力无可替代。解析时如果遇到全英文 PDF，还要注意连字符断词问题，有些排版本会在行末用短横线把单词拆到下一行，解析出来以后需要单独做合并处理。我写过一个小的清洗函数，把行末的连字符加上换行符一起替换为空格，再把下一个单词拼回去，这能显著提升英文文本后续做 NLP 处理的质量。

5. 几个绕不开的周边操作：压缩、拆分合并与 PDF 翻译

5.1 PDF 无损压缩免费方案：其实一条本地命令就能搞定

整理文件时经常遇到几十 MB 的 PDF，发邮件超限、网盘传输也慢。“pdf无损压缩免费”是被搜得最多的词之一，但真正理解压缩原理的人不多。PDF 里占体积的大头通常是图片、字体和对象的冗余元数据。所谓无损压缩，是在不改变页面内容的前提下，通过重新编码内嵌图片流、合并重复对象、移除不必要的元数据来减小文件体积。

免费工具里，Ghostscript 是功能很稳的选择，很多在线压缩网站后端就是它。一条常见的压缩命令是：

bash复制gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dPDFSETTINGS=/ebook -dNOPAUSE -dBATCH -dQUIET -sOutputFile=output.pdf input.pdf

关键参数是 -dPDFSETTINGS，它有几个预设：/screen 压缩率最高但图片质量损失明显，适合纯屏幕阅读；/ebook 相对平衡，适合大多数办公文档，图片会被压缩到 150 DPI 左右；/printer 保留了较高的图片质量，压缩率小一些。对印刷交付要求高的文件，我推荐用 /printer 或者不用 -dPDFSETTINGS，只做对象级压缩。用 Ghostscript 处理后，文档文字层依然保留，能搜索也能复制。但请不要对带签章、需要司法鉴定的文件做这种“优化”，因为重新编码后的 PDF 结构会发生变化，签名验证信息有可能失效。另外，如果是密码保护的 PDF，必须先解除限制再处理，否则 Ghostscript 会报错。

无损压缩领域还有一个开源工具 qpdf，它对普通用户的价值在于“清理 PDF 结构”，比如重新生成对象流、压缩流、修复结构性问题。你可以这样使用：

bash复制qpdf --object-streams=generate input.pdf output.pdf

这条命令通常能省下百分之十几的体积，而且完全不改变页面内容。如果文件压缩后依然很大，就说明问题可能出在页面携带的高清扫描底图上，需要考虑从源头重新导出，而不是依赖压缩工具“硬扛”。

5.2 PDF 合并拆分和页面排序：命令行比鼠标点更快

办公室里临时把几个 PDF 合并成一个文件，最方便的办法是用 Acrobat 或 WPS 的页面组织功能。但如果你经常处理这类批量任务，建议尝试 qpdf 或 PDFtk。合并两个 PDF 只需要一行：

bash复制qpdf --empty --pages a.pdf 1-5 b.pdf 1-3 -- merged.pdf

这个命令的意思是：把 a.pdf 的第 1~5 页和 b.pdf 的第 1~3 页按顺序合并到一个新文件里。拆分文件也很方便，比如从第 2 页到第 8 页提取出来：

bash复制qpdf input.pdf --pages 2-8 -- output.pdf

命令行工具最大的好处是批量操作可复制，不需要每次点几十下鼠标。批量处理时，还可以把文件名列表保存在文本文件里，用循环自动跑完所有任务。注意合并 PDF 时各个文件的书签和超链接不一定能完整保留，如果交付文件要求带目录导航，我建议用 Adobe Acrobat 做合并，它会对书签结构有更好的整理支持。还有一个经验是用 qpdf 之前先复制一份原文件，特别是当你用通配符批量覆盖文件时，不小心删掉页面文件，回头找原始文件就很麻烦。

5.3 PDF 翻译以后还能保持排版吗？分三个层级看

PDF 翻译的需求通常来自论文、说明书，尤其是外语 PDF。你肯定遇到过把整段文字往在线翻译里粘贴，格式全没了，图片和文本的对应关系也彻底丢失。要不要保持原排版，决定了你能走多远。

如果只是“大概看懂内容”，最省事的做法是先用 PDF 解析工具提取文本，再做机器翻译，最后阅读纯文本即可。但这样做损失了图片、表格布局和字体强调信息。

如果要保留原始页面的视觉位置，可以尝试 DeepL 或 Google 翻译的文档上传功能，它能翻译 PDF 并尽量保持原布局。实际效果对这个要求的满足程度取决于 PDF 复杂度。纯文字 PDF 的翻译效果较好，表格和嵌入式图片多的文档则经常错位。另一种相对可控的思路是：先解析出 PDF 中每个文字块的坐标和内容，翻译成目标语言后，再在相同坐标位置渲染出新文字。从工程角度看，这已经偏向“本地化排版系统”了，适合多语言版式需求稳定的项目，不太适合一次性的应急翻译。有一类更稳妥的业务流是先把 PDF 转成 Word，在 Word 里做翻译，再重新导出 PDF，这样翻译人员能看到原始排版，后续调整也方便，但前提是源 PDF 可以从字体层顺利转换，扫描件必须提前完成 OCR。

6. 常见问题排查表与我的避坑笔记

6.1 PDF 转换高频问题速查表

日常处理中，我整理了一张速查表，按现象直接索引可能的原因和解决方案。遇到问题的时候你可以先对照一遍，省得反复试错。

这张表里的每条我基本都踩过。只要你的需求能在表里找到对应行，大概率能少走一大段弯路。

6.2 动手转换前，先问自己三个问题

多年做文档处理，我养成了一个习惯：任何转换任务拿到手，先不急着点工具，而是用三句话确认范围。第一，这个 PDF 是文本型的还是有扫描图片的？这决定了要不要先 OCR。第二，最终交付要的是同一个版式，还是只要核心内容？这决定了选版式还原工具还是解析工具。第三，源文件有没有不能外传的敏感信息？这决定了是用本地工具还是在线服务。

这三个问题回答清楚了，才是工具选型和时间预算的问题。比如朋友要转一份简历模板 PDF，我通常让他们直接用 Acrobat 或 WPS，因为要版式。但如果是处理一份数据库导出的报表，需要把 PDF 里面的表格抓出来做统计，那我的首选就不是 Acrobat 了，而是 pdfplumber 加 pandas，因为重点是结构化数据，不是页面观感。

关于版权和资料安全问题，也要多说一句：不是所有 PDF 都有权转换和传播。出版社电子书、付费下载的学术论文、公司内部带水印的技术文档，都不应该随意用在线工具转成可编辑格式后二次传播。日常做技术方案时，我也会偶尔用 OCR 工具处理自己扫描的阅读笔记，但绝不会把购买的电子书拆页转文字再转发给他人。这个边界靠自觉，也靠责任意识。

6.3 处理多个文件时，始终保留一份原始版本

PDF 转换操作往往不可逆，即使转换工具提供“不再保留原始版本”的选项，也不建议直接勾选。因为大多数转换过程只保证了当下需求，一旦需求变化，比如从“只要文字”变成“要矢量图”，原来的 PDF 可能就是唯一可用的素材来源。我现在处理文档的标准动作是：在同一个文件夹里建一个 源文件_原始版本 的子文件夹，把所有原版 PDF 放进去，只在副本上做转换操作。文件命名会加上日期和后缀说明，比如 合同扫描版_20250115.pdf、合同_转Word_20250115.docx，这样即使过一个月再回去找文件，也能快速判断当时做了什么操作。

提一个容易被忽略的小细节：Windows 上如果你的文件名带了“PDF”和“DOCX”两个后缀，注意系统可能只展示最后一段后缀，实际文件名的其余部分仍会在命令行工具里生效，通配符处理时会带来误解。我习惯用简洁的英文或拼音文件名做批量操作，中文文件名在某些命令行环境里可能遇到编码兼容问题，虽然现在多数工具已经支持，但为了最大程度避免坑，给目录里的文件重命名成简单编号，是成本最低的保险动作。

6.4 我最想分享的一个经验：先识别源文件类型，再选择“往什么方向转”

做了这么久的 PDF 相关工作和项目，最深刻的体会是：PDF 转换从来不是一个单纯“点一下导出”的操作。很多人觉得转换不成功是软件不行，其实更常见的原因是没有识别出源文件是文本型还是扫描型、是纯大纲还是复杂表格、是内部文档还是加密文档。工具只是把 PDF 内部的数据结构重新映射到另一种格式，映射的前提是源文件内部的数据没有被拆散、没有失真，所以先看 PDF 本身的“质地”，比你收藏一万个转换工具都有用。

我后来帮同事处理那份扫描版 PDF 时，解决路径很清晰：先用 Acrobat 做了 OCR 中文识别生成文本层，再导出成 Word，后期手工调整了五六处表格合并位置，前后大概十来分钟。她惊讶地说原来不是软件不行，是转换思路的问题。这大概也是这篇内容想表达的核心理念。往后你再遇到要转 PDF 的情况，可以先停一下，用本节提到的问题过一遍脑子，或许能省下不少无用功。