网页和 api 提取的 markdown 内容不一致

[ollbao]

同一个 pdf文件，用你们官网提取的 markdown 内容和 api 提取的 markdown 内容为什么不一致呢？
官网的：

api提取的：

[dosubot[bot]]

Hi @ollbao! I'm Dosu and I’m helping the MinerU team.

造成官网和 API 提取同一 PDF 得到的 markdown 内容不一致，主要原因是两者默认的“后端类型”（如 pipeline、VLM、hybrid）、模型版本和参数设置（如是否强制 OCR、语言、表格/公式识别开关）可能不同。即使底层核心解析引擎一致，不同的后端/参数会导致内容结构、识别质量和细节有明显差异，比如部分 API 客户端或插件（如 Dify 旧版）无法选择官网默认的 VLM 后端，只能用 pipeline 或 PaddleOCR，识别效果会低于官网默认的 VLM 模型相关说明。

要保证官网和 API 提取结果一致，需确保：

• 后端类型（如 hybrid-auto-engine、vlm-auto-engine）一致
• 模型版本一致
• 参数设置（OCR、语言、表格/公式开关等）一致

建议操作步骤：

1. 明确官网和 API 各自用的后端类型和参数（可在 Gradio UI 或 API 请求参数中查看/设置）。
2. API 调用时手动指定与官网一致的 backend、语言、OCR、表格/公式开关等参数。
3. 如需排查差异，可比对中间产物 middle.json、content_list.json，或开启 debug 日志，核查 mineru.json 配置和模型 hash。
4. 遇到复杂表格、长公式、页眉页脚等特殊内容，不同后端/参数下处理方式也可能不同，部分内容会被自动过滤或识别失败详细分析。
5. 建议升级到 MinerU 最新版本，关注近期 PR（如 Dev #4231、Release 2.7.0 #4272）带来的后端和识别能力变化PR 说明。

如已确保参数完全一致仍有差异，可提供 sample 文件、配置、模型 hash 及 debug 输出，便于进一步定位问题。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ollbao]

还有为什么通过 api 下载的解析文件里没什么没有block_list.json 这个文件呢，有没有大佬解答下呢？很急！！

[dosubot[bot]]

block_list.json 不是 MinerU 的标准输出文件，无论是 API、命令行还是网页端都不会默认生成这个文件。所有结构化内容块（包括列表、表格、图片、标题、正文等）都在 middle.json 和 content_list.json 里，list 类型内容会以 type: "list" 的结构出现在这些标准文件中。你可以直接用 middle.json 或 content_list.json 进行二次开发或数据处理，无需依赖 block_list.json。如果你的流程或脚本依赖 block_list.json，建议适配为读取标准输出文件即可。详见官方输出文件说明。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[ollbao]

middle.json 没有这个文件。 content_list.json 的内容不全缺少页眉等内容

[dosubot[bot]]

middle.json 和 content_list.json 的生成与内容完整性，主要受 API 参数、后端类型（pipeline/vlm/hybrid）、模型版本和解析逻辑影响：

1. middle.json 不存在，通常是因为 API 请求时没有设置 return_middle_json=True，默认不会输出。你需要在 API 请求参数中明确加上 return_middle_json=True 才会生成 middle.json 文件 参考。

2. content_list.json 缺少页眉（header）等内容，常见原因有：

   • 后端类型为 pipeline 时，页眉页脚等内容会被归为 discarded_blocks，只在 middle.json 里出现，content_list.json 里类型为 discarded 或直接被过滤 参考。
   • 后端类型为 VLM（如 hybrid-auto-engine、vlm-auto-engine）时，header/footer 会以 type: "header"/"footer" 直接出现在 content_list.json 里 参考。
   • 如果 content_list.json 依然缺少 header，可能是模型没有识别出 header 块，或者参数设置未输出 discarded_blocks。

3. 解决方法：

   • API 请求时加上 return_middle_json=True 和 return_content_list=True，确保输出这两个文件。
   • 尽量选择 VLM 或 hybrid 后端（如 backend=vlm-auto-engine 或 hybrid-auto-engine），这样 content_list.json 会包含 header/footer。
   • 如需保留所有内容（包括页眉页脚），可尝试强制 OCR 模式（parse_method=ocr），此模式不会自动过滤 header/footer。
   • 如 content_list.json 依然缺失 header，可在 middle.json 的 discarded_blocks 字段中查找 header 内容，必要时手动提取。

4. 建议升级 MinerU 至 2.1.1 及以上版本，近期版本对 header/footer 检测和内容完整性有明显优化 参考。

如有具体 API 请求参数、后端类型或 middle.json 内容，可贴出来进一步定位问题。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ollbao]

model.json文件里的内容比较全，但是为什么 image 类型没有图片地址。
3f5d701f-d09e-4a80-b782-bd11c8e947f1_model.json

[dosubot[bot]]

model.json 只保存模型的原始推理结构（如内容类型、坐标、置信度等），不会包含图片的文件路径或 URL，这是设计使然，无法通过参数配置让 model.json 输出图片地址。图片的实际裁剪和 img_path 路径是在 middle.json 和 content_list.json 生成阶段，由后处理代码（如 cut_image_and_table）补充的，最终 img_path 字段只会出现在 content_list.json 或 middle.json 里，且图片实际保存在 markdown 输出目录下的 images 子目录中（img_path 为相对路径）官方说明。

如需获取图片地址，请查找 content_list.json 或 middle.json 里的 img_path 字段。如果发现 img_path 为空，常见原因有：图片 bbox 无效（坐标错误）、缺少字体包（如 Linux 下未安装 fonts-noto-core/fonts-noto-cjk）、模型或环境不一致、或遇到复杂版式/模型盲区等。建议升级 MinerU 至 2.1.1+，并检查依赖和 debug 日志详细排查建议。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.