简介：面向需要在 Windows 上把 PDF 批量转成 Word 的办公人群，这是一份基于 Python 自行整合打包的转换工具，解压后直接运行 pdf2doc.exe 即可使用，免安装、无广告，支持单个文件、多文件以及整个文件夹的批量转换。压缩包共 1154 个文件，约 105.54MB，其中 1 个 exe 主程序、11 个 py 源码文件与 50 个 dll、60 个 pyd 等运行时依赖共同构成可独立运行的环境，还包含大量时区数据文件、txt/readme 说明与图标 gif 等资源，体现 PyInstaller 打包的完整目录结构。已有 142 人学习下载。对于日常需要处理合同、报告、论文等 PDF 文档的办公人员，可直接获得一个开箱即用的转换工具，并借助附带源码了解 PDF 解析与 docx 生成的实现思路，也便于按需二次修改；批量处理文件夹的能力可显著减少重复操作。

1. 从双击闪退说起：pdf2doc.exe 在 Win10 和 Win11 上的真实门槛

第一次拿到这个 pdf2doc.exe，我也以为双击就完事——结果窗口白光一闪，什么都没留下。后来才想明白，所谓「自己用 python 整理的 pdf 转 doc 工具，解压即用」，省掉的是装 Python、敲 pip 的功夫，没省掉的是 Windows 这层地基。同一份包，在一台 Win11 家庭版上少了个 vcruntime140_1.dll 直接起不来；换到另一台 Win10 专业版，解压到桌面（路径带中文）又抛编码错误。pdf 转 doc 这件事本身不复杂，复杂的是运行库、解压路径，以及你手上那份 PDF 到底是文本型还是扫描件。这篇笔记写给两类人：想双击就用、不碰命令行的办公用户，和想搞清楚 exe 里到底塞了什么、出问题能自己救回来的开发者。装不好最轻是白等五分钟没输出，最重是转出一份排版全散的 doc，还怪工具不行。

2. 装前清点环境：64 位系统、VC++ 运行库与解压目录的选择

这一步最容易被跳过，也最容易在后面翻车。打包成 exe 的 Python 工具，本质是把解释器、依赖库和你的脚本一起封进一个可执行文件里，它对外部环境的要求确实比源码运行低很多，但不是零。装之前花五分钟把下面几项确认一遍，能省掉后面一小时的重装。

2.1 系统版本与位数：为什么 32 位机器直接出局

打包出来的 exe 内嵌的是 64 位 Python 解释器，这是当前打包工具的默认行为，因为绝大多数第三方库（尤其是处理 PDF 里图像的库）已经不再提供 32 位轮子。在 32 位系统上双击，得到的是「不是有效的 Win32 应用程序」，这个报错跟包本身没关系，再换十个版本也一样。

先用一条命令把底细看清楚：

# 一次看清系统名、版本号、架构；Win10/Win11 通用 Get-ComputerInfo | Select-Object OsName, OsVersion, OsArchitecture

输出里OsArchitecture必须是64-bit。老系统上有人习惯用wmic os get Caption,Version,OSArchitecture，注意wmic在新版 Win11 里已经被移除，敲下去会提示找不到命令，不是你环境坏了，是微软把它退役了，改用上面的 PowerShell 写法就行。

版本方面，我这边的经验值是 Win10 1809 及以上、Win11 21H2 及以上最稳。原因不在 exe 本身，而在系统自带的 Universal C Runtime（也就是ucrtbase.dll那一套）在这两个版本之后才完整覆盖，更老的系统缺文件时会连带报一串api-ms-win-crt-*找不到。真遇到这种老机器，与其折腾，不如直接补运行库，方法在下一节。

2.2 运行库补齐：vcruntime140 与 UCRT 各自管什么

这是 pdf2doc.exe 起不来的第一大原因，也是最容易被误判成「包坏了」的原因。Python 解释器本身是用 MSVC 编译的，它依赖 Visual C++ 运行库里的几个 DLL。这几个文件在装了开发工具的机器上一定有，在干净的办公机上经常缺。

先查，别急着装：

REM 三个文件都在，运行库这一关基本就过了 dir C:\Windows\System32\vcruntime140.dll dir C:\Windows\System32\vcruntime140_1.dll dir C:\Windows\System32\ucrtbase.dll

三者的分工不一样，搞清楚这个，看报错时就不会乱猜：

