企业官网建设流程全解析

PDF 格式转换这件事，表面上看是点几下鼠标，真干起来经常是另一回事：同一份文件在本地导出得干干净净，发到别人手里打开就变成一堆错乱的段落；扫描件转成表格，识别出来的数字位数都不对；上百份合同要统一转成图片归档，一份一份点下去能点到怀疑人生。更麻烦的是，很多人一遇到问题就换工具，换到第五个工具时才发现，问题根本不在工具上，而在 PDF 这种格式本身的设计逻辑里。

这篇东西想解决的就是这一件事：把 PDF 格式转换的几条主线一次讲透——PDF 与 Word、Excel、PPT 的互转，PDF 与图片的互转，扫描件的文字提取，以及批量场景下怎么把重复劳动交给命令行和脚本。写给的读者范围拉得比较宽：平时只是偶尔转个简历、转个发票的，看完前两节够用；手上有一堆文件要处理、或者要把转换流程固化进业务里的，可以直接跳到命令行和脚本那两节抄作业。文中提到的参数、命令、判断标准，都是我在实际处理文档流水线时反复用过的，涉及具体数值的地方会给出计算过程，方便你按自己的场景换算。

1. 先搞懂 PDF 为什么难转，方案才不会选错

1.1 PDF 是排版结果的快照，不是可编辑文档

要理解 PDF 格式转换的各种毛病，得先接受一个事实：PDF 从来就不是为了“被编辑”而设计的。它的前身是一套页面描述语言，核心思想是告诉打印机“在坐标 (x, y) 处画一个 12 号字形的‘订’字，颜色是 #333333”，而不是告诉任何软件“这里有一个二级标题，下面跟着一段正文”。整份文件里全是绘制指令，没有段落、没有行、没有列表概念，更没有“这一行属于上一段”的语义信息。

这个差别带来一个直接后果：从 Word 到 PDF 是正向渲染，信息是丢失式的单向流动；从 PDF 回到 Word 则是逆向推理，软件必须靠字符的坐标、间距、字号、基线位置去猜“这两行应该是一段”“这个大字号加粗的东西大概是标题”。猜得准不准，取决于原文件的结构有多规整。这就是为什么同一份 PDF，用不同工具转出来的 Word 能差出十万八千里——不是谁更强，是大家的猜测策略不一样。

我把这个关系理解成“烤好的蛋糕还原配方”：面粉、鸡蛋、糖的比例理论上还在蛋糕里，但你要把它精确还原成克数，只能靠经验和仪器。所以后面所有的方案选择，本质上都是在回答一个问题——你需要的到底是“能看的蛋糕”，还是“能改的配方”。

1.2 三种内部结构，决定三条不同的转换路线

同样是 .pdf 后缀，内部构造可能完全不同。判断错了类型，用错方案，怎么调参数都是白费劲。我一般把它分成三类：

判别方法很简单：随便打开一份，按 Ctrl+F 搜正文里一个确定存在的词。搜得到就是文本型，搜不到基本是图像型。再看能不能逐字选中，能选但选出来是乱码，多半是字体编码映射坏了，这种属于“伪文本型”，比纯扫描件更麻烦，因为工具会误以为有文字层而跳过 OCR，最后导出一堆乱码。

我见过最坑的一种情况是：某份资料先被扫描成图片，又被某个工具加了 OCR 文字层，但文字层的位置整体偏移了两三毫米。视觉上看完全正常，转成 Word 后每个字都错位，改起来比重打一遍还慢。所以拿到一批陌生 PDF 时，我第一件事永远是抽样验证文字层的质量，而不是直接开转。

1.3 按文件量和精度要求分档选方案

工具没有绝对好坏，只有匹配不匹配。我按两个维度分档：一次要处理多少份，以及对保真度的要求有多高。

这个分档的意义在于避免两种典型浪费：一是拿命令行去处理三份文件，配置环境的时间比手动转还长；二是拿图形界面工具去处理八百份文件，点完之后还得逐份检查，等于没省事。

还有一条隐性标准值得单独提：转换的终点是什么。如果终点是“给人看”，那保真度优先，宁可体积大一点；如果终点是“给机器读”，比如要做全文检索、要做数据抽取，那排版美观完全不重要，文字提取的完整率和准确率才是唯一指标。这两类需求经常被混在一起讨论，导致方案选得四不像。

提示：动手之前先明确一句话——这批文件转完之后，是给人看还是给程序读。这句话能省掉后面一半的返工。

