一个接口吃下 1000+ 种文件格式的「解析瑞士军刀」，搜索引擎和 RAG 管线的无名英雄
更新于 2026-08-21 · 稳定版 3.3.2 / 4.0.0-beta-1
← 返回汇总别为每种格式写一个解析器——Tika 替你写完了 1000 种
Apache 基金会顶级项目（前身是 Lucene 子项目）。单一 API 完成检测（这是什么文件）+ 元数据提取 + 正文提取，覆盖 Office、PDF、邮件、压缩包、音视频、图像等上千种格式。4.x 起默认输出 Markdown、fork 进程隔离防崩溃、内置 VLM 解析器兜底——明确面向 LLM / RAG / Agent 管线。
ASF 顶级项目 · 官方发布线：4.x（beta）为最新特性线，3.3.2（2026-07）为稳定线，2.x 已于 2025 年 EOL。
docx/xlsx/pptx/eml/msg/zip/七种 PDF/三种图像元数据……每接一种格式就是一轮 POI/PDFBox/自研解析器的坑。Tika 一层 API 全盖掉。
上传的文件说自己是 pdf 未必是 pdf。Tika 用文件名 + 魔数 + 容器嗅探三级检测定MediaType，再派发给正确解析器。
解析器面对的是不可信输入。Tika 官方安全模型直言「进程内解析无法做到防 DoS」，于是 4.x 把解析搬进 fork 的子进程——崩的是 fork，不是你的服务。
想亲手玩一遍这条检测链？下一页有浏览器版 Playground，拖任意文件即时出结果。
拖入任意文件，看魔数匹配、容器嗅探、文本编码启发式逐级给出判定——正是 Tika 检测引擎的决策过程。纯本地运行，文件不上传。
打开文件类型检测 Playground →# 4.x 的 CLI 默认就是 Markdown（3.x 默认纯文本） java -jar tika-app-4.x.jar document.docx # → Markdown java -jar tika-app-4.x.jar --text doc.pdf # → 纯文本 java -jar tika-app-4.x.jar -J doc.pdf # → 结构化 JSON：元数据 + 正文 # 且递归提取所有嵌入附件
恶意 PDF 触发 PDFBox 死循环？崩掉的是 fork 出来的解析进程，主服务无感。配套统一超时模型，大规模场景由 tika-pipes 编排。这是官方安全模型的正解——「进程内解析无法防 DoS」。
OCR 也读不了的（手写、复杂表格嵌图、扫描质量差）交给视觉语言模型：Claude / Gemini / OpenAI 三家开箱可选，作为解析链的最后一级兜底。
逐级降级：能规则解析的不上 OCR，能 OCR 的不烧 VLM token。另有可复现构建——同源码同 JDK 字节级一致。
| 形态 | 模块 | 适合 | 要点 |
|---|---|---|---|
| Java API | tika-core + parsers | 嵌入应用 | 3 行代码起步，依赖可裁剪 |
| CLI | tika-app | 脚本 / 临时任务 | 4.x 起为 runnable zip（薄 launcher + lib/） |
| REST | tika-server | 多语言调用 | 不安全端点默认关闭，需显式 enableUnsecureFeatures=true |
| gRPC | tika-grpc | 高性能内网服务 | 跨语言强类型接口 |
| Pipes | tika-pipes | 海量批量 / 不可信文档 | fork 隔离 + 统一超时 + pf4j 插件扩展 |
// Java：检测 + 抽正文 import org.apache.tika.Tika; Tika tika = new Tika(); String text = tika.parseToString( new File("document.docx")); System.out.println(text);
Maven 引 tika-parsers-standard-package，版本对齐用 tika-bom。
# CLI：解压 zip 后进入目录运行 $ java -jar tika-app-4.x.jar doc.pdf # 输出 Markdown，附元数据 title: 季度报告 author: … # 第一节 正文内容…
注意：jar 是薄启动器，必须带着相邻的 lib/ 目录跑，单独拷 jar 会 NoClassDefFoundError。
| 维度 | Tika | pdf-inspector |
|---|---|---|
| 格式覆盖广度 | 10 | 2 |
| 成熟度 / 稳定性 | 9.5 | 5.5 |
| 安全性（恶意文档） | 9.5 | 6 |
| OCR 能力 | 9 | 7 |
| 社区 / 生态 | 8.5 | 7.5 |
| 文档质量 | 8.5 | 7.5 |
| Markdown / LLM 输出 | 7 | 9 |
| 集成便捷性 | 6.5 | 9 |
| PDF 文本提取质量 | 6 | 9 |
| 表格还原 | 4 | 8.5 |
| 速度 / 性能 | 5 | 9.5 |
| 简单平均 | 7.6 | 7.3 |
绿条 = 该维度胜者。Tika 赢在「广与稳」，pdf-inspector 赢在「深与快」——不是替代关系。
权重 = 提取质量×3 + 速度×3 + 广度×0.5：
pdf-inspector ≈ 8.8 vs Tika ≈ 5.9
RAG 入库、批量 PDF 归一化、浏览器端解析——选 Rust 那个。
权重 = 广度×3 + 安全×3 + 成熟度×2：
Tika ≈ 9.2 vs pdf-inspector ≈ 4.9
任意格式上传入口、邮件网关、恶意样本分析——选 Apache 那个。
互补架构才是正解：pdf-inspector 做路由（54% 原生文本 PDF 本地秒解），Tika 吃掉其余全部格式，扫描页交给 OCR / VLM。
LLM 应用越普及，「把任意真实文件变成模型能吃的文本」的需求越刚性。Tika 用 15 年积累的 1000+ 格式覆盖 + 4.x 的 Agent 原生改造（Markdown 默认、fork 隔离、VLM 兜底、官方 Skills），把自己从「搜索时代基建」重新拉回 LLM 时代主航道。