文件格式转换实战：为什么很多系统要走“文件 → PDF → Markdown”，到底应该怎么做？

在大模型应用、知识库、RAG、文档解析、智能问答系统里经常会遇到一个问题用户上传 Word、PPT、Excel、图片、PDF系统最后却要把它们统一转成 Markdown。更常见的是很多工程不是直接Word / PPT / Excel → Markdown而是先走一层原始文件 → PDF → Markdown这不是多此一举而是为了让文档解析更稳定、更统一、更适合后续给大模型使用。下面就详细说清楚文件格式转换“文件 → PDF → Markdown”到底应该怎么做。一、先说结论文件转 Markdown本质不是“格式转换”而是“内容结构还原”很多人一听“文件格式转换”会以为只是把 .docx 变成 .md就像改个文件后缀一样。其实不是。真正难的是把一个复杂文件里的内容、层级、表格、图片、标题、页眉页脚、段落顺序、阅读顺序尽可能还原成大模型能理解的文本结构。比如一个 Word 文档里可能有一、标题二、正文段落三、表格四、图片五、脚注六、页眉页脚七、多栏排版八、批注九、目录十、复杂编号如果直接粗暴提取很可能出现正文顺序乱了表格散了标题层级丢了图片说明没了页眉页脚混进正文甚至一页内容被拆得七零八落。所以工程上通常要做三件事第一步统一入口格式。不同文件先转换成一个相对稳定的中间格式比如 PDF。第二步从 PDF 中解析内容。包括文本、表格、图片、坐标、版面结构。第三步生成适合大模型使用的 Markdown。Markdown 的好处是结构清晰、文本干净、方便切分、方便进入向量库和 RAG 流程。二、为什么要走“文件 → PDF → Markdown”1、PDF 是一种“版式固定”的中间格式Word、PPT、Excel 这类文件本质上是可编辑文档。不同软件、不同字体、不同系统打开显示效果可能不一样。比如同一个 Word 文件在 Windows Office 里看是一页在 WPS 里可能换行位置不同在 Linux 服务端转换时又可能字体丢失。但是 PDF 的特点是版式相对固定。也就是说PDF 更像是“最终展示效果”。标题在哪、表格在哪、图片在哪、每段文字的位置是什么都比较稳定。这就是为什么很多系统喜欢先转 PDF。2、统一成 PDF 后后续处理链路更简单如果不转 PDF你就要分别处理Word 解析一套逻辑PPT 解析一套逻辑Excel 解析一套逻辑图片 OCR 一套逻辑HTML 解析一套逻辑PDF 解析一套逻辑。这样系统会非常复杂。如果先统一成 PDF后面就可以变成Word → PDFPPT → PDFExcel → PDF图片 → PDFHTML → PDFPDF → Markdown后半段只需要重点打磨PDF → Markdown工程复杂度会降低很多。3、PDF 更适合做版面分析大模型知识库最怕什么不是没内容而是内容顺序乱。比如一份两栏论文如果直接提取文字很可能提取成左栏第一行、右栏第一行、左栏第二行、右栏第二行……这样大模型读起来就是乱的。PDF 里通常可以拿到文字坐标、字体大小、块位置、图片位置。像 PyMuPDF 这类库可以做 PDF 文本提取、版面分析、表格提取等操作。PyMuPDF 官方也说明它可用于 PDF 的数据提取、分析、转换和操作。所以 PDF 不是万能但它很适合做统一解析入口。三、为什么最终要转成 Markdown1、Markdown 结构清晰适合大模型阅读Markdown 很简单比如# 一级标题 ## 二级标题 这是一段正文。 | 字段 | 含义 | |---|---| | name | 用户名 | | age | 年龄 |它不像 HTML 那样标签很多也不像 PDF 那样强调页面坐标。Markdown 的优势是结构清楚文本干净体积小方便切分方便存入向量库方便给大模型作为上下文。所以在 RAG、知识库、Agent 文档理解场景里Markdown 是非常常见的中间文本格式。2、Markdown 更适合做 Chunk 切分知识库通常不会把整篇文档一次性塞给大模型而是要切成一段一段。比如按标题切按段落切按页码切按表格切按语义切。如果是 Markdown就可以根据######表格代码块列表这些结构做更合理的切分。比如## 3.2 费用结算规则 这里是费用规则正文……这一段可以单独作为一个知识块。如果只是纯文本就很难知道哪个段落属于哪个标题。3、Markdown 更容易保留“内容层级”大模型不只是看文字还要理解上下文关系。比如# 合同条款 ## 付款方式 ## 违约责任 ## 保密条款这种层级结构对大模型非常友好。它能知道“违约责任”是合同条款下的一个章节而不是一段孤立文本。四、整体架构应该怎么设计一个成熟的“文件 → PDF → Markdown”系统通常可以分成 8 层。五、第一层文件上传与类型识别1、先识别文件类型用户可能上传.doc.docx.ppt.pptx.xls.xlsx.pdf.jpg.png.txt.html.csv不要只依赖文件后缀。因为有些文件可能被用户改过后缀比如一个 PDF 被改成 .docx。更稳妥的做法是根据文件后缀初步判断根据 MIME Type 再判断根据文件头魔数再确认必要时尝试用解析器打开验证。2、上传后先做安全检查文件转换系统很容易被攻击因为它要打开用户上传的文件。所以需要做文件大小限制文件类型白名单病毒扫描压缩包炸弹检查文件名清洗路径穿越防护临时目录隔离转换容器隔离。比如不要让用户上传一个超大的 2GB Word 文件也不要让用户上传恶意宏文档直接在服务端执行。3、文件需要生成唯一任务 ID一次转换不要只靠文件名。应该生成taskIdfileIdrequestIdtraceId后续所有日志都围绕这些 ID 串起来。这样转换失败、解析失败、Markdown 质量异常时才方便排查。六、第二层原始文件预处理1、Word 文档预处理Word 文档最常见的问题是字体缺失目录字段异常批注影响正文页眉页脚干扰隐藏文字复杂表格嵌入图片公式文本框。处理建议优先保留正文、标题、表格、图片批注可以根据业务决定是否保留页眉页脚一般默认弱化目录可以保留但不要当作正文重点隐藏文字通常不进入知识库文本框内容要尽量提取。2、PPT 文档预处理PPT 比 Word 更难因为 PPT 是强视觉文档。它有标题副标题图形文本框流程图图片备注动画母版图表。PPT 转 Markdown 时不能只提取文字否则很多信息会丢。比较实用的方式是每页 PPT 转成一页 PDF提取页面里的文本块保留页码图片单独保存图表可转图片并生成说明备注区可以作为补充内容。3、Excel 文档预处理Excel 最麻烦的地方是它不是天然的文章结构而是表格结构。Excel 可能有多个 Sheet合并单元格公式隐藏行列筛选图表透视表宽表多层表头。Excel 转 PDF 有个问题如果页面设置不好可能会把表格切得很碎。所以 Excel 不一定所有场景都适合先转 PDF。更好的策略是如果是简单报表可以转 PDF 后再转 Markdown如果是结构化数据建议直接解析 Excel 生成 Markdown 表格如果是超大表格建议转 CSV 或数据库表结构不要强行塞成 Markdown。4、图片文件预处理图片类文档需要 OCR。比如扫描件、合同照片、截图。图片转 PDF 后再做 OCR 的好处是统一流程但要注意图片清晰度方向是否旋转是否有倾斜是否有阴影是否有水印是否是多图拼接是否有表格线。常见处理包括图片去噪自动旋转倾斜校正增强对比度裁剪边框OCR 识别版面区域检测。七、第三层文件转 PDF1、Office 文件转 PDF工程上常见方案是使用 LibreOffice 的 headless 模式也就是无界面转换。LibreOffice 支持在命令行中将 Office 文档转换为 PDF常见命令形式类似libreoffice --headless --convert-to pdf input.docx --outdir output_dirLibreOffice 可以处理它能打开读取的输入格式并转换成它能写出的格式包括 Office 文档转 PDF不过转换效果并不是所有文件都完美。实际工程中要注意服务端必须安装字体中文字体要完整不同版本 LibreOffice 转换效果可能不同转换过程要设置超时失败要能重试要防止多个任务抢同一个临时目录最好放在容器中隔离运行。2、HTML 转 PDFHTML 转 PDF 常见工具有Chromium headlessPlaywrightwkhtmltopdf。如果 HTML 中有复杂 CSS建议用 Chromium 系方案因为现代 CSS 支持更好。处理重点等待页面渲染完成处理远程图片处理字体处理分页处理懒加载处理动态内容禁用不安全脚本。3、图片转 PDF图片转 PDF 相对简单。可以把每张图片作为 PDF 的一页。但要注意保持图片比例不要过度压缩控制 DPI多张图片按顺序合并保留原始图片路径方便 Markdown 引用。4、PDF 文件直接进入下一步如果用户本来上传的就是 PDF就不需要再转 PDF。但仍然要做是否加密是否损坏是否扫描版是否有文本层是否页数过多是否包含图片和表格。八、第四层PDF 解析PDF 转 Markdown 是整个流程的核心。这一步不是简单“复制文字”而是要完成文本提取阅读顺序还原标题识别段落合并表格识别图片提取页码保留脚注处理多栏处理公式处理OCR 兜底。1、文本提取普通 PDF 里通常有文本层可以直接提取文字。但直接提取经常会有问题换行乱空格乱段落断裂左右栏混在一起页眉页脚混入正文标题和正文无法区分。所以要结合文本块坐标字体大小字体粗细行间距段落间距页面位置。PyMuPDF 提供了 PDF 文本提取、自然阅读顺序提取、表格提取、Markdown 提取等相关能力说明。2、阅读顺序还原这是最容易被忽略的一步。人看 PDF 时会自动知道先读左边再读右边先读标题再读正文。但程序不一定知道。所以需要根据版面做排序先按页面再按区域再按从上到下再按从左到右多栏文档要先识别栏表格区域不要按普通文本乱排。如果阅读顺序错了后面的 Markdown 再漂亮也没用。3、标题识别标题通常有几个特征字体更大加粗居中前面有编号上下间距更大出现在页面靠上位置。比如一、系统架构设计 1.1 文件解析流程 2.3 表格识别策略可以转换成# 一、系统架构设计 ## 1.1 文件解析流程 ## 2.3 表格识别策略标题识别准确后Markdown 才有层级。4、段落合并PDF 里的文本经常是一行一行存的。比如原文是文件格式转换系统需要先完成文件类型识别 然后将不同格式统一转换为 PDF 最后再解析为 Markdown。直接提取可能变成三行。但在 Markdown 中它应该是一段文件格式转换系统需要先完成文件类型识别然后将不同格式统一转换为 PDF最后再解析为 Markdown。所以要做段落合并。判断依据包括行尾是否有句号下一行是否缩进两行之间距离是否很近字体是否一致是否属于同一个文本块是否遇到标题、列表、表格。5、表格识别表格是 PDF 转 Markdown 最难的部分之一。表格可能有线框也可能无线框。有线表格可以根据线条和单元格边界识别。无线表格要根据文字坐标对齐关系识别。最终可以转成| 字段 | 类型 | 说明 | |---|---|---| | user_id | string | 用户ID | | amount | decimal | 金额 | | create_time | datetime | 创建时间 |但复杂表格不要强行转成普通 Markdown 表格。比如多级表头合并单元格跨页表格嵌套表格超宽表格。这些可以选择保留为 HTML table转成图片并附 OCR 文本拆成多个小表输出为 CSV 附件在 Markdown 中标注“该表格结构复杂”。6、图片提取PDF 里的图片不能简单丢掉。很多技术文档、合同、方案里图片可能包含重要信息架构图流程图截图签章图表二维码扫描件。建议做法将图片单独保存在 Markdown 中插入图片引用给图片生成描述必要时对图片做 OCR保留图片所在页码。比如 图片说明该图展示了文件上传、PDF转换、Markdown解析、向量入库的整体流程。7、页眉页脚处理页眉页脚经常污染正文。比如每一页都有公司名称文档编号第 1 页 / 共 20 页保密声明日期。如果不处理最后切分出来的知识块里会到处都是重复噪声。处理方式统计每页相同位置的重复文本识别顶部和底部固定区域将高频重复内容移除页码可以单独保留为元数据。8、水印处理很多 PDF 有水印比如内部资料保密草稿公司名称斜着铺满页面。水印如果被提取进正文会严重影响 Markdown 质量。处理方式根据透明度识别根据旋转角度识别根据重复频率识别根据位置和字体颜色识别必要时加入黑名单词。九、第五层OCR 兜底1、什么时候需要 OCR不是所有 PDF 都能直接提取文字。有些 PDF 其实是图片扫描件。判断方式每页提取文本为空文本字符很少页面主要由大图组成复制 PDF 内容复制不出来。这时就要 OCR。2、OCR 不是越多越好OCR 成本高速度慢而且会有识别错误。所以建议能直接提取文本就不要 OCR只有扫描页才 OCR图片区域可以局部 OCR表格图片可以用表格 OCROCR 结果要做清洗。3、OCR 后还要做版面恢复OCR 不是终点。OCR 只解决“图片变文字”但还要继续处理标题识别段落合并表格还原阅读顺序页码定位置信度过滤。否则 OCR 出来也是一堆乱文本。十、第六层Markdown 生成1、Markdown 不是越花哨越好用于大模型的 Markdown要追求干净稳定结构清晰少噪声可切分可追溯。不要为了好看加太多复杂格式。2、推荐 Markdown 输出格式可以采用这种结构!-- source: contract.pdf -- !-- page: 1 -- # 合同标题 ## 一、合作内容 这里是正文内容。 ## 二、付款方式 | 阶段 | 金额 | 时间 | |---|---:|---| | 首付款 | 10000 | 合同签署后 | | 尾款 | 20000 | 项目验收后 | 这样有几个好处可以追踪来源文件可以追踪页码可以保留表格可以保留图片方便后续切块。3、标题层级怎么生成一般可以按规则最大标题 → #二级标题 → ##三级标题 → ###小节标题 → ####但不要过度依赖字体大小。最好综合判断字体大小编号格式是否加粗上下间距是否独占一行是否出现在目录中是否符合标题关键词。4、列表怎么处理原始内容1. 支持 Word 文件上传 2. 支持 PDF 解析 3. 支持 Markdown 输出转换后1. 支持 Word 文件上传 2. 支持 PDF 解析 3. 支持 Markdown 输出无序列表- 文件上传 - PDF 转换 - Markdown 生成列表要尽量保留因为它对大模型理解步骤非常重要。5、代码块怎么处理技术文档中经常有代码。如果不处理代码缩进会丢。应该转成java public class FileConvertService { public String convert(String filePath) { return markdown; } }代码块要尽量保留语言类型比如 Java、Python、SQL、Shell。 --- ### 6、表格怎么处理 简单表格转 Markdown。 复杂表格可以转 HTML。 比如 html table tr th模块/th th能力/th /tr tr tdPDF解析/td td文本、表格、图片提取/td /tr /tableMarkdown 支持 HTML所以这是一个不错的兜底方案。十一、第七层内容清洗PDF 转 Markdown 后不能直接入库。还要做清洗。1、去掉乱码常见乱码包括不可见字符异常空格重复换行编码错误控制字符错误分隔符。处理方式统一编码为 UTF-8清理控制字符多个空格合并多个空行合并修复中文之间异常空格。2、去掉重复内容重复内容常见来源页眉页脚水印目录重复跨页表头免责声明。比如每页都有内部资料禁止外传就应该从正文中去掉或者只作为元数据保留一次。3、修复断句PDF 中常见问题本系统采用文件 转换服务进行处理应该修复为本系统采用文件转换服务进行处理。但不能盲目合并。比如列表、标题、表格不能乱合并。4、清洗无意义内容比如空页面只有页码的页面只有水印的页面重复目录乱码比例过高的段落。这些内容进入知识库后只会影响召回质量。十二、第八层质量评估文件转 Markdown一定要做质量评估。否则你不知道转换出来的内容到底能不能用。1、基础指标可以检查原文件页数PDF 页数Markdown 字数提取文本页数空白页比例乱码比例表格数量图片数量OCR 页数转换耗时失败原因。2、内容完整性检查比如Word 有 20 页PDF 只转出 3 页肯定有问题。PDF 有 100 页Markdown 只有 500 字也大概率有问题。可以做规则页数差异过大报警文本量过少报警连续空页报警乱码比例过高报警表格丢失报警图片数量异常报警。3、抽样人工校验对于重要文档最好做抽样校验。比如随机抽 3 页对比 PDF 页面和 Markdown 内容检查标题是否正确检查表格是否可读检查图片是否保留检查顺序是否正常。十三、推荐技术选型1、文件转 PDF常见选择LibreOffice headless适合 Office 转 PDFChromium / Playwright适合 HTML 转 PDF图片处理库适合图片转 PDF专业商业转换服务适合高保真场景。LibreOffice 的优势是开源、通用、部署成本低但复杂 Office 文档转换效果不一定百分百完美。2、PDF 解析常见选择PyMuPDFpdfplumberApache PDFBoxPopplerOCR 引擎版面分析模型。PyMuPDF 是高性能 PDF 处理库可用于 PDF 数据提取、分析、转换等场景。3、Markdown 转换工具如果是多格式转 Markdown可以关注 MarkItDown、Pandoc 等工具。Microsoft 开源的 MarkItDown 是一个轻量级 Python 工具目标是把多种文件转换成 Markdown服务于 LLM 和文本分析场景。Pandoc 则是非常经典的文档格式转换工具官方称它可以在多种标记格式之间转换。不过工程上不要完全依赖一个工具“一把梭”因为真实业务文档太复杂通常需要自己做规则增强和质量兜底。十四、完整处理流程示例可以设计成下面这样的流水线用户上传文件 ↓ 文件类型识别 ↓ 安全检查 ↓ 原始文件预处理 ↓ 转换成 PDF ↓ PDF 质量检查 ↓ 判断是否需要 OCR ↓ 文本 / 表格 / 图片 / 版面解析 ↓ 生成 Markdown ↓ Markdown 清洗 ↓ 质量评估 ↓ 切分 Chunk ↓ 向量化 ↓ 入库 ↓ 提供检索和问答十五、工程落地时的模块设计1、FileUploadService文件上传服务负责接收文件保存原始文件生成 fileId记录文件大小、类型、上传时间返回任务 ID。2、FileDetectService文件识别服务负责识别文件类型校验文件是否合法判断是否支持转换判断是否需要 OCR判断是否需要特殊处理。3、PdfConvertServicePDF 转换服务负责Word 转 PDFPPT 转 PDFExcel 转 PDFHTML 转 PDF图片转 PDF转换失败重试转换超时控制。4、PdfParseServicePDF 解析服务负责文本提取坐标分析段落重组标题识别表格识别图片提取页眉页脚去除水印过滤。5、OcrServiceOCR 服务负责扫描件识别图片文字识别表格图片识别低置信度标记OCR 结果清洗。6、MarkdownBuildServiceMarkdown 生成服务负责标题转 Markdown段落转 Markdown表格转 Markdown图片引用生成代码块保留页码元数据写入。7、QualityCheckService质量检测服务负责文本量检查页数检查乱码检查空页检查重复内容检查转换结果评分。8、ChunkService文档切分服务负责按标题切分按页码切分按段落切分表格单独切分控制每个 Chunk 长度保留来源信息。十六、Markdown 入库前最好保留哪些元数据每个 Markdown 或 Chunk 最好带上这些信息{ file_id: file_001, file_name: 产品方案.pdf, source_type: pdf, page_start: 3, page_end: 4, title_path: 系统设计 / 文件转换流程, chunk_index: 12, content_type: text, has_table: true, has_image: false, ocr_used: false }为什么要保留因为后续用户问答时可以告诉用户答案来自哪一页、哪个章节。这样可信度更高。十七、常见坑点1、只提取文本不管顺序这是最常见问题。最后结果看似有文字但顺序乱了大模型理解就会错。2、表格被拆散很多合同、财务报表、技术参数都在表格里。如果表格拆散关键信息就丢了。3、页眉页脚污染严重每页重复出现的内容如果不去掉会影响检索效果。比如用户搜索“保密”结果召回一堆页脚。4、OCR 结果不清洗OCR 会产生错字、空格、断行。不清洗直接入库后面问答质量会明显下降。5、Excel 强行转 PDFExcel 如果是大宽表转 PDF 后可能变得非常难解析。这种情况建议直接解析 Excel。6、转换服务没有隔离用户上传文件不可信。转换服务最好容器化限制 CPU、内存、磁盘、网络权限。7、没有失败兜底真实文件千奇百怪一定会失败。要有重试降级错误码人工处理入口失败日志用户提示。十八、文件 → PDF → Markdown 和直接文件 → Markdown怎么选不是所有场景都必须先转 PDF。可以按下面思路选择。1、适合先转 PDF 的场景Word 排版复杂PPT 页面视觉信息重要需要保留页面结构需要按页追溯文档格式很多希望统一解析链路需要接入 OCR对版式还原要求较高。2、适合直接转 Markdown 的场景纯文本标准 Markdown简单 HTML结构清晰的 DOCX结构化 ExcelCSVJSON代码文件。3、推荐采用混合策略最好的方案不是死板地全部转 PDF而是能直接结构化解析的直接解析版式复杂的先转 PDF扫描件走 OCR异常文件走兜底。比如DOCX 简单文档 → 直接转 Markdown 复杂排版 → 先转 PDF 再转 Markdown PPT 通常先转 PDF再按页解析 Excel 结构化表格 → 直接解析 报表展示型 → 可以转 PDF PDF 有文本层 → 直接解析 扫描件 → OCR 图片 OCR 后生成 Markdown十九、一个比较靠谱的落地方案可以这样设计1、第一阶段先跑通基础链路支持PDF → MarkdownDOCX → PDF → MarkdownPPTX → PDF → Markdown图片 → OCR → Markdown先不要一开始就追求所有格式都完美。2、第二阶段重点优化 PDF 解析质量优化标题识别段落合并表格识别图片提取阅读顺序页眉页脚清理。这一阶段对最终效果影响最大。3、第三阶段接入质量检测增加转换成功率解析成功率乱码率空页率OCR 占比表格识别率平均耗时失败原因分布。4、第四阶段接入大模型增强大模型可以辅助图片生成说明复杂表格转自然语言标题层级修正OCR 错字修正段落摘要文档结构归纳。但注意不要一上来什么都交给大模型。基础解析还是要靠规则和工具大模型适合做增强和兜底。二十、总结文件格式转换“文件 → PDF → Markdown”看起来只是转换格式实际上是一个完整的文档理解工程。它的核心不是把文件后缀换掉而是把复杂文档变成大模型能稳定理解的结构化文本。比较成熟的做法是原始文件先识别和安全检查复杂格式统一转 PDFPDF 里解析文本、表格、图片和版面扫描件走 OCR根据标题、段落、表格生成 Markdown清洗乱码、页眉页脚、水印和重复内容最后做质量评估再切分入库。真正落地时不要迷信单一工具。LibreOffice、PyMuPDF、Pandoc、MarkItDown 这些工具都很有价值但真实业务里还需要结合规则、OCR、质量检测、日志追踪和异常兜底。一句话总结文件 → PDF → Markdown 的本质是把“给人看的文档”转换成“给大模型读得懂、检索准、可追溯、可复用的知识结构”。