2. 命令行方案：批量转换的效率底盘

2.1 环境准备：五个工具覆盖九成需求

批量场景我基本只用命令行，原因很实在：图形界面每换一批文件就要重新点一遍，而命令行写好一次就能重复跑，还能塞进定时任务。需要的工具不多，五类基本够用：

• 页面渲染工具：把 PDF 每页渲染成 PNG 或 JPEG，常用的是 Poppler 工具集里的pdftoppm，稳定、参数直观。
• 文本提取工具：同一个工具集里的pdftotext，负责把文字层抽出来。
• PDF 处理引擎：Ghostscript，负责压缩、合并、格式降级、修复损坏文件，是命令行里最万金油的一个。
• 图像处理工具：ImageMagick，负责裁边、去底色、统一尺寸、格式互转。
• OCR 引擎：Tesseract，扫描件转文字的主力。

安装方式按各自系统的包管理器来就行，不再赘述。这里要重点提醒一个几乎人人都会踩的坑：ImageMagick 默认的安全策略会禁止处理 PDF，报错信息大概是“not authorized”。原因是为了防范恶意构造的 PDF，它的策略文件里把 PDF 的读写权限关掉了。解决办法是编辑策略配置文件，在 PDF 对应的策略里把权限从none改成read|write。这一步不做，后面所有基于convert的命令全部报错，很多人卡在这里以为是安装坏了。

另一个准备工作是给文件命名立规矩。批量任务里最怕的是文件名带空格、带中文括号、带特殊符号，命令一跑就断在某个奇怪的文件上。我的习惯是先把待处理文件统一复制到一个临时目录，重命名成001.pdf、002.pdf这种纯数字序列，处理完再映射回原名。多花两分钟，能省掉后面半小时的排错。

2.2 PDF 转图片：DPI 到底该设多少

这是被问得最多的参数问题。DPI 的本质是“每英寸多少个像素点”，所以像素尺寸 = 物理尺寸（英寸）× DPI。以最常见的 A4 为例，210mm × 297mm 换算成英寸是 8.27 × 11.69，那么各档 DPI 对应的像素是：

体积这笔账值得算一下，因为它直接决定你的存储成本。A4 在 300 DPI 下的原始像素量是 2480 × 3508 ≈ 870 万像素，按 RGB 每像素 3 字节算，未压缩的位图是 870 万 × 3 ≈ 26 MB。而实际导出的 JPEG 通常只有几百 KB，压缩比接近 50:1。所以“300 DPI 转出来会不会太大”这个担心基本是多余的，真正让文件爆炸的是 PNG 格式加无损压缩，一百页下来轻松上 G。

命令本身很简洁：

# 300 DPI 转 JPEG，质量 90，灰度可再省 30% 体积 pdftoppm -jpeg -jpegopt quality=90 -r 300 input.pdf page # 转 PNG，适合需要后续做图像处理的场景 pdftoppm -png -r 300 input.pdf page # 只转第 3 到第 8 页 pdftoppm -f 3 -l 8 -jpeg -r 150 input.pdf page

参数选择上有几条经验。做 OCR 时 DPI 不要低于 300，低于这个值，中文小字号的笔画会粘连，识别率断崖式下跌；而超过 600 之后识别率提升极小，处理时间却翻倍，属于典型的边际收益递减。纯展示用途 150 DPI 就够了，微信、邮件里传的图基本都是这个量级，再高也是被平台二次压缩。灰度扫描件加-gray参数，体积能再降三成，对黑白文档几乎无损。

还有一个细节：默认输出文件名是page-1.jpg、page-2.jpg这种，页数过百之后排序会变成 1、10、100、11，看着乱。批量命名时加-sep或者后续用脚本重命名成固定位数，能避免后面合成 PDF 时页码错乱。

2.3 图片合成 PDF：排序、尺寸、体积三件事

反方向的需求同样多：一堆手机拍的票据、一堆导出的图表，要合成一份 PDF 发出去。这个操作看着简单，三个地方容易出问题。

第一是排序。文件名里带数字时，字符串排序会把 10 排在 2 前面。解决方式是自然排序，或者在脚本里按数字部分排序。这个坑我在第一次做发票归档时踩过，一百多张票据合成后页码全乱，只能重来。

第二是页面尺寸。如果每张图尺寸不一，直接合成会得到大小不一的页面，打印时会被强制缩放，边缘留白很难看。处理办法有两种：统一缩放到固定画布，或者统一按 A4 等比缩放后居中补白。后者更适合正式文档。

