简介：这是一款面向日常办公与文档处理场景的PDF转Word工具包，适合需要将PDF内容转为可编辑docx的Windows 10/11用户。工具由Python整理打包，支持单个文件、多个文件以及整个文件夹的批量转换，转换结果以docx形式输出，兼顾零散文档处理与成批资料整理需求。压缩包共1154个文件、约105.54MB，除exe可执行入口外，还包含msg、enc、qm、tcl、pyd、dll、py等类型文件，主要对应Python运行时、本地化与时区数据、动态库及脚本等支撑内容，目录完整度较高。已有142人学习或下载。其价值在于把PDF解析与Word文档生成流程封装为可直接使用的桌面工具，省去自行配置Python环境和拼接库的过程；同时强调无广告及不良程序，适合对转换准确性与文件完整性有要求、又希望减少额外软件安装的办公人员使用。

1. 解压就能跑：pdf2doc.exe 替你焊死了哪几层依赖

第一次拿到这个包，我先把它当一个黑匣子看待：一个 exe，双击就把 pdf 转成 doc，听起来太像那种点开先装三个全家桶的东西。拆开看其实很朴素，就是 Python 脚本用打包工具封成单文件，把解释器、pdf 解析库、docx 写出库和字体映射表一起塞进可执行文件里。所以在 windows10 和 windows11 上，你不用装 Python、不用配环境变量、不用 pip install 折腾半小时。这个取舍是划算的：牺牲灵活性，换掉新手 90% 的门槛。适合整理合同、论文、票据，把别人发来的 PDF 改两行字的场景；不适合要求像素级还原排版、或者一次要吞几千页归档的活儿，那种得自己写脚本。

2. 从 PDF 到 DOCX 的拆解：页面、区块、样式三层怎么落成 docx

2.1 复制粘贴和「另存为」为什么注定失败

先要认清一个事实：PDF 里根本没有「段落」这个概念。页面内容流里存的是一串绘制指令，每个字符都带着自己的坐标被画到某个位置上，行与行、段与段的关系是靠坐标算出来的，不是靠结构记下来的。你框选复制的时候，阅读器只能按 y 坐标从上往下、x 坐标从左往右把字符拼回去，遇到双栏文档就变成左右栏串成一句，遇到三线表就散成一堆碎片。这就是为什么很多人复制一份两栏排版的 PDF，粘进 Word 之后读起来像天书。

DOCX 这边完全是另一套逻辑。它是流式文档，段落是一个对象，段落里跑着若干 run（文字片段），每个 run 记字体、字号、粗斜体、颜色；排版引擎在打开文件时才决定每行放多少字。也就是说，PDF 是「已经画好的坐标图」，DOCX 是「还没排版的原料」。所谓 pdf 转 doc，本质是重新排版，不是格式换壳。

理解这一层之后，你对转换质量的预期就合理了。工具能做的是：把散落的字符按坐标重新聚成行，把行聚成段，把段判定成普通文本、图片还是表格区域，再分别写成 docx 的 paragraph、inline shape、table。它做不了的是：凭空恢复原文档里作者的段落意图、列表层级、交叉引用。所以转出来的东西永远需要人工过一遍，任何宣称「零修改」的做法都值得怀疑。

2.2 三层结构：解析层、排版层、输出层

这类工具内部通常是三段式。解析层拿 PDF 页面的字典结构，也就是 block → line → span 的层级，span 是同一行内字体属性一致的最小片段，里面带着文本内容、字号、字体名、颜色、bbo� 坐标。排版层做的事最有技术含量：把所有 span 按 x 坐标聚类判断有没有分栏，按行间距判断段落边界，按字号突变的跨度判断标题级别，按线段和空白区域判断表格结构。输出层就简单了，调 python-docx 建段落、设 run 的字体字号、画表格边框。

