[Bug] 知识库解析：select_parser 与 chunker 白名单不一致，mdx/mkd/html/csv/rtf 等格式无路由或路由矛盾

[xiaoyuyu6420]

问题描述

KB 解析器路由（select_parser）与分块器（chunker）的格式白名单不一致，且部分常见格式完全无路由。

• astrbot/core/knowledge_base/parsers/util.py 的 select_parser 只支持：.md/.txt/.markdown（TextParser）、.rst/.adoc/.xlsx/.docx/.xls（MarkitdownParser）、.epub、.pdf，其余一律抛「暂时不支持的文件格式」
• astrbot/core/knowledge_base/kb_helper.py（约 336-337 行）的 Markdown 分块白名单还包含 .mdx、.mkd——这两个扩展名在 select_parser 中没有对应解析器，上传会在解析阶段直接失败，该分支实际是死代码，两侧自相矛盾
• .html/.htm、.csv、.rtf 完全没有路由，但 MarkitdownParser（markitdown-no-magika）本身能解析 html/rtf/csv，能力被浪费

另外，上传链路只依赖文件名末尾扩展名（astrbot/dashboard/services/knowledge_base_service.py 约 577-579 行），没有任何 magic bytes 内容嗅探；astrbot/core/computer/file_read_utils.py 中针对 zip 头/mimetype 的嗅探逻辑在 KB 上传路径没有复用。

建议修复

• 对齐 select_parser 与 chunker 白名单（为 .mdx/.mkd 增加 TextParser 路由，或移除 chunker 侧死分支）
• 考虑将 .html/.htm/.csv/.rtf 路由到 MarkitdownParser，无 markitdown 依赖时优雅降级
• （可选）上传时用内容嗅探校验扩展名与真实格式一致

[dosubot]

@xiaoyuyu6420 核实了一下代码，你描述的三个问题都能在当前代码里确认：

1. .mdx/.mkd 死分支

select_parser 把 .md/.txt/.markdown/.rst/.adoc/.xlsx/.docx/.xls 全部路由到 MarkitdownParser，.epub 和 .pdf 各有专属解析器，其余一律 raise ValueError("暂时不支持的文件格式")。而 kb_helper.py 的分块器选择逻辑 白名单里包含了 .mdx 和 .mkd——这两个扩展名在 select_parser 中完全没有路由，上传会在解析阶段直接报错，走不到分块那一步，所以这两个分支确实是死代码。

2. .html/.htm/.csv/.rtf 无路由

select_parser 没有任何分支覆盖这几个扩展名，会直接落到 raise ValueError [1]。而 MarkitdownParser 底层用的是 markitdown_no_magika，理论上具备解析 html/rtf/csv 的能力，只是没有被加入路由白名单。

3. 上传链路仅按扩展名分发，无内容嗅探

knowledge_base_service.py 只从文件名末尾字符串取 file_type，然后原样传给 select_parser(f".{file_type}")，没有任何 magic bytes 校验。而 file_read_utils.py 里已有一套基于 zip 头区分 docx/epub 的嗅探逻辑（_looks_like_zip_container、_is_docx_bytes、_is_epub_bytes），但这套逻辑是给 computer/file 工具用的，KB 上传路径完全没有复用。

你提出的三点修复方向都合理。额外补充一下：#9598 报告了当 markitdown-no-magika 依赖缺失时上传会失败，且错误信息被吞成通用的"文档解析失败"，看不出真实原因——如果要给 .html/.csv/.rtf 接入 MarkitdownParser，在依赖缺失时的优雅降级和明确错误提示也值得一并考虑。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.