[Bug]: The mineru program fails to correctly recognize tables when present in PDF files. This might be a bug in the code.

[cuihangrui]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

0.26.4

RAGFlow image version

0.26.4

Other environment information

Actual behavior

I used curl to call mineru and the parsing result is as follows

However, the information in the table of the Ragflow knowledge base parsing result is garbled. Is it due to the following issue? In [mineru_parser.py] (/D:/ragflow-0.26.4/ragflow-0.26.4/deepdoc/parser/mineru_parser.py), RAGFlow calls MinerU/file_parse and then downloads the ZIP file, decompresses and extracts the contents. The problem is most likely in: The encoding of the markdown files in the ZIP is not UTF-8, causing garbled characters when reading The HTML tables in the markdown are wrongly stripped or escaped The subsequent chunk processing disrupts the content of the table

Expected behavior

No response

Steps to reproduce

Is it due to the following issue? In [mineru_parser.py] (/D:/ragflow-0.26.4/ragflow-0.26.4/deepdoc/parser/mineru_parser.py), RAGFlow calls MinerU/file_parse and then downloads the ZIP file, decompresses and extracts the contents. The problem is most likely in:
The encoding of the markdown files in the ZIP is not UTF-8, causing garbled characters when reading
The HTML tables in the markdown are wrongly stripped or escaped
The subsequent chunk processing disrupts the content of the table

Additional information

No response

[dosubot]

This issue was reported and fixed previously in issue #16334 [1]. The root cause was that _sanitize_section_text() in mineru_parser.py strips all HTML tags — including <table>, <tr>, <td> — flattening table content into plain text [2].

This was fixed in PR #16118 [3], which added a table_enable flag to _transfer_to_sections(). When table_enable=True (the default), the sanitization step is skipped and table HTML structure is preserved intact [4]:

if not table_enable:
    section = self._sanitize_section_text(section)

Since you're on v0.26.4, this fix should already be included. A few things to check:

1. Verify mineru_table_enable is not set to False in your parser configuration. It defaults to True [5], but if it was explicitly disabled, tables would still get stripped.

2. Encoding is not the issue — the code properly reads MinerU's JSON output with encoding="utf-8" [6], so garbled characters from encoding mismatches should not occur.

3. Compare your curl output vs. RAGFlow output more carefully — your curl call hits MinerU directly and returns raw content_list.json, while RAGFlow processes that output through its chunking pipeline. If the table content looks correct via curl but garbled in RAGFlow, the issue might be in how chunks are being displayed or stored rather than in the MinerU parser itself.

Could you share the actual garbled text from the RAGFlow chunk (the content_with_weight value) so we can determine whether the HTML is being stripped or if there's a different issue at play?

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[cuihangrui]

