JOTO
联系我们
← AI 智库
知识库

14 种文档格式转 Markdown,一个 Rust 库全搞定

2026 年 8 月 7 日

Firecrawl 开源 Rust 库 anydoc,14种文档格式一键转 Markdown,无需多库拼接,实测速度碾压同类工具。 核心内容: 1. 文档格式转换痛点与现有方案局限 2. anydoc 库的功能覆盖与技术特性 3. 实测性能表现及速度优势

给 AI 应用喂文档这件事,比想象中麻烦。

用户上传的永远是"他手头有什么":2003 年的 .doc 合同、2009 年的 .xls 导出表、一页 pitch deck、一本 .epub。AI 要读这些,得先变成干净的 Markdown。市面上每个库只覆盖一部分格式——官方基准里 markitdown 只跑通 6 种,pandoc 5 种,docling 4 种。想全支持,就把四五个库拼起来,每个都有自己的依赖、输出格式和失败方式。

前几天 Firecrawl 开源了 anydoc,想终结这件事:一个 Rust 库,14 种格式,一个输出格式。

● ● ●

一个库,14 种格式

anydoc 是 Firecrawl 开的第二个 Rust 解析库(第一个是 pdf-inspector,专做 PDF)。两个库分工明确:PDF 归 pdf-inspector,其他格式全归 anydoc。

支持清单:

  • Word:doc、docx、docm
  • PowerPoint:ppt、pps、pot、pptx、pptm、ppsx、ppsm
  • Excel:xls、xlsx、xlsm、xlsb
  • OpenDocument:odt、ods、odp
  • RTF、EPUB、CSV
  • PDF(走 pdf-inspector)

8 大类、21 种扩展名(PDF 单独归 pdf-inspector),全部输出 GitHub Flavored Markdown。标题带锚点,表格带合并单元格,脚注、任务列表、演讲者备注都在。

没有 API key,没有系统依赖。Rust 代码里调 anydoc::to_markdown("report.docx") 就完事。Node、Python、WASM 绑定都有,npm 包零依赖。

● ● ●

实测:比宣传的还快

官方 README 说中位转换时间 4.4ms。我克隆下来在 WSL 上实测:

  • 单个 docx:0.78ms
  • 500 个 docx 进程内循环:0.056 秒(每个 0.11ms)
  • PDF 文本页:20ms(走 pdf-inspector)

网上流传的"500 个 docx 只要 1.7 秒",我翻了 README 和官方博客都没找到出处。实测进程内只要 0.056 秒——比那个数字还快两个数量级。1.7 秒那个说法大概算上了进程启动开销:CLI 串行跑 500 次,每次 exec 约 10ms,总计 5.8 秒,瓶颈在进程启动不在解析本身。

和现有方案比,官方基准(100 份真实文档,覆盖 14 种格式;博客口径 94 份):

工具
覆盖格式
中位耗时
综合分
anydoc
14/14
4.4ms
81
markitdown
6/14
134.8ms
65
pandoc
5/14
102.1ms
56
docling
4/14
513.6ms
57
LibreOffice 管线
12/14
1129.5ms
40

快 20-245 倍的说法就是这么来的,取决于和谁比。注意 LibreOffice 那行:综合分 40 是因为它走"转 HTML 再转 Markdown"的弯路,格式保真度差,还慢。

● ● ●

为什么快:一次解析,共享模型

anydoc 的设计比速度本身更值得看。

anydoc 架构:14 种格式 → 共享模型 → GFM 输出

anydoc 架构:14 种格式 → 共享模型 → GFM 输出

每种格式一个 parser,但解析完都塞进同一个 Document 模型(blocks、inlines、tables、footnotes、assets),最后由同一个 Markdown 序列化器输出。效果是:

  • docx 的表格转义修好,rtf、odt、epub 的表格自动跟着好——修一次,全格式受益
  • 格式检测看内容不看扩展名:PDF 头、RTF 开组、OLE 流名、ZIP mimetype,错标扩展名的文件照样转对
  • 安全边界做得很足:zip 炸弹、图片炸弹、深层嵌套都有固定限制,测了 25 轮字节变异防 panic

代码约 1.7 万行,58 个快照测试,每个 fixture 还有变异测试兜底。工程质量在早期开源项目里算讲究的。

● ● ●

诚实的边界

发布 4 天拿了 8 千多星,病毒式传播,但有几个点得说清楚:

  • 语料是自家的
    。官方基准用的 100 份文档是他们自己的,没有第三方复核。官方博客自己承认:单看 docx 完整性,mammoth 95 分 vs anydoc 87 分——如果你只处理 docx,mammoth 可能更合适
  • 中文复杂版面要小心
    。PDF 路径走 pdf-inspector,文本型 PDF 中文零乱码,但数据卡片、多列表格这种复杂版面,质量不如 MinerU
  • 很新
    。v0.1.7,一周发了 7 个版本,API 可能还会动

● ● ●

对 AI 应用开发者

如果管线里有一堆用户上传的杂格式文档,这是目前覆盖最全、最快的现成方案。MIT 协议,随便用。Firecrawl 还把它做成了 Agent Skill,npx skills add firecrawl/anydoc,Claude Code、Codex 之类的 agent 装上就能读文档。

另外值得琢磨的是 Firecrawl 的玩法:两个开源库,内嵌在自家 /parse 和 /scrape 端点里。开源版本覆盖 90% 的场景,剩下扫描件 OCR 的场景,引导到付费 API。免费获客,两头都占。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务,帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们
联系我们

开启企业级 AI 落地

留下你的行业、部门和当前痛点,我们会在 1 个工作日内与你联系,帮你判断适合先做什么、需要准备哪些数据、适合什么平台。

微信咨询
扫码添加,一对一沟通
JOTO 微信咨询二维码
发送邮件
jotoai@jototech.cn

填写需求单

收到你的信息后,我们将在 1 个工作日内与你取得联系。