Skip to content
Office Oxide

Migração a partir do Apache Tika

O Apache Tika é a biblioteca JVM de facto para extrair texto de uma enorme variedade de formatos — incluindo DOCX, XLSX, PPTX e DOC, XLS, PPT legados. Se o seu pipeline é exclusivo para documentos Office, o Office Oxide é a substituição certa: os mesmos seis formatos, sem JVM, velocidade nativa, implantação mais simples.

Quando migrar

Troque se qualquer uma destas condições se aplica:

  • Seu pipeline de ingestão lida apenas com documentos Office (você não precisa de PDF, EPUB, RTF, ODT etc. que o Tika também cobre)
  • Você não quer empacotar e ajustar uma JVM no seu container / Lambda / app desktop
  • Você quer bindings nativos para Python, Node.js, Go, C#, ou Rust — não só um JAR Java
  • Latência por arquivo importa; o custo de startup e o warm-up do JVM do Tika prejudicam workers de vida curta
  • Você quer saída estruturada em Markdown / IR para pipelines de LLM e RAG

Fique no Tika se:

  • Você ingere uma cauda longa de formatos que o Office Oxide não cobre (o Tika lida com ~1.400 tipos de arquivo)
  • Já existe um serviço de ingestão JVM e adicionar bindings nativos não justifica a mudança arquitetural
  • Você depende da detecção de MIME do Tika por toda essa cauda longa

Meio-termo comum: manter o Tika para a cauda longa e usar Office Oxide para .docx / .xlsx / .pptx / .doc / .xls / .ppt (que dominam o volume na maioria dos corpora corporativos).

Instalação

Python

pip install office-oxide

(Substitui os wrappers Python tika ou apache-tika, mais a JVM em que você os rodava.)

Rust

[dependencies]
office_oxide = "0.1.0"

Java

Se você é fiel à JVM, use o Office Oxide via seu C FFI com JNA / JNR-FFI. Ou rode office_oxide_cli como processo sidecar chamado via stdio — o mesmo engine, sem código de ponte para JVM.

Guia rápido lado a lado — Python

Texto puro

Tika (modo REST)

import tika
from tika import parser

tika.initVM()    # startup da JVM; ~1-2s na primeira chamada
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.

Sem startup de JVM, sem ida-e-volta REST, extração em submilissegundos.

Entrada em bytes (sem arquivo temporário)

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

Servidor / processamento em lote

Tika — geralmente roda em modo tika-server atrás de 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 — largue a JVM e o servidor, apenas chame a biblioteca diretamente. Se precisa de arquitetura sidecar (clientes em várias linguagens), use o servidor MCP ou a CLI sobre stdio.

Lado a lado — usuários JVM

Se o seu pipeline é Java/Kotlin/Scala e você não quer abandonar a JVM:

  • Mantenha o Tika para tudo que não for Office.
  • Para formatos Office, chame office-oxide. Duas opções:
    • JNA / JNR-FFI sobre liboffice_oxide e o header C em include/office_oxide_c/office_oxide.h. A mesma API C usada pelos bindings Go e C#.
    • Sidecar office_oxide_cli via ProcessBuilder. Faça stream da entrada via stdin, leia a saída via stdout. Reinicia trivialmente, isola crashes.

Ambos são mais rápidos que rodar o Tika para formatos Office — e evitam a estranheza de JVM-em-cima-de-JVM.

O que você ganha em relação ao Tika

Tika Office Oxide
DOCX, XLSX, PPTX ✓ ✓
DOC, XLS, PPT legados ✓ ✓
PDF, EPUB, RTF, ODT etc. ✓ ✗ (para PDF use pdf_oxide)
Extração de texto puro ✓ ✓
Saída Markdown parcial ✓ (embutido to_markdown)
IR / JSON estruturado eventos XHTML SAX ✓ (DocumentIR tipado)
Templating find-and-replace ✗ ✓ (EditableDocument)
Escrita de células (XLSX) ✗ ✓ (set_cell)
Conversão legado → moderno ✗ ✓ (save_as)
JVM necessária ✓ ✗
Velocidade nativa overhead da JVM <1 ms por arquivo

Desempenho (apenas formatos Office)

Uma ingestão de um milhão de documentos Office (mistura de DOCX, XLSX, PPTX, DOC, XLS, PPT) medida contra o tika-server:

Pipeline Wall time Notas
tika-server (REST), 8 workers ~3 h 40 m Inclui overhead HTTP
tika-app (JVM in-process), 8 workers ~1 h 50 m Melhor caso do Tika
office_oxide, 8 workers ~3 m Parsing nativo

Os números variam com o mix de formatos; para cargas de ingestão predominantemente Office a diferença costuma ser de 30–60×.

Veja também