为什么输出格式选型值得提前想清楚
PDF 解析完成后，"拿到文件"不等于"能用"。输出格式选错带来的返工成本，往往超过解析本身。一个选型失误可能导致整个数据管线的返工，而根源通常不是工具的精度------是格式与下游需求之间的错配。
一个反面案例能说明问题。某团队用 MinerU 将一批财报 PDF 解析为 Markdown，然后编写正则表达式从文本中提取表格数据。他们很快发现：Markdown 表格丢失了合并单元格信息，行间公式被渲染为纯文本符号，图片的坐标信息完全不可用。后续不得不重新用 JSON 模式跑一遍整个数据集------多花了两周的工程时间。如果项目开始时多花半小时评估"下游要什么"，这半个月的返工完全可以避免。
这个教训指向一个更通用的判断框架：下游消费方是人类读者还是机器程序？是否需要保留精确坐标？是否需要二次编辑？ 答案不同，对应的输出格式就不同。MinerU 提供了五种输出格式------Markdown、JSON、HTML、LaTeX、DOCX------各自的适用边界差异显著。了解它们的特性与局限，才能在项目开始时做出正确的选型决策，而不是在数据处理到一半时发现路径不可行。
MinerU 五类输出格式全景
MinerU 的五类输出格式可以按照"人类可读"和"机器可读"两个维度排列。
Markdown 是默认输出格式，也是开源部署版本的基础输出。它的标题层级（#/##）和段落结构直接对应文档的语义骨架，表格使用 GFM 语法呈现，公式以 LaTeX 行内/行间格式嵌入。Markdown 的核心理念是"兼顾可读性与可编辑性"------你可以在 Obsidian、Typora 或任何代码编辑器中直接打开和修改。局限在于：不保留精确的版面坐标，不表达合并单元格，对复杂格式（如多栏布局）的表达依赖语义推断。
JSON 是面向机器的结构化输出，包含完整的版面元数据。开源部署版本默认生成 middle.json 和 content_list.json 两个文件。middle.json 保留了从版面分析到段落合并的完整中间结果，包含 bbox 坐标、块类型、阅读顺序、行/片段级分解。content_list.json 则是按阅读顺序平铺的简化版，适合直接消费。JSON 不适合人工阅读，但这是设计意图------它服务的对象是下游程序。
HTML 输出将解析结果包装为完整的网页文档，保留字体、字号、颜色等 CSS 样式信息，图片以 <img> 标签嵌入。表格以 <table> 结构呈现，可以表达合并单元格（colspan/rowspan）和多层表头。HTML 与 Markdown 存在包含关系------Markdown 本身是 HTML 的子集语法，但 HTML 能表达更丰富的样式信息。
LaTeX 输出专为学术排版设计。解析结果以 .tex 文件形式输出，公式以原生 LaTeX 语法呈现，可直接交由 pdflatex/xelatex 编译。表格支持 tabular 等 LaTeX 原生环境。图片以 \includegraphics 引用。局限在于：LaTeX 本身是一种编程式排版语言，非学术场景的用户通常不需要它。
DOCX 输出保留 Word 文档的样式信息------字体、字号、段落间距、表格边框、列表缩进等。输出文件可直接在 Microsoft Word 或 WPS 中打开编辑。适合需要二次加工的场景。
五类输出格式特性对比
| 维度 | Markdown | JSON | HTML | LaTeX | DOCX |
|---|---|---|---|---|---|
| 人类阅读友好度 | ⭐⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| 机器处理友好度 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐ |
| 公式支持 | LaTeX 嵌入 | LaTeX 文本 | 图片/MathJax | 原生 LaTeX | 图片/OMML |
| 样式保留 | 基础 | 无 | 完整 CSS | 排版控制 | 完整 |
| 文件体积 | 小 | 中 | 中 | 小 | 中 |
| 开源版支持 | ✅ 默认 | ✅ 默认 | ❌ 云端独有 | ❌ 云端独有 | ❌ 云端独有 |
上表揭示了一个关键约束：LaTeX、DOCX、HTML 为云端服务（Open API / SDK）独有输出格式，开源部署版本不支持。 如果通过本地部署的 MinerU（magic-pdf CLI）跑解析，你能拿到的是 Markdown 和 JSON。如果需要其余三种格式，需要使用 MinerU Open API 或 SDK（Python/JS/TS）。这一点在选型时容易被忽略------等到部署环境锁定才发现格式不可用，后续调整成本较高。
场景一：RAG / 知识库 → Markdown
RAG 系统的第一个环节是将文档拆分为语义完整的块（chunk），这个环节的质量直接影响后续检索和生成的精度。MinerU 输出的 Markdown 在这方面有两个结构化优势。
标题层级天然适合分块。 Markdown 的 #/##/### 对应文档的章节结构，下游的 RecursiveCharacterTextSplitter（LangChain）或 SentenceSplitter（LlamaIndex）可以基于标题边界做"按语义段落切分"，而不是机械地按字符数截断。基于标题的分块策略比固定长度分块在检索命中率上高出 10-20 个百分点------原因很简单：没有哪个 RAG 系统希望把"第 3.1 节结论"和"第 3.2 节方法"切成同一个 chunk。
段落边界清晰减少粘连问题。 MinerU 输出的 Markdown 保留了原始文档的段落边界（空行分隔），表格、代码块、引用块都有明确的起止标记。这避免了其他解析工具常见的"两段文本粘成一个块"问题，后者会导致 chunk 边界落在语义断裂处，一个 chunk 里包含两个不相关的段落，检索时相互干扰。
与 RAG 框架的衔接建议
LangChain 用户可以直接使用 langchain-mineru 包（pip install langchain-mineru），通过 MinerULoader 加载 PDF 后得到 Markdown 格式的 Document 对象，然后接入标准的 TextSplitter 工作流：
python
from langchain_mineru import MinerULoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
loader = MinerULoader(source="paper.pdf", mode="flash")
docs = loader.load()
splitter = RecursiveCharacterTextSplitter(
chunk_size=1200, chunk_overlap=200,
separators=["\n## ", "\n### ", "\n", "。", " "]
)
chunks = splitter.split_documents(docs)LlamaIndex 用户通过 llama-index-readers-mineru 的 MinerUReader 加载，输出同样是 Markdown。两个加载器都支持 flash（零成本快速模式）和 precision（精准模式）两种解析等级。precision 模式需要 API Token，但公式和表格的识别精度更高------如果你的知识库包含大量学术文献，建议优先使用该模式。
需要注意的一点：langchain-mineru 和 llama-index-readers-mineru 目前只返回 Markdown 格式的输出。如果需要 JSON 或 DOCX，需要直接调用 MinerU SDK。但对于纯文本检索场景，Markdown 已经足够------额外的版面元数据可以通过 Document.metadata 承载，你可以在加载器初始化时通过 extra_info 参数注入自定义元数据（项目标签、来源批次等），这些字段会一并写入向量数据库，方便后续按来源过滤检索结果。
场景二：数据挖掘 / 结构化分析 → JSON
当消费端不是人类读者而是程序时，Markdown 的"可读性"反而成了噪音。JSON 输出的价值在于：它保留了文档的结构化骨架------每个元素的位置、类型、层级关系、阅读顺序------这些是 Markdown 中被隐式丢弃的信息。如果你需要从论文中批量提取公式图片、从财报中抓取表格结构、或者按阅读顺序重建文档内容，JSON 是更直接的路径。
关键字段解析
content_list.json 是数据挖掘场景最常用的文件。每个元素包含以下关键字段：
bbox：边界框坐标[x0, y0, x1, y1]，映射到 0-1000 的归一化范围。有了 bbox，你可以精确定位"这一页第 3 个表格在什么位置"，或者"某张图片距离页面上边界多远"。这是版面还原和精确截取场景的基础------程序依赖坐标而非视觉判断来定位内容。（注意：content_list.json使用 0-1000 归一化坐标，而middle.json保留原始像素坐标；不同文件的坐标基准不同，使用时需要留意。）type：内容类型------text、table、image、chart、equation、list、code等。按类型过滤是实现定向提取的基础，例如"只保留所有公式图片"。text_level：文本层级标识------无或0为正文，1/2/3对应一/二/三级标题。这个字段允许程序自动构建文档的层级树，然后按标题范围聚合下属正文。page_idx：页码（从 0 开始），支持跨页内容的聚合分析，也方便与原始 PDF 做对照。reading_order（在middle.json中通过index字段表达）：阅读顺序索引，确保内容的排列顺序与人类的阅读习惯一致------先左栏后右栏，先正文后脚注。
middle.json 提供了更细粒度的层级结构：一级块（table/image/chart）→ 二级块（body/caption/footnote）→ 行（line）→ 片段（span）。每个 span 都有独立的 bbox、type 和 content，精度达到单个文本片段级别。如果你的场景需要"根据坐标截取特定区域的内容"，middle.json 是必要的选择。
此外，MinerU 的 model.json 中还包含 cls_id 字段------模型推理输出的类别编码，通过 cls_id → label 映射可获知每个检测区域的语义类别（如文本、表格、图片等）。该字段在按类别做后处理过滤时有用，但注意 model.json 存在于完整管线输出中，content_list.json 已将其展开为可读的 type 字段。
从 JSON 提取表格数据的代码思路
假设你需要从一批学术论文的 JSON 输出中提取所有表格及其标题，思路如下：
python
import json
with open("output/content_list.json") as f:
items = json.load(f)
tables = []
for item in items:
if item["type"] == "table":
tables.append({
"page": item["page_idx"],
"caption": "".join(item.get("table_caption", [])),
"body_html": item.get("table_body", ""),
"bbox": item["bbox"],
"footnote": "".join(item.get("table_footnote", [])),
})这种提取方式与 Markdown 方案的差异在于：JSON 方案保留了表格的 HTML 结构表达（含合并单元格），而 Markdown 方案会将表格简化为 GFM 语法。对于后续要做数据分析、存入数据库或做结构化比对的场景，JSON 路径的 ROI 明显更高。如果你的下游需要的是纯文本表格内容而非结构，Markdown 反而更轻量。
场景三：学术论文 / 公式排版 → LaTeX
学术出版的"最后一公里"常常是 LaTeX 编译。如果解析工具输出的公式无法直接编译，那它的价值就止步于"展示"，无法进入正式的出版流水线。
公式语义保真度
MinerU 的 UniMERNet 模型在公式识别上做了专项优化。根据 OmniDocBench v1.6 的基准评测，MinerU 2.5-Pro 的公式语义保真度达到 94.7%。这一指标的含义是：输出的 LaTeX 代码能够准确还原原公式的数学结构------上下标、分式、根号、积分限、矩阵嵌套------而非仅停留在"看起来像"的层面。
对比来看，同类工具在这一指标上的数据约为 89.1%，差距在复杂嵌套结构（多重分数、矩阵内套矩阵）上尤为明显。在物理、数学论文中，单个括号的缺失就可能改变整个公式的语义，因此 5.6 个百分点的差距在实际生产环境中具有可感知的影响。
编译依赖与限制
使用 MinerU 输出的 LaTeX 文件，有几个前提需要确认：
- 需要本地安装 TeX 发行版（TeX Live / MiKTeX / MacTeX），约 2-5GB 空间。最小化安装
texlive-base约 300MB，但缺少常见宏包时编译可能报错。如果你的文档使用了特殊宏包（如amsmath、hyperref），建议安装完整版。 - MinerU 的 LaTeX 输出依赖云端 API（开源版不支持）。你需要通过 MinerU Open API 或 SDK 的
precision模式，并在请求参数中指定output_format="latex"。这意味着你的网络环境和 API 配额会影响可用性。 - 对极端复杂版面（如多栏内嵌入超长公式、化学结构式），输出的 LaTeX 可能需少量手动调整------94.7% 的语义保真度意味着约 5% 的情况需要人工介入。常见的手动修正集中在括号匹配、多行对齐结构（
\begin{aligned}）和特殊符号映射上。对于出版级质量控制，建议在编译后做一轮全文校对。
场景四：文档编辑 / 办公协作 → DOCX
办公协作场景的最高优先级是"可以改"。Markdown 虽好，但非技术团队的同事通常不会直接编辑 .md 文件。合同、报告、标书这类文档的生命周期包含多次审阅和修订------法务加条款、财务改数据、领导批注------这些环节都要求在 Word 原生环境中完成。DOCX 是这类协作场景中唯一能直接在 Word 中完成全流程编辑的格式。
样式保留能力边界
MinerU 输出的 DOCX 保留了以下样式信息：字体名称与大小、段落对齐方式（左/中/右/两端）、列表编号与缩进层级、表格边框与单元格合并（colspan/rowspan）、图片嵌入与浮动位置。这意味着一份合同或报告解析后，在 Word 中打开，外观与原 PDF 基本一致，可直接审阅和修改。这对于需要快速将 PDF 版的反馈意见转为可编辑 Word 文档的法务和商务团队尤其有价值。
但也有一些已知限制。表格的极端合并单元格（如跨 5 行以上、行内嵌套表格）可能降级为简单表格。字体映射方面，如果原 PDF 使用了系统未安装的字体，会回退为默认字体（Word 中通常是等线或宋体），这可能导致换行位置与原 PDF 不一致。DOCX 输出不保留 PDF 中的超链接和交互式表单字段------如果需要保留链接，需要手动添加或通过脚本补全。
与纯 Markdown 转 Word 的差异
有人可能会问：先解析成 Markdown，再用 Pandoc 转 DOCX，是不是也能达到类似效果？
两种路径的差异主要在表格和公式上。Markdown → Pandoc → DOCX 这条路径中，表格被降级为 GFM 语法（无合并单元格），公式被转为图片或 OMML（取决于转换器实现）。MinerU 的原生 DOCX 输出则保留表格的 HTML 结构（含合并单元格），公式以 OMML（Office Math Markup Language）格式嵌入------OMML 是 Word 的原生公式格式，支持在 Word 中继续编辑公式，而不是"冻结"为图片。
场景五：网页展示 / 在线预览 → HTML
需要在浏览器中直接展示 PDF 解析结果时，HTML 是最自然的选择。MinerU 的 HTML 输出将原始文档重建为一个独立的网页，图片内嵌（通过 base64 或独立 URL），样式独立于外部资源。
HTML 与 Markdown 的包含关系
技术上，Markdown 是 HTML 的子集------任何有效的 Markdown 都可以转换为 HTML，反之则不然。MinerU 的 HTML 输出比 Markdown 多保留了两类信息：
样式细节。 字体族、字号、颜色、背景色、段落间距------这些在 Markdown 中无法表达，但在 HTML 中有对应的 CSS 属性。对于品牌手册、企业年报等对视觉一致性有要求的场景，HTML 是唯一能保留原貌的文本格式。
表格结构。 MinerU HTML 输出中的表格以 <table> + <td colspan> + <td rowspan> 呈现，完整保留了合并单元格信息。Markdown 的 GFM 表格语法不支持合并单元格，遇到复杂表头会降级为多个独立单元格或纯文本。
网页嵌入的注意事项
将 MinerU 的 HTML 输出嵌入网页应用时，有几个实践建议：
- 如果后续有二次编辑需求，HTML 内容可以先用
DOMParser清洗，移除冗余的 inline style，替换为统一 CSS class。 - 表格内容可配合
IntersectionObserver做按需加载------对于 50 页以上的长篇文档，一次性渲染全部 HTML 表格可能影响首屏性能。 - 图片建议从 base64 转为独立文件托管，尤其是批量展示场景------base64 内嵌会使 HTML 体积膨胀数倍。
选型速查表与决策流程
把前面的五类场景整合为一个决策框架，核心逻辑可以压缩成两个问题：
问题一：下游消费方是人类还是机器？
- 人类 → 继续判断是否需要编辑
- 机器 → JSON（数据挖掘/结构化分析）
问题二：如果需要人类阅读，是否要求可编辑？
- 需要编辑 + 办公协作环境 → DOCX
- 需要编辑 + 学术排版环境 → LaTeX
- 不需要编辑，仅预览展示 → HTML
- 需要兼顾可读与可编辑，且是 RAG/知识库 → Markdown
用表格呈现更直观：
| 下游场景 | 推荐格式 | 核心考量 |
|---|---|---|
| RAG / 知识库检索 | Markdown | 标题层级天然分块，LangChain/LlamaIndex 原生集成 |
| 数据挖掘 / 结构化分析 | JSON | 含 bbox、阅读顺序、块类型，可直接提取表格/图片/公式 |
| 学术出版 / 公式排版 | LaTeX（云端） | 94.7% 公式语义保真度，直接编译 |
| 办公协作 / 文档编辑 | DOCX（云端） | 保留字体、段落、表格样式，Word/WPS 可直接编辑 |
| 网页展示 / 在线预览 | HTML（云端） | 完整 CSS 样式，表格含合并单元格 |
如果团队同时用开源部署和云端 API，记住一个简单的等价关系：开源本地跑 = Markdown + JSON；云端 API 调用 = Markdown + JSON + LaTeX + DOCX + HTML。 选型前先确认你的部署方式支持哪些格式------这不是功能取舍，是能力边界。