缺哪个都别去网上单独下那个 DLL 往 System32 里塞，这是血泪经验——版本对不上会导致更多程序一起崩，而且很难回滚。正确做法是装微软官方的「Visual C++ 2015-2022 Redistributable」，x64 版本，一个安装包装完三个文件全齐，装完重启一次让 PATH 和注册表生效。这一步不需要联网找什么特殊渠道，微软下载中心直接搜这个名字就有。

注意：如果你的机器上已经装了一堆版本的 VC++ 运行库（2010、2013、2015、2017 各一份），不要卸载旧的。它们之间是并存关系，卸载旧版会让别的老软件跟着挂。

2.3 解压目录三不原则：不中文、不空格、不同步

运行库齐了，第二个坑在路径。这套 pdf2doc.exe 底层调用的 PDF 解析库，很多文件操作走的是系统默认编码，路径里带中文时，在某些区域设置下会抛UnicodeDecodeError或者干脆静默失败——表现就是双击后没反应，任务管理器里进程闪一下就消失。

三条原则，按重要性排序：

第一，路径不带中文。D:\工具\pdf2doc这种看着舒服，实际是给自己埋雷，改成D:\tools\pdf2doc。

第二，路径不带空格。D:\my tools\pdf2doc在命令行里不加引号会被截断成两段，exe 收到的参数就是错的。桌面路径C:\Users\XXX\Desktop里如果用户名带空格，同样中招。

第三，不放在 OneDrive、坚果云这类同步目录下。转换过程中 exe 会往输出目录写文件，同步客户端可能同时占用这个文件句柄，结果就是「转换完成但文件是 0 字节」。这种问题最难查，因为日志里一切正常。

还有个权限问题：别解压到C:\Program Files下面。那个目录默认需要管理员权限才能写，而 pdf2doc.exe 默认把输出放在自己所在目录，写不进去就报「拒绝访问」。我一般固定放在D:\tools\pdf2doc，全盘无中文、无空格、不同步、不需要提权。

2.4 一份可直接对照的环境清单

把上面几项合并成一张表，装之前逐条打勾。这张表我在几台机器上验证过，只要全绿，双击跑通的概率在九成以上：

磁盘空间这条容易被忽略。PDF 转 doc 的过程是先解析、再重建文档结构，中间会生成临时文件，占用大致是原文件的 1 到 2 倍。一个 200MB 的扫描版 PDF，转的时候临时目录可能吃掉 400MB，C 盘红了的机器上直接失败，报错还很不明显。

3. 解压与首次启动：从压缩包到 pdf2doc.exe 跑起来

环境清完，进入实际动手环节。这一章的动作不多，但每一步都有个「为什么」，照着做能避开大部分首次启动的失败。

3.1 用对解压工具，别在压缩包里双击

第一个动作：把压缩包完整解压出来，不要在压缩软件的预览窗口里直接双击 pdf2doc.exe。

原因很实在。Windows 资源管理器打开 zip 时，你看到的是一个虚拟目录，双击里面的 exe，系统会先把它释放到%TEMP%下的一个随机临时目录再运行。如果你的包是单文件 exe（所有依赖都封进去了），这样勉强能跑；但只要包里还有配套的 dll、配置文件或者字体文件，exe 在临时目录里就找不到它们，报错信息通常是「找不到模块」或者干脆无响应。而且临时目录在进程退出后会被清理，你连排查的现场都留不下。

解压工具的选择上，Windows 自带的「全部解压缩」对付小包够用，但遇到内含几十上百个小文件的包时，偶尔会出现解压不完整、权限丢失的情况，尤其是从某些渠道下载、带了额外元数据的压缩包。我一般用 7-Zip，右键「提取到当前位置」，稳。

解压完先看一眼目录结构，正常应该长这样：

D:\tools\pdf2doc\ ├── pdf2doc.exe ← 主程序，双击入口 ├── _internal\ ← 依赖库目录（单文件版可能没有） ├── samples\ ← 示例 PDF，用来验证环境 └── README.txt ← 参数说明

_internal目录存不存在，决定了你这个包是「单文件模式」还是「目录模式」。单文件模式启动慢（每次都要把内部文件解压到临时目录），目录模式启动快。两种都能用，别因为看到一堆 dll 就以为中病毒了。

3.2 解除锁定与首次启动的两种姿势

从网络下载的压缩包，解压出来的文件会带一个「来自其他计算机」的标记，Windows 会因此限制它的执行权限。表现是双击后弹一个「Windows 已保护你的电脑」的蓝色窗口，或者干脆没反应。

