Skip to content
Office Oxide

从 Apache Tika 迁移

Apache Tika 是从海量文件格式中抽取文本的事实标准 JVM 库 — 包括 DOCX、XLSX、PPTX 和遗留的 DOC、XLS、PPT。如果你的流水线只处理 Office 文档,Office Oxide 就是合适的替代品:同样的六种格式,不需要 JVM,原生速度,部署更简单。

何时迁移

下列任一条成立就切换:

  • 你的摄取流水线只处理 Office 文档(不需要 Tika 顺带支持的 PDF、EPUB、RTF、ODT 等)
  • 你不想在容器 / Lambda / 桌面应用里随附并调优 JVM
  • 你想要 Python、Node.js、Go、C#、Rust 的原生绑定 — 而不仅仅是一个 Java JAR
  • 单文件延迟很重要;Tika 的启动开销和 JVM 预热会拖垮短生命周期 worker
  • 你需要给 LLM 和 RAG 流水线的结构化 Markdown / IR 输出

继续用 Tika 的场景:

  • 你需要摄取 Office Oxide 不覆盖的长尾格式(Tika 处理约 1,400 种文件类型)
  • 你已经有一个 JVM 摄取服务,为此加一层原生绑定不值得做架构调整
  • 你依赖 Tika 在这些长尾格式上的 MIME 检测

一个常见的折中:长尾交给 Tika,.docx / .xlsx / .pptx / .doc / .xls / .ppt(它们在大多数企业语料里占大头)交给 Office Oxide。

安装

Python

pip install office-oxide

(替换 tika 或 apache-tika 的 Python 包装,以及承载它们的 JVM。)

Rust

[dependencies]
office_oxide = "0.1.0"

Java

如果你执意留在 JVM 上,通过 C FFI 加 JNA / JNR-FFI 调用 Office Oxide。或者把 office_oxide_cli 作为通过 stdio 调用的 sidecar 进程运行 — 同一个引擎,没有 JVM 桥接代码。

对照速查 — Python

纯文本

Tika(REST 模式)

import tika
from tika import parser

tika.initVM()    # JVM 启动;首次调用约 1-2s
parsed = parser.from_file("report.docx")
text = parsed["content"]
metadata = parsed["metadata"]

office_oxide

from office_oxide import Document

with Document.open("report.docx") as doc:
    text = doc.plain_text()
    props = doc.as_docx().core_properties()    # author、modified 等

没有 JVM 启动,没有 REST 往返,亚毫秒级抽取。

字节输入(不走临时文件)

Tika

import io, requests
from tika import parser

data = requests.get(url).content
parsed = parser.from_buffer(io.BytesIO(data))

office_oxide

import requests
from office_oxide import Document

data = requests.get(url).content
with Document.from_bytes(data, "docx") as doc:
    print(doc.plain_text())

服务端 / 批处理

Tika — 通常以 tika-server 模式跑在 HTTP 后面。

java -jar tika-server.jar -h 0.0.0.0 -p 9998

import requests
text = requests.put("http://localhost:9998/tika",
                     data=open("report.docx", "rb"),
                     headers={"Accept": "text/plain"}).text

office_oxide — 丢掉 JVM 和服务端,直接调库。如果需要 sidecar 架构(语言中立的客户端),用 MCP 服务器 或通过 stdio 调 CLI。

对照 — JVM 用户

如果你的流水线是 Java/Kotlin/Scala 且不想丢掉 JVM:

  • 非 Office 的一切仍交给 Tika。
  • Office 格式调用 office-oxide。两种方式:
    • 用 JNA / JNR-FFI 调 liboffice_oxide 和 C 头文件 include/office_oxide_c/office_oxide.h。这就是 Go 和 C# 绑定用的同一套 C API。
    • 通过 ProcessBuilder 启 office_oxide_cli sidecar。用 stdin 流入输入,stdout 读取输出。重启成本低,崩溃被隔离。

两者都比让 Tika 处理 Office 格式快 — 而且避免了 JVM-on-JVM 的怪状。

相对 Tika 你得到什么

Tika Office Oxide
DOCX、XLSX、PPTX ✓ ✓
遗留 DOC、XLS、PPT ✓ ✓
PDF、EPUB、RTF、ODT 等 ✓ ✗(PDF 用 pdf_oxide)
纯文本抽取 ✓ ✓
Markdown 输出 部分 ✓(内置 to_markdown)
结构化 IR / JSON XHTML SAX 事件 ✓(类型化 DocumentIR)
查找替换模板化 ✗ ✓(EditableDocument)
单元格写入(XLSX) ✗ ✓(set_cell)
遗留 → 现代转换 ✗ ✓(save_as)
需要 JVM ✓ ✗
原生速度 JVM 开销 每文件 <1 ms

性能(仅 Office 格式)

一百万份 Office 文档摄取(DOCX、XLSX、PPTX、DOC、XLS、PPT 混合),对比 tika-server:

流水线 挂钟时间 备注
tika-server(REST),8 worker ~3 h 40 m 含 HTTP 开销
tika-app(进程内 JVM),8 worker ~1 h 50 m Tika 最佳情况
office_oxide,8 worker ~3 m 原生解析

具体数字随格式组合变化;对以摄取为主的 Office 负载,差距通常在 30–60 倍。

相关链接