这里有个容易踩的认知误区：很多人以为字号大的就是标题，实际不行。封面上的大字号可能是水印，页脚的小字可能是页码，正文里的加粗可能是强调而不是标题。合格的实现会综合字号、加粗、居中、上下留白四个信号投票，而不是单看一个。你在调优的时候，思路也应该对齐这个逻辑——想让识别更准，就从这四类信号下手，而不是去改输出端的样式表。

另外一个细节是字体映射。PDF 为了减小体积会对字体做子集化，只嵌入文档里用到的那些字形，并且给每个字形一个自定义编码。如果原文件里没带 ToUnicode 映射表，解析层拿到的就是一串没有意义的编码值，转出来就是方框、问号或者拉丁乱码。这是中文 PDF 转换翻车最常见的原因之一，跟工具有没有 bug 关系不大，源头文件就缺信息。

2.3 先用一页样张探路，把参数试出来

不管后面要转多少文件，第一步永远是拿一页试。整本转完发现表格全散，回头再找原因是纯浪费时间。命令行方式最直接，先把第 1 页单独抽出来看效果：

# 只转前 1 页做样张，页索引从 0 开始，end 不含该页 pdf2docx convert "D:/in/report.pdf" "D:/out/sample.docx" --start 0 --end 1 # 也可以指定不连续的页码，先挑最复杂的那几页 pdf2docx convert "D:/in/report.pdf" "D:/out/sample2.docx" --pages 0 3 7

--start和--end是页索引区间，左闭右开，第 1 页是 0 不是 1，这点跟人直觉相反，写错就会得到一份空文档还以为工具坏了。--pages接受一串页码，适合挑样张：封面、目录、有表格的那页、双栏的那页，各来一张，一次看清四类问题。

Python 接口更灵活，适合塞进自己的脚本里：

from pdf2docx import Converter pdf_path = r"D:/in/report.pdf" docx_path = r"D:/out/sample.docx" cv = Converter(pdf_path) try: # start/end 为页索引，end 不包含；只转第 1 页观察效果 cv.convert(docx_path, start=0, end=1) finally: cv.close() # 必须显式关闭，否则文件句柄不释放，后续覆盖会失败

Converter在初始化时就把 PDF 打开并解析了页面结构，所以对同一个 PDF 连续转多个区间，复用一个实例比反复新建快得多。convert的start/end控制页码范围，pages参数可以传列表覆盖区间写法。close()放在finally里是要点——这个库持有底层文档对象，异常路径下不关，进程会一直占着源文件，Windows 上表现为「文件正被另一个程序使用」，很多人误判成权限问题。

样张看完再决定策略：如果表格全散，考虑先单独处理表格页；如果双栏串行，考虑按栏裁切后再转；如果整页空白，先确认这份 PDF 到底有没有文本层。这三个判断，比盲目调参数有效得多。

3. 把 exe 用成流水线：批量、命名、重试三个具体动作

3.1 单文件、批量与静默调用

最省事的方式是拖拽：把 PDF 拖到 exe 图标上，脚本从命令行参数里拿到路径，转完在源文件旁边生成同名 docx。这种方式适合一天转两三个文件的场景，缺点是每次都弹一个窗口，几十个文件就是几十次点击。

如果这个 exe 保留了命令行入口（打包时没有把sys.argv直接写死），那就可以在批处理里循环调用，把交互彻底去掉：

@echo off rem 逐个把 in 目录下的 PDF 交给 exe，输出到 out 目录 set EXE="D:\tools\pdf2doc\pdf2doc.exe" set SRC=D:\in set DST=D:\out for %%f in ("%SRC%\*.pdf") do ( echo converting %%~nxf %EXE% "%%~ff" "%DST%\%%~nf.docx" )

%%~nf取不含扩展名的文件名，%%~ff取完整路径。这里有个兜底思路：如果你拖进去能用、命令行调没反应，说明打包时没接参数入口，那就退回到「把 PDF 全丢进 exe 同目录、让它自己扫」的用法，或者干脆用下一节的 Python 脚本自己实现一层，反正底层的转换逻辑是一样的。

