简介这是一款面向日常办公与文档处理场景的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 的拆解页面、区块、样式三层怎么落成 docx2.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 rD:/in/report.pdf docx_path rD:/out/sample.docx cv Converter(pdf_path) try: # start/end 为页索引end 不包含只转第 1 页观察效果 cv.convert(docx_path, start0, end1) 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 EXED:\tools\pdf2doc\pdf2doc.exe set SRCD:\in set DSTD:\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(rD:/in) DST Path(rD:/out) LOG Path(rD:/out/_convert.log) TIMEOUT 180 # 单文件上限秒超过说明这页有复杂矢量图或表格 DST.mkdir(parentsTrue, exist_okTrue) 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(parentsTrue, exist_okTrue) # 已存在且非空则跳过支持断点续跑 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_outputTrue, textTrue, timeoutTIMEOUT ) 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, encodingutf-8).write(fTIMEOUT\t{pdf}\n) except Exception as e: fail 1 print(f[FAIL] {pdf.name} {e!r}) LOG.open(a, encodingutf-8).write(fERROR\t{pdf}\t{e!r}\n) print(fdone ok{ok} skip{skip} fail{fail})几个参数值得解释。TIMEOUT180是经验值正常二三十页的文档几秒到几十秒就完了超过三分钟基本可以判定那一页有问题比如嵌了大尺寸矢量图或者复杂合并单元格表格与其等下去不如掐掉人工看。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判断相邻两表列数一致、前表最后一行的首列不等于表头首列时把后表的行搬到前表末尾。这活儿没有通用解规则得按你的文档类型单独写。三类页面的策略差异我整理成一张表页面类型判断依据处理策略主要失败表现纯文本单栏文本块 x 分布单峰直接整本转人工校对段落粘连、行距错乱表格页大量水平/垂直短线段单独抽页转再合并单元格错位、跨页断表双栏/多栏文本块 x 分布双峰按栏裁切后分别转左右栏串行、阅读顺序乱扫描件抽取文本长度接近 0先 OCR再转整页空白或只有一张图加密件打开时要求密码先解密再转直接报错或输出 0 字节4.2 双栏文档先判断栏数再决定裁不裁双栏的判断不难拿一页的文本块矩形统计它们的中心点 x 坐标分布。单栏文档的分布是一个明显的峰双栏是两簇。用 PyMuPDF 抽一页看看就清楚import fitz # 新版包名是 pymupdffitz 作为兼容别名仍然可用 doc fitz.open(rD:/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(rD:/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 时只能填占位符。这不是编码设置能解决的问题跟你在脚本里写不写encodingutf-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(rD:/in).glob(*.pdf)): print(triage(p))is_encrypted只判断有没有加密标记不判断是否需要打开密码实际用的时候还得试着打开一次才算数。idx用集合去重避免页数很少时重复抽同一页。这条预检只读取元信息和文本不解码图片所以速度很快几千份也扛得住。转换后抽检我盯两个数段落数和总字符数。正常文档每页大概十几个到几十个段落如果一份 30 页的文件转出来只有 5 个段落基本可以判定段落聚合失败正文被塞进了少数几个巨型段落里字符数低于源文件抽样字符数的一半说明有内容丢失。这两个阈值按你自己的文档类型调我一般设成「段落数 页数 × 3」和「字符保留率 60%」两条触发人工复核。抽检项计算方式触发阈值大概率原因段落数len(Document(p).paragraphs)低于页数 × 3段落粘连、整页识别成一块字符保留率docx 字符数 / PDF 抽样字符数低于 60%部分页空白、字体缺失表格数len(Document(p).tables)源含表格却为 0表格识别失败退化成文本空文件大小 10KB触发转换中断、加密未解这张表跑一遍几十行代码但能挡掉九成以上的「转完了但其实是废的」。从那以后我每批 PDF 进流水线之前都强制先跑一遍样张加预检哪怕只有三个文件也不例外——宁可多花两分钟也不要在交付前一天晚上发现三百份 docx 全是空白页、被迫通宵重来。希望帮到你。本文还有配套的精品资源点击获取
