PDF转Markdown听上去是个小需求但真上手你会发现最折磨人的不是格式丢了多少而是那该死的换行。从PDF里扒出来的文本十有八九是每一行都断开的贴进Markdown编辑器以后整段文字碎成一地你只能一行一行手工拼接。做一次两次还能忍碰到那种几十页的技术文档手工删换行删到怀疑人生。我自己处理过不下百份PDF转Markdown的活学术论文、技术手册、产品说明书都转过。这个需求看着简单但牵扯到PDF的底层结构、解析引擎的选型、还有后处理脚本的细节哪一环没处理好最后都得靠手工兜底。这篇就说说我踩过的坑和真正有效的方案为什么转换后会有换行问题、不同场景怎么选工具、以及如何做到基本不需要手工删换行。适合被PDF排版折磨过的开发者、文档工程师和知识管理爱好者。1. 为什么PDF转Markdown的换行问题这么烦人1.1 PDF的换行本质不是文本是坐标PDF和Word有个本质区别。Word是流式文档文字是一个连续的流换行是动态计算出来的段落结构清清楚楚你把正文复制出来一定是完整的段落。PDF恰恰相反它是最终排版结果每一页上的每个字符记录的是“在哪个位置把这个字形画出来”存的是坐标。PDF里根本没有“段落”这个对象只有“这一行画在哪里、下一行画在哪里”。所以你会遇到一个很诡异的现象从PDF复制文字常常是一行一行断开的内容。这不是你的阅读器有问题而是PDF本来就只“认识”行不“认识”段。PDF内容流里确实有换行标记但这种标记通常代表“这一行结束了下一行开始”跟段落结束没有必然关系。段落结束在视觉上往往靠空行或缩进体现但PDF内部一般没有对应的语义标记。这说明一个关键问题任何工具想把PDF转成结构良好的Markdown第一步必定是做“行合并”把属于同一段落的多行物理行合并成一个逻辑段落。这一步做得好不好直接决定你拿到的是正常段落还是碎行。1.2 换行问题的三种典型表现第一种是行尾硬断行最常见。整段文字在PDF里每行末尾被截断转出来之后从Markdown源码看一堆短行渲染出来虽然能连读但后续做翻译、做检索、做摘要都会被这种碎行折磨。第二种是连字符断词。英文PDF很常见单词“implementation”在行尾被断成“implementa-tion”转换工具直接暴力抽出文本连字符就留在那里了。转完之后的文本乍一看像拼写错误实际上要逐个还原非常难受。中文文档少见一点但中英文混排的PDF也有概率遇到。第三种是代码和表格被拆散。代码块的缩进、表格的竖线对齐一旦被物理行拆散转出来的Markdown基本不能用。你得重新对齐、重新拼单元格这种手工工作量比删换行还大。这三种问题的根源是同一个解析工具没有做语义层面的段落重建。有的工具干脆不做有的做了但只看缩进不看语义。理解了这一点后面选工具你就有了判断力。1.3 为什么有的工具转出来是好的关键差别在于是否做了版面分析和段落重建。像Marker、MinerU这类基于深度学习的解析引擎会先做版面检测识别出文本块、标题、表格、图片、公式各自的区域然后在每个文本块内部做行合并再判断块与块之间是内容延续还是新段落。这个思路接近人眼阅读效果自然好。传统工具pdftotext呢它只是把坐标排序后一行行输出不做段落判断所以转出来的就是物理行。顺带提一句网上很多人推荐“先把PDF转Word再转Markdown”这个绕路方案本质上是借用了Word的段落重构能力对纯文本文档确实有效。但遇到多栏、文本框、复杂表格时经常水土不服而且Word导出的HTML再转Markdown格式冗余特别多后续清理也麻烦。我试过几次之后就不太推荐这条路线了。2. 工具选型不同场景的最优解2.1 先判断你的PDF属于哪一类拿到PDF别急着转先分个类。我会把PDF分成四类这个分类直接决定工具选型也直接决定你后面要花多少时间处理换行。PDF类型典型特征建议路线纯文本型由文字排版生成无扫描图片无复杂排版pdftotext/pandoc扫描型整页是图片没有文本层OCR路线图文混排型含图片、表格、多栏排版Marker/MinerU公式代码型含数学公式、程序代码Marker/MinerU 公式识别纯文本型PDF不复杂但工具选错了也会出问题图文混排型如果不选深度学习引擎手工量会大得吓人。2.2 经典路线Pandoc pdftotext处理纯文本对于纯文本型PDF我最常用的还是poppler-utils里的pdftotext配合pandoc来用。pdftotext把PDF文本抽出来加-layout参数保留物理布局然后交给pandoc转成Markdown。命令大概是这样的pdftotext -layout input.pdf output.txt pandoc output.txt -o output.md注意这一步转出来的Markdown大概率还是有物理行断行因为没有任何工具能在纯文本层面“猜”出哪里是段落结束。不过纯文本场景有个简单粗暴的兜底用脚本把所有非空行之间的单换行合并掉空行保留作为段落分隔。后面第3节我会给详细脚本。这个方案它最大的优点就是轻量、快、好控制。你不需要下载模型不需要GPU一条命令干干净净跑完。缺点是遇到复杂排版基本白给所以它只适合纯文本。2.3 复杂排版路线Marker和MinerU如果你的PDF有表格、有配图、有多栏排版就别硬用pdftotext了。我推荐两个开源工具一个是Marker一个是MinerU。Marker是Python写的安装简单pip install marker-pdf转换命令也简单marker_single input.pdf --output_dir ./outputMarker对段落重建做得很到位标题、列表、表格、引用都能识别输出自带Markdown结构。换行问题在它这里基本消失因为它已经把段落识别好了。缺点是第一次运行要下载模型机器没有GPU的话会慢一些但也不是不能忍。MinerU是另一个好选择版面分析能力很强尤其适合中文PDF对公式和表格的抽取比Marker更激进纯CPU环境下也能跑。选择上我的经验是英文文档优先Marker中文文档优先MinerU都不行的再上OCR。这真的只是经验总结不是硬标准你可以两个都拿同一份PDF跑一下看哪个输出更顺眼就留哪个。2.4 兜底路线OCR不适合换行合并扫描版PDF没有文本层不管什么解析引擎都拿不到文字必须走OCR。PaddleOCR和Tesseract都可以但你要明白OCR引擎输出的也是“识别出的文字”加“每个文字块的坐标”它同样没有段落概念还是需要你自己按坐标排序再合并。处理扫描版的思路是这样先OCR成带坐标的结构化输出然后按文本块的垂直坐标聚类判断哪些行属于同一个段落。同一段落内行与行之间的距离通常比较小不同段落之间垂直距离会明显变大。这个阈值需要你根据实际PDF的排版密度去调。特别提醒一下很多在线OCR工具默认按行输出你导出来的结果照样一堆硬换行。所以扫描版PDF想做到“不手工删换行”核心还是得靠坐标聚类脚本而不是换了工具就万事大吉。2.5 选型速查表场景推荐工具换行处理效果备注纯文本英文PDFpdftotext pandoc需脚本合并最轻量适合批量纯文本中文PDFMinerU自动合并中文版面检测更准图文混排/含表格Marker自动合并效果好优先考虑GPU扫描版PDFPaddleOCR需坐标聚类合并时间成本最高数学公式多Marker Mathpix公式可转LaTeXMathpix是商业服务注意费用3. 实操三步做到不手工删换行3.1 第一步搭好工具链这一步真正开始动手。以最常见的图文混排文档为例我推荐Marker加Python后处理脚本的组合。先搭环境pip install marker-pdf pip install pypandoc如果机器有NVIDIA显卡先把CUDA环境配好Marker会快很多。没有GPU也不怕CPU模式慢一点但能出结果。后处理脚本需要Python环境建议用Python 3.9以上。这里有个细节容易被忽略Marker的模型是首次运行才下载的国内网络环境有时候会很慢。我的做法是把模型目录单独设置到工作区以外避免每次换环境都重新下载。具体参数是MARKER_MODEL_DIR环境变量设置一次就好。3.2 第二步转换并自动合并段落Marker默认就会做段落合并跑完之后的Markdown基本是干净的。但别急着收工跑完之后我建议你打开文件随便翻几页。遇到特殊的排版比如没有缩进、没有空行、但确实是分段的文档Marker也有可能把整段拼成一大块因为PDF里确实没有段落边界标记。如果你的工具链不是深度学习型的比如用的是pdftotext那转换命令之后就必须加一个行合并脚本。这一步正是“不手工删换行”的关键所在。我之前帮朋友处理一批政府公开的PDF文件就是靠这个脚本把几十页的碎行全部合并成正常段落全程没动过手。3.3 第三步后处理脚本兜底自动合并硬换行这是我总结出来的核心脚本思路你可以直接复制改。原理很简单把转换出来的Markdown按行读入逐行判断是不是“普通文本行”。如果当前行是普通文本而且下一行也是普通文本不是空行、不是标题、不是表格、不是代码块开头就把当前行的末尾换行替换成空格让两行变成一行。如果下一行是空行或者Markdown结构标记就保留原样。import sys def is_special(line): s line.strip() if s : return True if s.startswith(#): return True # 标题 if s.startswith(|): return True # 表格行 if s.startswith(-) or s.startswith(*) or s.startswith(): return True # 列表项保守处理 if s.startswith(): return True # 引用 if s.startswith(): return True # 代码块边界 if s.startswith( ): return True # 缩进代码块 return False def merge_lines(md_text): lines md_text.split(\n) out [] in_code False for i, line in enumerate(lines): if in_code: out.append(line) if line.strip().startswith(): in_code False continue if line.strip().startswith(): in_code True out.append(line) continue if is_special(line): out.append(line) continue # 当前行是普通文本看下一行 if i 1 len(lines): nxt lines[i 1] if not is_special(nxt) and not nxt.strip().startswith(): # 合并去掉当前行尾的换行替换为空格 out.append(line.rstrip() ) continue out.append(line) return \n.join(out) if __name__ __main__: txt open(sys.argv[1], encodingutf-8).read() print(merge_lines(txt))运行方式很简单python merge_lines.py converted.md fixed.md这个脚本里有几个细节值得单独说。第一代码块必须单独处理否则脚本会把代码块里的行全拼成一行那整份文档就废了。我一开始没处理这个问题跑完一份Python手册代码全部成了一行排查了半天才发现是脚本在作妖。第二列表项建议保守处理也就是不合并。为什么因为Markdown的列表里下一行可能是新的列表项也可能是上一项的续行脚本无法判断语义合并错了反而更乱。保守起见凡是-、*、开头的都不合并剩下少量需要微调的手工处理优先级是最高的。第三表格行的识别要优先于普通文本。PDF转出来的表格表头和数据行都以|开头一旦被合并整个表格就废了。第四中文文档没有空格断词合并逻辑和英文不一样。我的建议是中文用空字符串拼接而不是空格英文用空格拼接。可以把脚本里那行改成拼接时根据两行是否包含中文字符来决定。3.4 验证与微调把换行问题消灭在交付前合并完不是就完事了我习惯做三件事。第一在编辑器里搜索\n和\n\n快速扫一遍有没有漏网的碎行。虽然这个搜法治标不治本但对小文件来说肉眼检查非常快。第二打开渲染预览随便找几个段落看看是否通顺重点看各级标题下面那段文字。标题后的正文经常因为标题和正文的间距问题被解析成两段这种问题脚本看不出来只有渲染预览能看到。第三用markdownlint跑一遍。如果提示代码块未指定语言或者某行太长很多就是换行合并没做干净导致的长行。行太长不用太纠结渲染完全没影响但代码块语言标注是值得补一下的。4. 常见问题与排查技巧实录4.1 段落全挤在一起没有空行这是最容易翻车的地方通常是合并脚本过于激进了。你检查一下逻辑只有当下一行不是空行时才合并如果你的原始PDF每个段落之间没有空行很多双栏排版的PDF就是这样那合并之后必然全糊在一起。解决方法是调整策略与其全自动合并不如设置“只合并到从视觉上看是段落结束的位置”也就是根据缩进、字体大小变化来判断。这个判断在纯文本层面很难做所以遇到这种PDF我建议直接用Marker这类版面分析工具而不是靠脚本硬扛。4.2 表格变成一堆散行表格在PDF里就是一组坐标如果解析引擎没有识别出“这是一个表格”它会把每行单元格当成独立段落转出来之后全部变成散落的行。如果你用的工具没有表格识别能力建议单独处理这一页用专门的表格抽取工具转成CSV或HTML再手动粘进Markdown表格。虽然听起来要手工但比在一堆碎行里重建表格快十倍。我曾处理过一份全是统计表格的PDF大概有三十多张表用传统工具转出来全是碎行我硬是拼了一下午。后来换成Marker表格结构基本一次就对了再调调个别行的对齐就行。工具选对工作量降低一个量级。4.3 中文文档的换行特别“诡异”中文PDF大多是在Word里排的版行与行之间挤得紧转成PDF后物理行很短。更麻烦的是有些中文PDF在行尾会出现半角空格和全角字符混合的问题合并时如果不做字符清理会出现“字 字”这样奇怪的空格。我在脚本里加了字符清理把全角空格先转成普通空格把连续空格折叠成一个把“句号空格”的情况保留为段落句点。这样处理之后中文文档的观感才正常。另外中文里双引号、书名号跨行的情况也比较多合并之后要检查一下引号是否成对偶尔会有引号丢失的问题。4.4 公式和图片怎么办PDF里的公式有两种存在形式。如果源PDF是LaTeX生成的Marker和MinerU有时候能直接从字体信息里提取出公式源码转成LaTeX文本如果是扫描版或者Word排版的公式那大概率是图片或特殊字体这类只能走公式识别工具比如Mathpix。Mathpix效果好但收费本地也有开源的公式识别模型效果看模型质量。遇到这种情况我的建议是不要强求一次转换全部搞定。把公式批量导成图片用专门的公式识别工具处理再替换回Markdown的公式语法。听上去绕了一圈但至少不用手工敲公式而且准确率比你手敲还高。4.5 常见问题速查表症状原因解决方案段落全粘在一起合并脚本过于激进PDF本身无空行分隔改用版面分析工具或保留空行作为段落分隔每行末尾还有硬换行工具没做段落重建用后处理脚本合并物理行表格散落成独立行PDF表格本质是坐标解析引擎未识别表格单独使用表格抽取工具公式乱码公式是图片或特殊字体公式识别工具单独处理中英文混排出现怪空格合并逻辑未区分语言和字符宽度按中英文分别决定空格拼接方式代码块被拼成一行后处理脚本未跳过代码块增加代码块状态判断标题和正文连在一起PDF中标题与正文间距被识别为同一文本块手工调整标题下方空行或用高级版面分析工具5. 一套顺手到不想换的批处理流程工具和后处理脚本都跑通了剩下的问题就是重复劳动。我现在处理一批PDF基本是下面这套流程你可以直接抄走。第一步把要转换的PDF全部丢进一个目录按文件名批量处理for file in *.pdf; do marker_single $file --output_dir ./output/${file%.pdf} done第二步对输出目录里的所有Markdown文件统一跑后处理脚本for md in ./output/*/*.md; do python merge_lines.py $md ${md%.md}.fixed.md mv ${md%.md}.fixed.md $md done第三步抽查目录里三到五个文件重点看有没有表格乱掉、段落粘连、代码被拼行。抽查过关这批转换就算交付了。最后再多说一句没有100%完美的PDF转Markdown工具任何工具都会在某个偏门的排版上翻车。但只要你把工具选对、后处理脚本写好、批量流程跑顺手工删换行这件事基本可以从你的人生里消失。我个人的体会是这套流程最大的价值不是省了那几分钟而是让你在处理几十上百页的长文档时心里有底你知道硬换行有脚本兜底表格有工具识别公式有单独方案每一类问题都有对应的解法。这种确定性比什么神仙工具都重要。