anydoc：用一个 Rust 库搞定 14 种文档格式转 Markdown

在 AI 应用开发中，为大模型提供文档数据是一项看似简单却极其繁琐的工作。用户上传的文件格式五花八门：二十年前的 Word 合同、Excel 报表、PowerPoint 演示文稿、电子书，甚至 RTF 文本。这些格式在转换为 AI 可读的 Markdown 时，现有方案往往力不从心——每个库只能覆盖部分格式，想要全支持就得拼接四五个不同的依赖库，不仅增加复杂度，还会导致输出格式不统一、错误处理各异等问题。

性能表现：速度优势显著

Firecrawl 近期开源的 anydoc 库试图从根本上解决这一痛点。这是一个用 Rust 编写的文档转换工具，能够将 14 种文档格式统一转换为 GitHub Flavored Markdown（GFM）。支持范围涵盖 Word（doc、docx、docm）、PowerPoint（ppt、pps、pot、pptx、pptx、pptm、ppsx、ppsm）、Excel（xls、xlsx、xlsm、xlsb）、OpenDocument（odt、ods、odp）、RTF、EPUB、CSV 等 8 大类共 21 种文件扩展名。PDF 格式则由同一团队开发的 pdf-inspector 库专门处理。

架构设计：一次解析，共享模型

根据官方基准测试（100 份真实文档，覆盖全部 14 种格式），anydoc 的中位转换时间仅为 4.4ms，综合评分达到 81 分。对比主流方案：markitdown 覆盖 6 种格式、中位耗时 134.8ms，pandoc 覆盖 5 种格式、中位耗时 102.1ms，docling 覆盖 4 种格式、中位耗时 513.6ms。anydoc 的速度领先幅度达到 20-245 倍。实际测试中，单个 docx 文件转换仅需 0.78ms，500 个 docx 文件的进程内循环总耗时 0.056 秒，平均每个文件 0.11ms。

安全防护：多层次保障稳定可靠

anydoc 的架构设计值得深入了解。其核心思路是“一次解析，共享模型”：每种格式使用独立的 parser 解析，但最终都映射到统一的 Document 数据模型（包含 blocks、inlines、tables、footnotes、assets 等组件），再由同一个 Markdown 序列化器输出。这种设计带来一个关键优势——修复一个问题，所有格式同时受益。例如，修复 docx 表格转义问题后，rtf、odt、epub 的表格处理也会自动改善。此外，格式检测基于文件内容而非扩展名，能够准确识别被错误命名的文件。代码规模约 1.7 万行，包含 58 个快照测试和针对每个 fixture 的变异测试，工程质量在早期开源项目中属于较高水平。

应用建议与局限性

对于需要在管线中处理多种格式用户文档的 AI 应用开发者，anydoc 提供了目前覆盖最全面、速度最快的现成方案。MIT 许可证允许自由使用，Node、Python、WASM 绑定齐全，可通过 npx skills add firecrawl/anydoc 集成到 Claude Code、Codex 等 AI Agent 中。不过需要客观看待其局限性：官方基准使用的文档集来自团队内部，缺乏第三方独立验证；PDF 路径在处理中文复杂版面（如多列表格、数据卡片）时质量不如 MinerU；当前版本为 0.1.7，发布仅一周已更新 7 个版本，API 稳定性有待观察。如果你的场景仅涉及 Word 文档，mammoth（95 分）可能比 anydoc（87 分）是更合适的选择。

如有侵权，请联系删除。