第三是体积。这里有一个非常实用的技巧：如果源图已经是 JPEG，合成时尽量让它直通嵌入，不要重新编码。PDF 内部支持直接嵌入 JPEG 数据流，不再二次压缩，画质和体积都能保住。用图像工具先转 PNG 再合成，等于解码又编码一遍，体积涨、画质降，纯属自找麻烦。

# 推荐做法：直接嵌入 JPEG，不重编码 img2pdf --output out.pdf --pagesize A4 --fit into *.jpg # 通用做法：交给图像工具统一尺寸后合成 convert page-*.png -resize 2480x3508 -gravity center -extent 2480x3508 out.pdf

第二条命令里的-resize加-extent组合是关键：先等比缩放到不超过目标尺寸，再用-extent补白到精确的 A4 像素，-gravity center保证内容居中。少了这一步，合成出来的页面会大小参差。

2.4 文本提取与 Office 互转的取舍

从 PDF 抽文字，pdftotext是首选，但它有两种输出模式，选错了结果差很多。默认模式按内容流的顺序输出，适合纯散文；加-layout参数则尽量保留原始的横向位置和换行，适合表格、代码、多栏排版。

我一般先用-layout试一遍，如果抽出来的内容里塞满了多余空格、表格串行，说明文档是双栏或者复杂版式，这时候纯文本提取基本救不回来，得换思路——要么走版式还原工具，要么干脆放弃文本层，把页面渲染成图再做结构化识别。这是很多教程不会讲的一点：文本提取不是万能的，复杂版式下它的上限很低，早点认清能省很多时间。

至于 PDF 转 Office 文档，命令行这条路能做的其实有限，效果最好的是专门的转换引擎，但这类引擎大多要装体积不小的依赖。我的实际做法是：结构简单的文档（单栏纯文字、标准表格）走转换工具，结构复杂的（多栏、图文环绕、公式）直接上桌面软件手动处理。硬要用批量工具去啃复杂版式，产出物的返工成本远超省下的时间。

注意：转换前先跑一遍pdfinfo看一眼页数和文件大小。遇到过不少“转换失败”的案例，其实是文件本身下载不完整或者被截断，转换工具只是背了锅。

3. 桌面与在线方案：零基础怎么走稳

3.1 办公套件的原生导出，保真度最高的那条路

如果源文件还在自己手里，那最优解永远是从源文件重新导出 PDF，而不是拿别人给的 PDF 去反向转换。这个道理很朴素，但实际工作中大量的人在做无用功：明明手里有 Word 原稿，非要把别人转好的 PDF 再转回来改。

从办公套件导出 PDF 时有几个参数值得调，它们直接决定文件在别人机器上长什么样：

• 字体嵌入：必须开启，最好是完整嵌入而不是仅嵌入使用字符。不嵌入的后果是对方机器缺字体，整篇换成默认字体，行宽全变，排版稀碎。
• 图片压缩：默认设置通常是“适用于打印”，会保留较高分辨率。如果只是内部传阅，改成屏幕质量能把文件压到三分之一。
• 保留书签与标题结构：勾选之后导出的 PDF 自带导航目录，长文档体验提升非常明显，而这一步几乎零成本。
• 权限设置：需要防止随意修改时加权限密码，但要区分“打开密码”和“权限密码”——前者是打开就要输，后者是能打开但不能编辑打印。设错了会给自己挖坑。

反方向的 PDF 转文档，桌面软件通常提供两个选项：“保留版式”和“保留文本流”。前者转出来像图片拼贴，每个文本框独立定位，好处是外观接近原件；后者转出来是可编辑的连续段落，好处是容易改，坏处是格式会散。改内容选后者，做展示选前者，选反了会觉得工具很烂。

3.2 在线工具的使用边界

在线转换工具的优势是不用装东西，劣势大家心里都清楚：文件要上传到别人的服务器。这里不是要讲什么大道理，只说几条实操层面的判断。

敏感文件不上传，这条没有例外。合同、身份材料、财务数据、内部图纸，一律走本地工具，哪怕慢一点。判断标准很简单：这份文件如果出现在公开渠道，会不会造成实际损失。会，就别上传。

看它给什么、要什么。一个正常的在线工具，转换完给下载链接就够了。如果它开始要手机号、要注册、要关注、要分享后才能下载，说明它卖的不是转换服务，是你的信息。这类站点我一律不用，因为转换本身的技术成本极低，附加这么多门槛只能说明商业模式在别处。