{
"code": 0,
"data": {
"chunks": [
{
"available": true,
"content": "\n北京西岐网络科技有限公司关于“有效管理的5大兵法”全员学习成果排名的通知\n各部门、各分公司：\n公司于2026年1月5日起开展的“有效管理的5大兵法”全员推广学习计划，目前已完成第一阶段十二指令的学习，根据专项工作安排，现将学习成果通知如下：\n一、学习成果评定\n本次学习成果评定共分为三个等级，对排名靠前的部门予以通报表扬，具体如下：\n

	WEY	B1
tA	AAJEERI	EPZ$
-$a	#F	RBKllBA
	5X

\n二、评定结果依据\n1.网盘存储的学习过程材料。\n请全体员工高度重视本次学习工作，主动参与、认真实践，切实将 “五大兵法”的思想精髓转化为推动工作的强大动力，共同助力公司发展。",
"dataset_id": "da33c65c84e311f1995ef33d60f3a479",
"docnm_kwd": "关于有效管理的5大兵法全员学习成果排名的通知20260311-3(2).pdf",
"document_id": "736811e6867111f1a1840f55bb980fcf",
"id": "aa08709e79707983",
"image_id": "da33c65c84e311f1995ef33d60f3a479-aa08709e79707983",
"important_keywords": [],
"positions": [
[
1,
194,
673,
118,
193
],
[
1,
108,
586,
220,
234
],
[
1,
86,
564,
247,
289
],
[
1,
108,
586,
302,
318
],
[
1,
106,
585,
333,
347
],
[
1,
82,
561,
360,
519
],
[
1,
108,
587,
546,
563
],
[
1,
108,
586,
578,
592
],
[
1,
86,
565,
636,
684
]
],
"questions": [],
"tag_kwd": []
}
],
"doc": {
"chunk_count": 1,
"chunk_method": "naive",
"content_hash": "c1c846fb5e3f11cdde966126c08edd80",
"create_date": "2026-07-23T16:35:25",
"create_time": 1784795725133,
"created_by": "2d3546f684e311f1995ef33d60f3a479",
"dataset_id": "da33c65c84e311f1995ef33d60f3a479",
"id": "736811e6867111f1a1840f55bb980fcf",
"location": "关于有效管理的5大兵法全员学习成果排名的通知20260311-3(2).pdf",
"name": "关于有效管理的5大兵法全员学习成果排名的通知20260311-3(2).pdf",
"parser_config": {
"auto_keywords": 0,
"auto_questions": 0,
"built_in_metadata": [],
"children_delimiter": "",
"chunk_token_num": 512,
"compilation_template_group_id": [],
"delimiter": "\n",
"enable_children": false,
"enable_metadata": false,
"graphrag": {
"batch_chunk_token_size": 4096,
"build_subgraph_min_timeout_seconds": 600,
"build_subgraph_timeout_per_chunk_seconds": 300,
"community_timeout_seconds": 1800,
"entity_types": [
"organization",
"person",
"geo",
"event",
"category"
],
"lock_acquire_timeout_seconds": 600,
"merge_timeout_seconds": 180,
"method": "light",
"resolution_timeout_seconds": 1800,
"retry_attempts": 2,
"retry_backoff_max_seconds": 60,
"retry_backoff_seconds": 2,
"use_graphrag": true
},
"html4excel": false,
"image_context_size": 0,
"image_table_context_window": 0,
"layout_recognize": "MinerU",
"llm_id": "",
"metadata": {
"additionalProperties": false,
"properties": {},
"type": "object"
},
"mineru_formula_enable": true,
"mineru_lang": "English",
"mineru_parse_method": "auto",
"mineru_table_enable": true,
"overlapped_percent": 0,
"parent_child": {
"children_delimiter": "\n",
"use_parent_child": false
},
"raptor": {
"ext": {
"clustering_method": "gmm",
"tree_builder": "raptor"
},
"max_cluster": 64,
"max_token": 256,
"prompt": "Please summarize the following paragraphs. Be careful with the numbers, do not make things up. Paragraphs as following:\n {cluster_content}\nThe above is the content you need to summarize.",
"random_seed": 0,
"scope": "file",
"threshold": 0.1,
"use_raptor": true
},
"table_context_size": 0,
"toc_extraction": false,
"topn_tags": 3
},
"pipeline_id": null,
"process_begin_at": "2026-07-23T17:31:21",
"process_duration": 3.94847,
"progress": 1,
"progress_msg": "\n17:31:22 Task has been received.\n17:31:22 Page(12): Start to parse.\n17:31:22 Page(12): [MinerU] Received binary PDF -> /tmp/mineru_bin_pdf_c8_am4fg/关于有效管理的5大兵法全员学习成果排名的通知20260311-3(2).pdf\n17:31:22 Page(12): [MinerU] Output directory: /tmp/mineru_pdf_1e_q4zia\n17:31:22 Page(12): [MinerU] invoke api: http://192.168.100.116:38000/file_parse\n17:31:24 Page(12): [MinerU] zip file returned, saving to /tmp/mineru_pdf_1e_q4zia/关于有效管理的5大兵法全员学习成果排名的通知20260311-3(2)_auto_pb3uxo40.zip...\n17:31:24 Page(12): [MinerU] Unzip to /tmp/mineru_pdf_1e_q4zia/关于有效管理的5大兵法全员学习成果排名的通知20260311-3(2)_auto_pb3uxo40...\n17:31:24 Page(12): [MinerU] Parsed 15 blocks from PDF.\n17:31:24 Page(12): Finish parsing.\n17:31:24 Page(12): Generate 1 chunks\n17:31:24 Page(12): Embedding chunks (0.21s)\n17:31:24 Page(12): Indexing done (0.26s).\n17:31:24 Page(12): Task done (2.36s)",
"run": "DONE",
"size": 133651,
"source_type": "local",
"status": "1",
"suffix": "pdf",
"thumbnail": "thumbnail_736811e6867111f1a1840f55bb980fcf.png",
"token_count": 313,
"type": "pdf",
"update_date": "2026-07-23T17:31:24",
"update_time": 1784799084948
},
"total": 1
}
}
The above is the block information of the obtained document. You can check from where it is located to see if it is in a closed state. In the knowledge base configuration, the "Formula recognition" and "Table recognition" are both in an enabled state.
@dosu

[dosubot]

Thanks for sharing the chunk data. I can see the issue clearly now — the HTML <table> structure is actually preserved correctly (your mineru_table_enable: true is working), but the cell content itself is garbled: "WEY", "AAJEERI", "EPZ$", "#F", "RBKllBA" etc., while the surrounding Chinese text outside the table renders perfectly.

The root cause is your mineru_lang setting. Your parser config shows "mineru_lang": "English", but your document is in Chinese. This language setting controls the OCR model MinerU uses for text recognition [1]. When set to "English", MinerU applies its English OCR model, which misrecognizes Chinese characters — particularly in table cells where text tends to be denser and in smaller fonts.

The reason regular text outside the table appears fine while table content is garbled is that MinerU uses different content paths for text vs. tables [2]. Table cell recognition can be more sensitive to language model mismatches due to the compact layout.