先解除锁定：

# 递归解除目录下所有文件的网络来源标记 Get-ChildItem -Path "D:\tools\pdf2doc" -Recurse | Unblock-File

这条命令的作用是去掉每个文件的 Zone.Identifier 备用数据流，等价于手动右键属性里点「解除锁定」，只是批量的。执行完不会有任何输出，这是正常的，没消息就是好消息。

然后首次启动，别急着双击，先在命令行里跑一次：

REM 先切到程序目录，保证工作目录正确 cd /d D:\tools\pdf2doc REM 打印帮助信息，验证 exe 能正常加载 pdf2doc.exe --help

为什么要多这一步？因为双击启动时，如果程序崩了，窗口一闪而过，你什么都看不到——尤其是打包时用了无控制台模式（-w参数）的版本，报错信息根本没有输出的地方。而在 cmd 里跑，Python 的 traceback 会完整打出来，是缺 DLL 还是参数错误，一眼就能分辨。这一步是后面所有排查的基础，养成习惯。

如果--help能正常打印参数列表，说明运行库、路径、权限三关都过了，双击大概率也能用。如果这一步就报错，直接跳到第 5 章对症处理。

提示：把cd /d D:\tools\pdf2doc和pdf2doc.exe两行存成一个run.bat放在同目录，以后双击 bat 启动，等于每次都在正确的工作目录下运行，还能保留报错窗口。

3.3 用批处理把 pdf2doc.exe 变成拖拽工具

命令行能用之后，就可以做点提升效率的事了。这套工具最顺手的用法不是一个个双击，而是把 PDF 直接拖到批处理文件上批量处理。下面这个脚本我一直在用：

@echo off REM pdf2doc 拖拽批处理：把若干 PDF 拖到本文件上即可批量转换 setlocal enabledelayedexpansion REM %~dp0 是本 bat 所在目录，保证不受当前工作目录影响 set "EXE=%~dp0pdf2doc.exe" set "OUTDIR=%~dp0output" REM 输出目录不存在就先建，exe 自己不会创建 if not exist "%OUTDIR%" mkdir "%OUTDIR%" :loop REM 没有更多参数就退出循环 if "%~1"=="" goto done echo 正在转换: %~nx1 REM 输入输出都用引号包住，防止路径里有空格 "%EXE%" --input "%~1" --output "%OUTDIR%" shift goto loop :done echo 全部处理完成，输出目录: %OUTDIR% pause

逐段说一下逻辑。setlocal enabledelayedexpansion是为了在循环里正确读取变量，虽然这个脚本没用到复杂变量，但带上不会有副作用。%~dp0展开成 bat 文件所在目录的绝对路径（带结尾反斜杠），用它拼EXE和OUTDIR，好处是不管你从哪里启动这个 bat，路径都对。if not exist "%OUTDIR%" mkdir这行必须留着，输出目录不存在时 exe 会直接报错退出，而不是自动创建。

循环部分靠shift推进参数列表，%~1是第一个参数去掉引号后的值，%~nx1只取文件名和后缀，用来打印进度。"%EXE%" --input "%~1" --output "%OUTDIR%"是核心调用，两个路径参数都加了引号——这一步不做，含空格的路径必挂。

最后pause是给自己留个后悔药，批处理跑完窗口不会立刻关掉，能看到哪几个文件成功、哪几个报错。等用熟了、确认没问题，再把这行删掉。

这个脚本还能再改一步：加个时间戳，避免同名文件被覆盖。把set "OUTDIR=%~dp0output"换成带%date%和%time%的目录名即可，不过%date%的输出格式跟系统区域设置有关，中文系统下带「周」字，直接拼进路径会出错，需要时用wmic os get localdatetime取值更稳。

4. 参数与环境配置：pdf 转 doc 的输出质量由这几项决定

工具跑起来了，接下来的问题是「转出来的 doc 能不能用」。同一份 PDF，参数不同，输出质量能差出两个档次。这一章讲清楚路径怎么写、参数怎么取舍，以及在什么情况下值得放弃 exe、自己搭一套 Python 环境。

4.1 输入输出路径：引号、盘符与相对路径

路径这件事，在图形界面里点鼠标不会出错，一进命令行全是坑。三条规则记牢：