我更倾向第二种。原因很实在：exe 是黑匣子，失败了你不知道卡在哪一页、哪个异常；自己写脚本能拿到每一页的耗时和异常栈，几十个文件的批次里，这个信息价值远大于省下的几行代码。

3.2 输出命名、覆盖与目录结构

批处理最容易出的事故不是转换失败，是覆盖。上一批转出来的合同.docx被这一批同名文件悄悄盖掉，等你发现的时候原始版本已经没了。血泪经验是：输出目录永远和输入目录分开，文件名加上时间戳或者哈希后缀，宁可长一点。

命名策略上我是这么做的：原名__转换日期.docx，比如2024年度报告__20250312.docx。好处是一眼能看出这份是哪个源文件、哪次转的，重跑不会覆盖，想清理旧版本按日期筛就行。如果同一个源文件要反复转着调参，再加一个后缀区分：__v2、__tablefix，别嫌丑，比事后翻记录强。

目录结构按输入目录的层级镜像过去，用relative_to保住子目录关系。很多人的批量脚本只 glob 顶层，子目录里的 PDF 全漏掉，跑了半天以为转完了，实际漏了一半。

3.3 用脚本包一层：日志、跳过与超时

真正能长期用的批量脚本，核心不是转换那一行，是外围三件事：已经转过的跳过、失败的单独记、卡死的能掐断。参考实现：

import subprocess import sys import time from pathlib import Path SRC = Path(r"D:/in") DST = Path(r"D:/out") LOG = Path(r"D:/out/_convert.log") TIMEOUT = 180 # 单文件上限，秒；超过说明这页有复杂矢量图或表格 DST.mkdir(parents=True, exist_ok=True) ok = skip = fail = 0 for pdf in sorted(SRC.rglob("*.pdf")): rel = pdf.relative_to(SRC).with_suffix(".docx") out = DST / rel out.parent.mkdir(parents=True, exist_ok=True) # 已存在且非空则跳过，支持断点续跑 if out.exists() and out.stat().st_size > 10 * 1024: skip += 1 continue t0 = time.time() try: # 用子进程隔离：超时可控，崩溃不会带走主进程 proc = subprocess.run( [sys.executable, "-m", "pdf2docx", "convert", str(pdf), str(out)], capture_output=True, text=True, timeout=TIMEOUT ) if proc.returncode != 0: raise RuntimeError(proc.stderr.strip()[-300:]) ok += 1 print(f"[OK] {pdf.name} {time.time() - t0:.1f}s") except subprocess.TimeoutExpired: fail += 1 print(f"[TIME] {pdf.name} 超过 {TIMEOUT}s，记为待查") LOG.open("a", encoding="utf-8").write(f"TIMEOUT\t{pdf}\n") except Exception as e: fail += 1 print(f"[FAIL] {pdf.name} {e!r}") LOG.open("a", encoding="utf-8").write(f"ERROR\t{pdf}\t{e!r}\n") print(f"done ok={ok} skip={skip} fail={fail}")

几个参数值得解释。TIMEOUT=180是经验值，正常二三十页的文档几秒到几十秒就完了，超过三分钟基本可以判定那一页有问题，比如嵌了大尺寸矢量图或者复杂合并单元格表格，与其等下去不如掐掉人工看。subprocess而非直接 import 调用，是为了隔离内存和崩溃——转换库遇到畸形 PDF 是有可能把进程带走的，主进程死了整批就断了。

out.stat().st_size > 10 * 1024这个阈值不是随手写的。失败时很多工具会留下一个几 KB 的空壳 docx，光判断exists()会把它当成成功跳过，于是你永远修不好那一份。按大小过滤能把空壳排除掉，重跑时会重新尝试。

日志写成 TSV，用制表符分隔，方便后面用 Excel 或者脚本二次筛选。别用 print 当日志，几百个文件刷屏之后你根本找不回哪一行是失败。

4. 质量调优：表格、双栏、扫描件三类页面的处理差别

4.1 表格：有线表靠线条，无线表靠对齐