注意输出的质量损耗。很多在线工具为了控制服务器成本，会统一按低分辨率渲染或者高压缩比输出。表现就是转出来的图片发虚、PDF 里的图片变糊。测试方法很简单：拿一份带小字号文字的 PDF 去转，转完放大到 200% 看笔画边缘是否还清晰，糊了就是二次压缩过了。

页数和体积限制也是常态，免费额度通常在 10 到 20 页、10 到 20 MB 之间。超过就得拆文件，拆完再合并，来回折腾的时间成本比装个本地工具高得多。所以我的建议是：在线工具只用于临时救急，稳定需求一律转到本地方案。

3.3 扫描件的 OCR：让图变成字的关键在预处理

扫描件转文字是 PDF 格式转换里最难的一环，也是最容易失望的一环。很多人拿手机拍的文档直接丢进 OCR，出来一堆错字，就断定“OCR 不好用”。实际上问题八成出在预处理上。

预处理要做的事，按收益从高到低排：

顺序也有讲究：先纠偏，再转灰度调对比度，最后才考虑二值化。反过来的话，二值化之后纠偏的插值会让边缘产生锯齿，反而更难识别。

OCR 之后必须校对，而且要重点校对特定内容。根据我的经验，出错密度最高的是：数字（尤其是 0 和 O、1 和 l、5 和 S）、形近汉字（己和已、未和末）、表格里的行列对应关系。金额、编号、日期这类字段建议逐条核对，正文可以抽检。整篇通读一遍校对是理想做法，但实际赶工期时，把关键字段揪出来核对比通读有效得多。

还有一个小技巧：如果 OCR 结果里频繁出现同一类错误，说明语言包或者识别模式选错了。中文文档要用中文语言包，中英混排要配中英双语言包，只装英文包跑中文，出来必然是乱码。这个错误看似低级，但因为默认配置常常是英文，中招的人非常多。

4. 脚本方案：把重复劳动交给代码

4.1 拆分、合并、加密的最小可用脚本

到了需要固定流程的阶段，就该上脚本了。Python 生态里有几个成熟的 PDF 处理库，日常的拆分、合并、加密、读页数、提取元信息都能覆盖，写起来也就十几行。

from pypdf import PdfReader, PdfWriter def split_pdf(src, out_dir): """按单页拆分，适合把合集拆成独立文件归档""" reader = PdfReader(src) for i, page in enumerate(reader.pages, start=1): writer = PdfWriter() writer.add_page(page) with open(f"{out_dir}/part_{i:03d}.pdf", "wb") as f: writer.write(f) def merge_pdfs(files, out_path, encrypt_pwd=None): """按给定顺序合并，可选加打开密码""" writer = PdfWriter() for f in files: writer.append(f) # append 比逐页 add 更快 if encrypt_pwd: writer.encrypt(encrypt_pwd, algorithm="AES-256") with open(out_path, "wb") as f: writer.write(f) def need_ocr(path, char_per_page=50): """判断是否扫描件：平均每页有效字符太少就判定需要 OCR""" reader = PdfReader(path) total = sum(len((p.extract_text() or "").strip()) for p in reader.pages) return total / max(len(reader.pages), 1) < char_per_page

最后那个need_ocr函数是我用得最多的一个判断。它的逻辑很简单：如果一份 PDF 平均每页提取出来的有效字符少得可怜，那它大概率是扫描件或者文字层坏掉了，直接进 OCR 流程，不要浪费时间在文本提取上。这个阈值设 50 是经验值，封面、图表页多的文档可以调低到 20。

批量处理时还有两个工程习惯值得养成。一是每个文件独立处理、独立记录，用字典或者日志把“文件名 → 处理结果”存下来，中途挂了能续跑，不用从头再来。二是先处理 3 个样本，人工验收通过再跑全量，这一步能挡住九成的批量事故。

4.2 转换结果的自动化质检

批量转换最大的隐患不是失败，而是“看起来成功了但结果是坏的”。一百份文件里混进去三份空白页、两份乱码，不逐份看根本发现不了。所以我给每批任务都配几个自动检查项：