第一，路径一律用绝对路径加双引号。--input "D:\合同\2024\a.pdf"是能跑的，--input D:\合同\2024\a.pdf在某些参数解析实现下会被空格切断（如果路径里有空格），或者被反斜杠转义搞乱。

第二，相对路径的基准是「当前工作目录」，不是 exe 所在目录。双击运行时工作目录通常就是 exe 目录，但如果你从快捷方式、计划任务或者别的程序里调用，工作目录可能是C:\Windows\System32，此时--input samples\a.pdf会找不到文件。稳妥做法是在脚本开头cd /d %~dp0锁死工作目录，这也是上一章那个批处理里做的事。

第三，输出路径必须指向一个已存在的目录。多数这类工具不会自动创建多级目录，--output "D:\out\2024\06"里如果2024\06不存在，直接报错。要么先mkdir，要么输出到单一目录靠文件名区分。

还有一个实际会遇到的问题：同名覆盖。批量转的时候，两个不同目录下的报告.pdf输出到同一个output目录，后一个会把前一个顶掉，而且没有任何提示。我一般按源文件名加哈希或者时间戳重命名，批处理里用%~n1_%random%.docx之类的简单方式也能应急。

4.2 转换参数取舍：页面范围、图片压缩与表格

具体参数名以你手上这个包的--help输出为准，不同时间打包的版本会有出入。下面这张表是我这个版本里实际存在的几项，以及调它们会带来什么变化：

几个取舍经验。页面范围这个参数看着不起眼，实际是最省时间的：一个 500 页的标书，先--start 1 --end 10转十页看看表格和页眉页脚还原得怎么样，满意了再全量跑，比闷头等二十分钟强得多。加密 PDF 不给密码的话，报错信息通常很含糊（「文件无法打开」），容易误判成文件损坏，先确认一下 PDF 打开时要不要密码。

更重要的一件事：先判断你的 PDF 是文本型还是扫描件。这个判断决定了后面所有参数的意义。文本型 PDF 里的文字是可提取的字符，转出来的 doc 能编辑；扫描件本质上是一堆图片，转出来的 doc 里只有图片，看着「转换成功」，实际一个字都改不了。用一段 Python 几秒钟就能判断：

import fitz # PyMuPDF，pip install pymupdf doc = fitz.open(r"D:\samples\test.pdf") text = "".join(page.get_text() for page in doc) print(f"页数: {doc.page_count}, 可提取字符数: {len(text)}") if len(text) / max(doc.page_count, 1) < 50: print("疑似扫描件，转出的 doc 里会是图片，需要 OCR 才能编辑")

这段代码遍历每一页调get_text()，把可提取的文字拼起来统计长度。判断阈值用「平均每页少于 50 个字符」是个经验值——正常文本型 PDF 每页几百到上千字符，扫描件接近 0，偶尔有几页带页眉文字的会在几十的量级。这个判断很重要，因为这套 pdf2doc.exe 不含 OCR 引擎，遇到扫描件不要反复重试换参数，那是白费功夫，得换工具。

4.3 换条路走：自己搭 Python 环境跑源码并打包 exe

如果你需要改转换逻辑、加批量重命名、或者想把工具塞进自己的流水线，那就别用现成的 exe，自己搭一套。这套环境不复杂，Python 3.9 到 3.11 之间挑一个都行，太新的版本有时第三方库轮子还没跟上。

# 建一个独立虚拟环境，别污染系统 Python py -3.11 -m venv venv venv\Scripts\activate # 升级 pip 再装依赖，顺序别反 python -m pip install --upgrade pip pip install pdf2docx pyinstaller # 先用解释器直接跑，确认逻辑没问题 python pdf2doc.py --input "D:\samples\test.pdf" --output "D:\out"

py -3.11 -m venv venv里的-3.11是版本选择器，机器上装了多个 Python 时靠它指定；venv\Scripts\activate是 Windows 下的激活脚本路径，Linux 下是venv/bin/activate，别搞混。依赖装两个就够：转换库负责解析 PDF 和生成 docx，打包工具负责封成 exe。

跑通之后打包：

# 先用控制台模式打包，方便看报错 pyinstaller -D -c -n pdf2doc pdf2doc.py # 确认没问题后，再换成无控制台的单文件模式 pyinstaller -F -w -n pdf2doc pdf2doc.py