表格是转换质量分水岭。有明确线框的表格（三线表、全框表）识别率通常不错，实现思路是二值化后做形态学处理，把横线和竖线提取出来求交点，交点围成的矩形就是单元格。这条路径对线条连续、无遮挡的表格很稳。

无线表就麻烦。没有线条可抓，只能靠文本块的 x 坐标对齐来推断列边界：如果一列文字的左边距高度一致，就认为它们是同一列。这种推断在数字列、短文本列上效果好，遇到长短差异大的描述列就容易错行，把本该在一格的整段话切到相邻单元格里。

跨页表是另一个坑。表格从第 3 页延续到第 4 页，中间被分页符切断，转出来就是两个独立的表，而且第二段丢了表头。处理办法只有事后合并：转完之后用 python-docx 遍历doc.tables，判断相邻两表列数一致、前表最后一行的首列不等于表头首列时，把后表的行搬到前表末尾。这活儿没有通用解，规则得按你的文档类型单独写。

三类页面的策略差异，我整理成一张表：

4.2 双栏文档：先判断栏数，再决定裁不裁

双栏的判断不难，拿一页的文本块矩形，统计它们的中心点 x 坐标分布。单栏文档的分布是一个明显的峰，双栏是两簇。用 PyMuPDF 抽一页看看就清楚：

import fitz # 新版包名是 pymupdf，fitz 作为兼容别名仍然可用 doc = fitz.open(r"D:/in/paper.pdf") page = doc[2] # 取第 3 页 blocks = page.get_text("blocks") # 每项: (x0, y0, x1, y1, text, block_no, type) mid = page.rect.width / 2 left = [b for b in blocks if b[2] <= mid + 5] # 右边界不超过中线 right = [b for b in blocks if b[0] >= mid - 5] # 左边界不早于中线 print(f"页宽 {page.rect.width:.0f} 左栏块 {len(left)} 右栏块 {len(right)}") # 两栏都有足够多的文本块，才认定是双栏 if len(left) > 3 and len(right) > 3: print("判定：双栏，建议按栏裁切后分别转换") doc.close()

get_text("blocks")返回的矩形是块的包围盒，page.rect.width是页面宽度（单位是点，1 英寸 = 72 点）。判断阈值用mid ± 5给了一点容差，因为跨栏的图表可能压在中线上，严格比较会把它们错分。len(left) > 3这个下限是为了避免把带侧边注释的单栏文档误判成双栏。

判定为双栏之后，裁切的做法是用clip参数把每一栏单独输出成新的 PDF 页，再分别转换，最后按「左栏全部内容 + 右栏全部内容」的顺序拼回一个 docx。裁剪会带来副作用：压在中线上的图片会被切掉一半，处理时先把页面里的图片对象单独抽出来，放到拼接后的文档尾部或者原位插入，比让它被腰斩强。

如果文档只有个别页是双栏，别整本套同一套流程。按页判断、按页处理，混合文档就该用混合策略。

4.3 扫描件、加密件与字体缺失的前置处理

扫描件转出来是空白，不是工具的问题，是这份 PDF 里压根没有文字。整页是一张大图，解析层抽不到任何 span，输出自然什么都没有。判断方法很直接：抽三五页，把文本长度加起来，接近 0 就是图片型 PDF。

import fitz doc = fitz.open(r"D:/in/scan.pdf") sample = [0, 1, 2, min(5, doc.page_count - 1)] total = sum(len(doc[i].get_text().strip()) for i in set(sample)) print(f"抽样页数 {len(set(sample))}，文本字符总数 {total}") print("判定：图片型 PDF，需先做 OCR" if total < 50 else "判定：有文本层，可直接转换") doc.close()

阈值 50 是留了余量的，正常正文一页几百到上千字，扫描页除了页眉页码基本为零。这类文件的正路是先过一遍 OCR 把文本层压进去，然后再走 PDF 转 docx 的流程；直接转只会得到一堆图片。