Fix: Change mineru_lang from "English" to "Chinese" in your knowledge base parser configuration, then re-parse the document. This will tell MinerU to use the Chinese OCR model, which should correctly recognize the table cell content.

This is not a bug in RAGFlow's code — RAGFlow correctly passes MinerU's table_body output through without modification when mineru_table_enable is true [3]. The garbled content is coming from MinerU's OCR due to the language mismatch.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[cuihangrui]

Is there still a solution? The knowledge base cannot have only one language of files.
@dosu

[dosubot]

Good point — a knowledge base with mixed-language documents is a common scenario. Here are a couple of options:

Option 1: Set the language per-document (recommended)
mineru_lang is actually a per-document setting stored in each document's parser_config [1]. Even though documents inherit the knowledge base's default config at upload time, you can update individual documents via the API to set a different language. For your Chinese documents, update their parser_config.mineru_lang to "Chinese" and re-parse them, while keeping English documents as-is.

Option 2: Default to Chinese for the knowledge base
If most of your documents are Chinese, set the knowledge base default mineru_lang to "Chinese". The Chinese OCR model in MinerU generally handles English text reasonably well (Latin characters are simpler to recognize), so English documents may still parse acceptably — though with slightly lower accuracy than using the English model.

Option 3: Try mineru_parse_method: "txt"
If your PDFs are text-based (not scanned images), switching the parse method from "auto" to "txt" tells MinerU to extract text directly from the PDF's text layer rather than relying on OCR [2]. This bypasses the OCR language model entirely, which could resolve the garbled table content regardless of the language setting. This only works for PDFs that have embedded text — it won't help with scanned documents.

Unfortunately, there is currently no multilingual or auto-detection mode for mineru_lang [3]. This would be a useful feature enhancement if the maintainers are open to it.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[cuihangrui]

Why did this problem occur? Is it because of an issue with my configuration? @dosu

[dosubot]

I wasn't able to load the screenshot you shared — it may require authentication to access. Could you describe what the screenshot shows? For example:

• Is it an error message? If so, what does it say?
• Is it showing garbled table content similar to what we discussed earlier?
• Is it a configuration page, parsing result, or something else?

Alternatively, you could paste the relevant text or error message directly in a comment so I can help diagnose the issue.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[cuihangrui]

hint : 102 Fail to access model(MinerU/MinerU).[MinerU] MINERU_APISERVER not configured.
The IP address I have configured http://192.168.100.116:38000
MinerU Output Directory /tmp/mineru
MinerU Backend pipline
model name mineru
How should I link to the mineru on the local server?
@dosu

[dosubot]

The error "[MinerU] MINERU_APISERVER not configured" means the MinerU API server URL wasn't properly resolved by RAGFlow. Simply entering the IP in the Model Provider UI fields may not correctly map to the required mineru_apiserver key.

Fix: Set the MINERU_APISERVER environment variable in your RAGFlow deployment:

• If using Docker Compose, add this to your .env file:

  MINERU_APISERVER=http://192.168.100.116:38000
  

  Then restart RAGFlow (docker compose up -d).

• If running directly, export the variable before starting:

  export MINERU_APISERVER=http://192.168.100.116:38000

RAGFlow's MinerU integration resolves the API endpoint by checking: UI model provider config → environment variables → default (empty) [1]. The environment variable approach is the most reliable.

After setting it, RAGFlow will validate connectivity by checking http://192.168.100.116:38000/openapi.json [2]. Make sure the MinerU server at that address is running and accessible from the RAGFlow container.

Also, double-check that your knowledge base has layout_recognize set to the string "MinerU" — there's a known issue in some v0.26.x versions where it can get stored as a UUID instead, which breaks parser resolution [3].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[one985]

You can test this on the Mineru website; the same issue occurs there. Mineru tends to lose data when processing tables within PDFs, so you need to switch the PDF parser.

[cuihangrui]

I noticed that the mineru version has been updated to the latest version 3.4.4. May I ask if ragflow has also been adapted accordingly? @dosu

[dosubot]

RAGFlow connects to MinerU as an external API service rather than bundling it as a direct dependency, so there's no hard version pin. RAGFlow migrated to the MinerU v3 API (using the /file_parse endpoint) in PR #14282 [1], so it should be compatible with MinerU 3.x versions, including 3.4.4, as long as the API contract hasn't changed.

That said, I didn't find any specific testing or mentions of MinerU 3.4.4 in the codebase or recent PRs. If MinerU 3.4.4 introduced API changes or different output formats, there could be subtle compatibility issues.

Regarding @one985's point about MinerU losing table data — the garbled table content you saw earlier was likely due to the mineru_lang being set to "English" for a Chinese document. However, if MinerU itself is misrecognizing tables (as confirmed on MinerU's own website), that's a MinerU-side limitation rather than a RAGFlow issue. In that case, you could try:

• Switching to a different PDF parser like DeepDoc in your knowledge base's layout_recognize setting
• Checking if the newer MinerU 3.4.4 has improved table recognition for your specific documents

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.