四个参数的差别值得说清楚，因为这直接对应了本文开头那个「双击闪退」的坑。-D是目录模式，输出的dist\pdf2doc\里有一堆文件，启动快；-F是单文件模式，所有东西封进一个 exe，启动时要先解压到临时目录，首次启动明显慢，文件越大越明显。-c保留控制台窗口，报错能看见；-w去掉控制台，界面干净但出问题时两眼一抹黑。

我的一般做法是：调试阶段用-D -c，稳定之后再出-F -w给不碰命令行的人用。如果你拿到的现成包是-w打包的，遇到闪退就按第 3 章的办法，从命令行启动，把报错捞出来。

注意：PyInstaller 打包出来的 exe，在某些杀软眼里特征很像恶意程序，这是打包机制决定的，不是包本身有问题。处理办法见下一章。

5. 常见问题排查：闪退、缺 DLL、被杀软拦、转出来是空白

这一章是我自己踩过的、以及帮别人远程处理时遇到频率最高的五类问题。每一条都按「现象、原因、解决」写，照着对号入座就行。

5.1 双击一闪而过，看不到任何报错

现象：双击 pdf2doc.exe，鼠标转一圈，什么都没发生，任务管理器里进程出现又消失。

原因：三种可能。一是打包时用了-w无控制台模式，Python 抛出的异常没有输出目标，直接吞掉；二是程序启动时工作目录不对，找不到同目录的依赖文件；三是参数缺失，程序要求必须给输入文件，双击时没有任何参数，它解析失败就退出了。

解决：从命令行启动，把报错捞出来。

cd /d D:\tools\pdf2doc pdf2doc.exe --help

如果--help能出结果，说明程序本身没问题，双击失败是因为没给参数——那就用第 3 章的拖拽批处理，或者建个快捷方式在「目标」里补上参数。如果--help也闪退，把命令换成pdf2doc.exe --help > log.txt 2>&1，日志会写进 log.txt，里面通常能看到缺哪个 DLL 或者哪行代码出错。

5.2 提示缺少 vcruntime140.dll 或 api-ms-win-crt

现象：弹窗报「计算机中丢失 vcruntime140.dll」或「api-ms-win-crt-runtime-l1-1-0.dll」，程序无法启动。

原因：系统没装 Visual C++ 运行库，或者装的是 32 位版本而程序是 64 位的。这个错误跟 pdf2doc.exe 本身一点关系没有，换任何 Python 打包的工具都会报。

解决：装微软官方的 Visual C++ 2015-2022 Redistributable 的 x64 版本，装完重启。别去第三方站点单独下那个 dll 文件丢进 System32，版本错配会导致其他程序连环崩，而且卸载不干净。装完用第 2 章那三条dir命令复查一遍，三个文件齐了再跑。

5.3 杀软与 Windows Defender 把 exe 删了

现象：解压完还在，过一会儿文件没了；或者双击时提示「此应用已被阻止」，日志里能看到被隔离的记录。

原因：PyInstaller 打包的单文件 exe，运行时会把自身解压到临时目录并执行，这个行为特征跟某些恶意程序高度相似，启发式扫描容易误判。这不是你这个包特有的问题，所有 Python 打包工具都有。

解决：把整个程序目录加进杀软的排除列表，Windows Defender 的路径是「病毒和威胁防护 → 管理设置 → 排除项 → 添加排除项 → 文件夹」。加之前先确认包是从可信来源拿到的，确认没问题再加。加完把被隔离的文件恢复回来，或者重新解压一次。如果你自己打包，用代码签名证书签一下能显著降低误报率，个人用户就算了，成本不划算。

5.4 转出来的 doc 打不开、乱码或整页空白

现象：转换过程显示成功，output 目录里也有文件，但用 Word 打开提示「文件已损坏」，或者打开后全是乱码方块，或者干脆一片空白。

原因：按出现频率排——路径带中文导致编码错乱；PDF 本身是扫描件所以只有图片（不算故障）；PDF 有权限密码但没提供；转换中途磁盘满了导致文件写了一半；用 WPS 打开而文件实际是 docx 格式但后缀被改成了 doc。

解决：按顺序排查。先看文件大小，0 字节或者明显偏小就是写入失败，检查磁盘空间和输出目录权限。再看路径，把输入输出都挪到纯英文路径下重试。然后用 4.2 节那段 Python 判断是不是扫描件。最后确认文件真实格式：

# 读文件头几个字节，docx 本质是 zip，开头是 PK Format-Hex -Path "D:\out\test.docx" -Count 4