加密 PDF 的处理顺序是先解密再转换。转换库面对需要密码的文件多半直接抛异常，或者更糟——静默输出一个 0 字节文件。用 pikepdf 这类库先把加密解掉，保存成无密码副本再进流水线。别试图在转换脚本里原地处理加密，逻辑纠缠在一起，出错时你分不清是密码错了还是版面解析错了。

字体缺失导致的乱码前面提过，补充一个可操作的分诊办法：转出来如果中文全是方框、英文正常，基本是字体编码问题；如果连英文都是乱码，多半是文件损坏或者压根不是 PDF（改了扩展名的图片、加密壳）。前者换源文件或者上 OCR，后者直接退回让发件人重发。

5. 避坑与排查：五类翻车现场的现象、原因和解决

5.1 输出侧的两类异常：空白与乱码

第一类，转出来的 docx 打开是空白，或者整页只有一张大图。

现象很好认：文件生成了，大小也不小（因为图片被完整嵌进去了），但一个字都搜不到，光标点不进任何段落。原因基本锁定在源文件没有文本层——扫描件、截图拼接的 PDF、某些系统导出的图片型 PDF 都属于这一类。解析层拿到的页面字典里只有 image 块，没有 text 块，工具只能老实把图片贴进 docx。

解决办法是转换前加一道预检，用 4.3 节那段统计文本长度的代码跑一遍，低于阈值就转 OCR 流程。别指望调转换参数能救回来，没有文字就是没有文字。另一个容易忽略的变体是「部分页有文本、部分页没有」，一本几十页的文档中间夹了几页扫描件，整本转完发现那几页是空的，逐页预检能提前把这批页挑出来单独处理。

第二类，中文全部变成方框或者问号，英文数字正常。

现象很典型：打开 docx 看到一行行□□□□，复制出来贴到别处还是乱码。原因是 PDF 里嵌的是子集化字体，且缺少 ToUnicode 映射表，解析层拿到的字符编码没有对应的 Unicode 值，写出 docx 时只能填占位符。这不是编码设置能解决的问题，跟你在脚本里写不写encoding="utf-8"毫无关系。

解决路径有三条，按成本排序：换一份带完整字体信息的源文件最省事；不行就退到 OCR，让它重新识别字形而不是读编码；再不行只能人工对照重打关键页。我一般会先花两分钟确认是不是所有中文字体都缺失——如果正文是宋体正常、只有标题的黑体变方框，那说明是部分字体子集的问题，把标题单独重排的代价远小于整篇 OCR。

5.2 运行侧的三类异常：闪退、拦截、路径

第三类，双击 exe 黑窗口一闪就没了。

现象是双击之后屏幕闪一下，什么都没生成，也没有任何提示。原因通常有三个：打包时没带全运行库，缺 VC++ 运行库在部分干净系统上会直接崩；脚本用了相对路径，双击时的工作目录不是 exe 所在目录，找不到输入文件；或者脚本本身在启动阶段就抛了异常，窗口来不及显示就关了。

排查方式很朴素：开一个命令行窗口，cd 到 exe 所在目录，把 exe 拖进去回车。这样异常栈会留在窗口里，能看到具体是ModuleNotFoundError还是FileNotFoundError。这一步能解决八成的「闪退」问题，剩下两成再去看系统事件查看器。

第四类，杀毒软件把 exe 直接删了或者提示风险。

现象是解压完文件还在，过几秒没了，或者运行时弹窗拦截。原因是单文件打包的自解压行为：exe 启动时会把自己解压到临时目录再执行，这个动作和某些恶意程序的行为特征重合，启发式引擎容易误判。这不是文件真的有问题，但也不能简单粗暴地关防护。

可行的做法：把工具目录加进白名单；或者打包时选目录模式（一堆 dll 加一个 exe），行为特征温和很多；最稳的是自己从源码打包一遍，你清楚每一行代码干什么，跑起来心里有底。给别人分发的时候，附一句说明比让人自己猜要体面得多。

