Skip to content
Office Oxide

Migration von Apache Tika

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

Wann sich eine Migration lohnt

Wechseln Sie, wenn eines dieser Kriterien auf Sie zutrifft:

  • Ihre Ingest-Pipeline verarbeitet nur Office-Dokumente (kein Bedarf an PDF, EPUB, RTF, ODT usw., die Tika ebenfalls unterstützt)
  • Sie möchten keine JVM in Ihren Container / Ihre Lambda / Ihre Desktop-App einbetten und konfigurieren
  • Sie benötigen native Bindings für Python, Node.js, Go, C# oder Rust — nicht nur eine Java-JAR
  • Die Latenz pro Datei spielt eine Rolle; Tikas Startzeit und der JVM-Warmup belasten kurzlebige Worker spürbar
  • Sie benötigen strukturierten Markdown-/IR-Output für LLM- und RAG-Pipelines

Bleiben Sie bei Tika, wenn:

  • Sie einen Long Tail von Formaten verarbeiten, die Office Oxide nicht abdeckt (Tika unterstützt rund 1.400 Dateitypen)
  • Sie bereits einen JVM-basierten Ingest-Dienst betreiben und der Aufwand für native Bindings die Architekturänderung nicht rechtfertigt
  • Sie auf Tikas MIME-Erkennung für diesen Long Tail angewiesen sind

Ein bewährter Mittelweg: Tika für den Long Tail behalten und Office Oxide für .docx / .xlsx / .pptx / .doc / .xls / .ppt einsetzen, die in den meisten Unternehmenskorpora den Großteil des Volumens ausmachen.

Installation

Python

pip install office-oxide

(Ersetzt die Python-Wrapper tika oder apache-tika samt der darunter laufenden JVM.)

Rust

[dependencies]
office_oxide = "0.1.0"

Java

Wer bei der JVM bleiben möchte, kann Office Oxide über sein C-FFI zusammen mit JNA / JNR-FFI nutzen. Alternativ lässt sich office_oxide_cli als Sidecar-Prozess betreiben, der über stdio aufgerufen wird — gleiche Engine, kein JVM-Brückencode.

Direktvergleich als Spickzettel — Python

Einfacher Text

Tika (REST-Modus)

import tika
from tika import parser

tika.initVM()    # JVM startup; ~1-2s on first call
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, etc.

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

Bytes als Eingabe (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 — wird üblicherweise im tika-server-Modus hinter einem HTTP-Endpunkt betrieben.

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 und Server können entfallen; rufen Sie die Bibliothek einfach direkt auf. Wenn Sie eine Sidecar-Architektur benötigen (sprachunabhängige Clients), nutzen Sie den MCP-Server oder die CLI über stdio.

Direktvergleich für JVM-Nutzer

Wenn Ihre Pipeline auf Java/Kotlin/Scala basiert und Sie die JVM nicht aufgeben möchten:

  • Behalten Sie Tika für alles, was kein Office-Format ist.
  • Für Office-Formate rufen Sie office-oxide auf. Zwei Möglichkeiten:
    • JNA / JNR-FFI gegen liboffice_oxide und den C-Header unter include/office_oxide_c/office_oxide.h. Dasselbe C-API, das auch die Go- und C#-Bindings verwenden.
    • office_oxide_cli als Sidecar via ProcessBuilder. Eingabe über stdin streamen, Ausgabe über stdout lesen. Problemlos neustartbar, Abstürze werden isoliert.

Beide Varianten sind bei Office-Formaten schneller als Tika — und umgehen die bekannten Eigenheiten von JVM-in-JVM-Setups.

Was Sie gegenüber Tika gewinnen

Tika Office Oxide
DOCX, XLSX, PPTX ✓ ✓
Legacy-DOC, -XLS, -PPT ✓ ✓
PDF, EPUB, RTF, ODT usw. ✓ ✗ (für PDF: pdf_oxide)
Extraktion von Klartext ✓ ✓
Markdown-Ausgabe teilweise ✓ (eingebaut: to_markdown)
Strukturiertes IR / JSON XHTML-SAX-Events ✓ (typisiertes DocumentIR)
Suchen-und-Ersetzen-Templating ✗ ✓ (EditableDocument)
Zellen schreiben (XLSX) ✗ ✓ (set_cell)
Legacy → Modern-Konvertierung ✗ ✓ (save_as)
JVM erforderlich ✓ ✗
Native Geschwindigkeit JVM-Overhead unter 1 ms pro Datei

Performance (nur Office-Formate)

Ingest von einer Million Office-Dokumenten (Mix aus DOCX, XLSX, PPTX, DOC, XLS, PPT) im Vergleich zum tika-server:

Pipeline Tatsächliche Laufzeit Hinweise
tika-server (REST), 8 Worker ~3 h 40 m Inkl. HTTP-Overhead
tika-app (in-process JVM), 8 Worker ~1 h 50 m Bestmögliches Tika-Ergebnis
office_oxide, 8 Worker ~3 m Natives Parsing

Die Werte hängen vom Format-Mix ab; bei ingest-lastigen Office-Workloads beträgt der Unterschied typischerweise das 30- bis 60-Fache.