Skip to content
Office Oxide

Migration von Apache Tika

Apache Tika ist die De-facto-JVM-Bibliothek zur Textextraktion aus einer riesigen Zahl von Formaten — einschließlich DOCX, XLSX, PPTX und Legacy-DOC, -XLS, -PPT. Wenn Ihre Pipeline ausschließlich Office-Dokumente verarbeitet, ist Office Oxide der richtige Ersatz: dieselben sechs Formate, keine JVM, native Geschwindigkeit, einfacheres Deployment.

Wann migrieren

Wechseln Sie, wenn eines davon zutrifft:

  • Ihr Ingest verarbeitet nur Office-Dokumente (Sie brauchen kein PDF, EPUB, RTF, ODT usw., was Tika auch abdeckt)
  • Sie wollen keine JVM in Container / Lambda / Desktop-App ausliefern und tunen
  • Sie wollen native Bindings in Python, Node.js, Go, C# oder Rust — nicht nur eine Java-JAR
  • Latenz pro Datei zählt; Tikas Startup-Kosten und JVM-Warmup tun kurzlebigen Workern weh
  • Sie wollen strukturierten Markdown-/IR-Output für LLM- und RAG-Pipelines

Bleiben Sie bei Tika, wenn:

  • Sie einen Long Tail von Formaten ingesten, den Office Oxide nicht abdeckt (Tika behandelt ~1 400 Dateitypen)
  • Sie bereits einen JVM-Ingest-Service haben und das Hinzufügen nativer Bindings die Architekturänderung nicht wert ist
  • Sie auf Tikas MIME-Erkennung quer durch den Long Tail setzen

Häufiger Mittelweg: Tika für den Long Tail behalten, Office Oxide für .docx / .xlsx / .pptx / .doc / .xls / .ppt nutzen (die in den meisten Unternehmenskorpora das Volumen dominieren).

Installation

Python

pip install office-oxide

(Ersetzt die Python-Wrapper tika oder apache-tika plus die darunter laufende JVM.)

Rust

[dependencies]
office_oxide = "0.1.0"

Java

Wenn Sie bei der JVM bleiben, nutzen Sie Office Oxide über sein C-FFI plus JNA / JNR-FFI. Oder betreiben Sie office_oxide_cli als Sidecar-Prozess über stdio — gleiche Engine, ohne JVM-Brückencode.

Spickzettel im Direktvergleich — Python

Einfacher Text

Tika (REST-Modus)

import tika
from tika import parser

tika.initVM()    # JVM-Start; ~1-2s beim ersten Aufruf
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 usw.

Kein JVM-Start, kein REST-Hin-und-Her, Submillisekunden-Extraktion.

Bytes-Input (ohne temporäre Datei)

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())

Server / Batch-Verarbeitung

Tika — üblicherweise im tika-server-Modus hinter 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 — lassen Sie JVM und Server weg, rufen Sie einfach die Bibliothek direkt auf. Wenn Sie eine Sidecar-Architektur brauchen (sprachunabhängige Clients), nutzen Sie den MCP-Server oder die CLI über stdio.

Direktvergleich — JVM-Nutzer

Wenn Ihre Pipeline Java/Kotlin/Scala ist und Sie die JVM nicht aufgeben wollen:

  • Behalten Sie Tika für alles, was nicht Office ist.
  • Rufen Sie für Office-Formate office-oxide auf. Zwei Optionen:
    • JNA / JNR-FFI gegen liboffice_oxide und den C-Header unter include/office_oxide_c/office_oxide.h. Das gleiche C-API, das auch Go- und C#-Bindings verwenden.
    • office_oxide_cli-Sidecar via ProcessBuilder. Input über stdin streamen, Output über stdout lesen. Trivial neustartbar, isoliert Crashes.

Beides ist schneller, als Tika für Office-Formate laufen zu lassen — und vermeidet JVM-auf-JVM-Kuriositäten.

Was Sie gegenüber Tika bekommen

Tika Office Oxide
DOCX, XLSX, PPTX ✓ ✓
Legacy-DOC, -XLS, -PPT ✓ ✓
PDF, EPUB, RTF, ODT usw. ✓ ✗ (für PDF siehe pdf_oxide)
Extraktion einfachen Texts ✓ ✓
Markdown-Ausgabe teilweise ✓ (eingebaut to_markdown)
Strukturiertes IR / JSON XHTML-SAX-Events ✓ (typisiertes DocumentIR)
Find-and-Replace-Templating ✗ ✓ (EditableDocument)
Zellen-Schreiben (XLSX) ✗ ✓ (set_cell)
Legacy → Modern-Konvertierung ✗ ✓ (save_as)
JVM erforderlich ✓ ✗
Native Geschwindigkeit JVM-Overhead <1 ms pro Datei

Performance (nur Office-Formate)

Ein Ingest von einer Million Office-Dokumenten (Mix aus DOCX, XLSX, PPTX, DOC, XLS, PPT), gemessen gegen tika-server:

Pipeline Wall-Time Hinweise
tika-server (REST), 8 Worker ~3 h 40 m Inklusive HTTP-Overhead
tika-app (in-process JVM), 8 Worker ~1 h 50 m Tikas Bestfall
office_oxide, 8 Worker ~3 m Native Analyse

Zahlen schwanken mit dem Format-Mix; bei ingestlastigen Office-Workloads liegt der Abstand meist bei 30–60×.

Siehe auch