输出里如果看到50 4B（也就是 ASCII 的PK），说明这是标准的 docx，用 Word 打开没问题，WPS 报错就升级 WPS 版本。如果开头是D0 CF 11 E0，那是老的 doc 二进制格式，说明工具输出的是 doc 而非 docx，同样用 Word 能开。

5.5 大文件卡死、进度条不动的处理顺序

现象：转一个几百页的 PDF，卡在某一页十几分钟不动，CPU 占用很低，内存占用一路涨。

原因：这类工具是逐页解析再重建文档结构的，页数一多内存占用是线性增长的；PDF 里如果有特别复杂的矢量图或者嵌套表格，单页解析耗时会突然拉长；还有一种情况是 PDF 本身有损坏，解析器在某一页死循环重试。

解决：先用页面范围分段处理，这是最有效的手段。

REM 分三段转，每段 200 页，中间失败不影响已完成的部分 pdf2doc.exe --input "D:\samples\big.pdf" --output "D:\out" --start 1 --end 200 pdf2doc.exe --input "D:\samples\big.pdf" --output "D:\out" --start 201 --end 400 pdf2doc.exe --input "D:\samples\big.pdf" --output "D:\out" --start 401 --end 600

分段之后还要合并，用 Word 的「插入 → 对象 → 文件中的文字」按顺序合并就行，比装额外的合并工具省事。如果分段后还是卡在固定某一页，那就是那份 PDF 该页有问题，用阅读器单独导出那一页重试，或者直接跳过——为了两页内容耗一晚上不值得。另外转之前先把其他占内存的程序关掉，这类工具在 8G 内存的机器上转 500 页以上确实吃力。

6. 装完怎么验证：三份样本文件跑通才算收工

装完不等于能用。我见过太多「装好了」的机器，实际转出来一塌糊涂，等到真正要用的时候才发现。验证这一步花十分钟，比后面返工强。准备三份样本，覆盖三种典型场景：

三份都跑一遍，命令统一用：

cd /d D:\tools\pdf2doc pdf2doc.exe --input "D:\tools\pdf2doc\samples\text.pdf" --output "D:\out" pdf2doc.exe --input "D:\tools\pdf2doc\samples\table.pdf" --output "D:\out" pdf2doc.exe --input "D:\tools\pdf2doc\samples\scan.pdf" --output "D:\out"

纯文字那份，打开后重点看段落有没有被拆成一堆短行——这是 PDF 转 doc 最常见的毛病，转换器把每个换行都当成段落分隔，结果一段话变成七八段。如果遇到，说明这版工具的段落合并策略偏保守，可以试试带--no-image参数重跑一次对比。

表格那份，看的是结构。把光标点进表格里，如果 Word 顶部出现「表格工具」的选项卡，说明是真表格；如果只是看起来像表格但点不进去，那就是被渲染成了图片或者文本框，这份文档后续没法编辑数据。

扫描件那份，目的不是要求它转出可编辑文字，而是确认它能正常输出、不报错、不卡死。输出里是图片就对了，这套包的能力边界到此为止，需要 OCR 就换专门工具。

最后再用一段脚本做机器校验，比肉眼翻页靠谱：

from docx import Document # pip install python-docx doc = Document(r"D:\out\text.docx") print(f"段落数: {len(doc.paragraphs)}") print(f"表格数: {len(doc.tables)}") print(f"图片数: {len(doc.inline_shapes)}") # 抽查前三个非空段落，确认文字不是乱码 for p in [p.text for p in doc.paragraphs if p.text.strip()][:3]: print("首段:", p[:50])

len(doc.paragraphs)给出段落总数，跟原 PDF 的段落数量量级对得上就说明没把整篇拆碎；len(doc.tables)是零就说明表格没还原成结构；len(doc.inline_shapes)能反映图片有没有丢。最后那个列表推导过滤掉空段落，取前三段打印，如果出现大量问号或者方块，就是编码环节出了问题，回到第 5 章 5.4 节处理。

从那以后我每次在新机器上装这类转换工具，都会强制走一遍这三份样本的流程，哪怕只是换了台电脑、系统版本一样。因为真正的坑从来不在工具本身，而在那台机器的运行库版本、路径设置和杀软策略上，这些你不跑一遍是看不出来的。这份自己整理的 pdf2doc 包，解压就能用，但前提是环境对了——希望帮到你。

本文还有配套的精品资源，点击获取