这几项里最实用的是“纯白页检测”。实现方式是先按 72 DPI 渲染，再把图缩到很小比如 64×64，然后算像素值的标准差。空白页的标准差会接近 0，哪怕有轻微噪点也能用一个很小的阈值区分开。这个检查帮我抓到过好几批因为扫描仪进纸故障产生的空白页，如果人工翻，一百页里夹三张白页，很可能翻着翻着就滑过去了。

另一条经验是：质检要比转换本身更早设计。先想清楚“什么叫转好了”，再去写转换。这个顺序反过来，往往要返工。我现在的习惯是每接一个新的转换需求，先花十分钟写验收条件，哪怕只是几个 if 判断，后面的返工率能降一大截。

5. 常见问题与排查技巧实录

5.1 排版跑偏的三步定位法

转换后排版错乱是最常见的抱怨，但“排版乱”这三个字背后至少有五种不同的原因，盲目换工具纯属碰运气。我固定用三步定位：

第一步，判断是源问题还是目标问题。把源 PDF 用另一个查看器打开，如果在这里就已经显示异常（缺字、重影、错位），那问题在源文件，转换工具再怎么换也没用，得回去找正确的原始文件或者重新生成。这一步能排除掉大约三分之一的问题。

第二步，用文本提取验证文字层。跑一遍文本提取，看抽出来的是正常文字、乱码，还是空白。正常文字说明文字层健康，问题出在版式还原环节；乱码说明编码映射坏了，得走 OCR；空白说明是扫描件，压根没有文字层。三种情况的处理路径完全不同。

第三步，降级到纯文本。如果只关心内容不关心格式，直接把 PDF 转成纯文本再粘回目标软件重新排版，往往比跟转换工具较劲更快。这不是妥协，是理性选择——把一份复杂版式的 PDF 精确还原成可编辑文档，本身就是一个没有完美解的问题。

这三步的价值在于把“玄学”变成可执行的检查。我见过太多人在这件事上消耗时间，本质原因是把不同层次的问题当成了同一个问题。

5.2 常见问题速查表

这张表覆盖了日常八成的情况。剩下的两成属于真正的疑难杂症，通常跟文件本身被多次转手有关——一份文件从 A 格式转到 B，再从 B 转回 A，反复几轮之后结构会变得很奇怪，这时候最省事的做法是重新渲染成图片再重建 PDF，等于做一次“格式洗白”。

5.3 几个我踩过的坑和工作习惯

最后说几个具体的、教程里不太会写的东西。

PDF 转图片时，透明背景会变黑。带透明图层的 PDF 转成 JPEG 后，原本透明的地方经常变成纯黑或纯白，非常难看。原因是 JPEG 不支持透明通道，渲染器就把透明区域按默认底色填充了。解决方法是输出 PNG 保留透明，或者渲染时显式指定白色背景。这个小问题曾经让我在一批宣传物料上返工了一下午。

页数多不等于文件大，反过来也成立。判断一份 PDF 会不会转出问题，看的不该是页数，而是内嵌图片的数量和分辨率。一份 200 页的纯文字文档可能只有 3 MB，转起来飞快；一份 10 页的产品画册可能 80 MB，每页都是高分辨率大图，渲染时内存吃紧，甚至会把进程撑爆。处理这类文件要分页批处理，别一次性全渲染。

转换前先留原始备份。这条听起来像废话，但批量任务里“覆盖了源文件”的事故发生率远比想象中高。我的做法是所有输出都写到独立目录，源目录设为只读，用脚本硬性约束。这个习惯养成之后，至少心里踏实。

建立一个自己的参数对照表。哪种文档用多少 DPI、什么场景用 JPEG 什么场景用 PNG、哪种情况必须走 OCR，这些判断做多了会形成直觉，但直觉会忘。我自己的表就放在项目根目录的一个文本文件里，每次开工前扫一眼，比凭感觉靠谱。这个做法成本极低，收益却持续很多年。

别迷信“一键转换”。所有宣称一键搞定所有格式的工具，实际表现都是“大部分格式能转个大概”。真正要求高的场景，还是得分类型、分步骤处理。认识到这一点之后，我在 PDF 格式转换上浪费的时间反而少了很多——因为不再期待某个工具能解决全部问题，而是先判断问题属于哪一类，再挑对应的那把刀。

如果你的文件量还很小，从第 3 节的办公套件原生导出用起就够了；等到某一天你发现自己在一遍遍重复同样的点击动作，那就是该把第 2 节和第 4 节的命令行方案捡起来的时候。转换这件事本身不难，难的是先看清源文件是什么、目标是什么，剩下的都是参数问题。