第五类，路径里有中文或者空格，转换报错或者输出 0 字节。

现象是同一份 PDF 放在D:/in/下能转，放到D:/我的文档/2024 年度报告/下就失败。原因是脚本里路径拼接没做处理，或者调外部命令时没加引号，空格把参数切成了两段。老脚本在这上面翻车的特别多。

解决办法不复杂：输入输出都放到短英文路径下，比如D:/pdfwork/in、D:/pdfwork/out；脚本里所有路径用pathlib.Path拼，别用字符串加号；调外部命令时参数作为列表传给subprocess，别自己拼命令行字符串。这三条做到，路径类问题基本绝迹。

5.3 排查顺序：先隔离文件，再隔离环境

出问题的时候最忌讳的是同时改三个变量：换工具、换文件、换机器，然后发现好了，却不知道是哪一步起的作用。我的固定顺序是这样：

先隔离文件。拿一份确定能正常转换的小 PDF（自己用 Word 导出两页），跑一遍。能过，说明工具和环境没问题，问题在源文件；不能过，往下走。

再隔离环境。换一台机器，或者新建一个干净目录重新解压工具包，跑同一份文件。这台能过那台不能过，方向就指向运行库、权限、杀毒拦截。

最后隔离页面。整本转失败但单页能过，就用--pages二分，每次转一半，几轮就能定位到具体哪一页出问题。定位到页之后再看那一页有什么特殊：是不是有超大的嵌入图、是不是有合并单元格特别复杂的表、是不是有旋转过的文本块。找到特征，才有针对性的处理办法。

这套顺序的价值在于，它保证每次只动一个变量，结论是可信的。跳过这一步凭感觉调参数，很容易陷入「改了十处，好了，但不知道哪处起作用」的玄学状态，下次遇到还得从头再来。

6. 进阶：转换前预检与转换后抽检的一条完整链路

单次转换靠肉眼验收没问题，一旦上到几百份，验收就成了瓶颈。我的做法是在流水线两头各加一道自动检查，中间才是转换。

转换前预检，输出一张分诊表：页数、是否加密、抽样文本长度、是否双栏、是否含表格线。这一步用 PyMuPDF 跑，几秒钟就能过完一个目录，成本极低但收益很大，因为它把「注定失败」的文件提前挑出来了。

import fitz from pathlib import Path def triage(pdf_path: Path): doc = fitz.open(pdf_path) if doc.is_encrypted: doc.close() return {"file": pdf_path.name, "route": "decrypt"} idx = list({0, 1, doc.page_count // 2, doc.page_count - 1}) chars = sum(len(doc[i].get_text().strip()) for i in idx) doc.close() if chars < 50: return {"file": pdf_path.name, "route": "ocr"} # 走 OCR 分支 return {"file": pdf_path.name, "route": "convert"} # 走常规转换 for p in sorted(Path(r"D:/in").glob("*.pdf")): print(triage(p))

is_encrypted只判断有没有加密标记，不判断是否需要打开密码，实际用的时候还得试着打开一次才算数。idx用集合去重，避免页数很少时重复抽同一页。这条预检只读取元信息和文本，不解码图片，所以速度很快，几千份也扛得住。

转换后抽检，我盯两个数：段落数和总字符数。正常文档每页大概十几个到几十个段落，如果一份 30 页的文件转出来只有 5 个段落，基本可以判定段落聚合失败，正文被塞进了少数几个巨型段落里；字符数低于源文件抽样字符数的一半，说明有内容丢失。这两个阈值按你自己的文档类型调，我一般设成「段落数 < 页数 × 3」和「字符保留率 < 60%」两条触发人工复核。

这张表跑一遍几十行代码，但能挡掉九成以上的「转完了但其实是废的」。从那以后我每批 PDF 进流水线之前，都强制先跑一遍样张加预检，哪怕只有三个文件也不例外——宁可多花两分钟，也不要在交付前一天晚上发现三百份 docx 全是空白页、被迫通宵重来。希望帮到你。

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