Skip to content
Office Oxide

Migração a partir do Apache Tika

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

Quando migrar

Faça a troca se qualquer uma dessas condições se aplicar:

  • Seu pipeline de ingestão trata apenas de documentos Office (não precisa de PDF, EPUB, RTF, ODT etc., que o Tika também suporta)
  • Você não quer empacotar e ajustar uma JVM no seu container / Lambda / app desktop
  • Você precisa de bindings nativos em Python, Node.js, Go, C# ou Rust — não apenas um JAR Java
  • A latência por arquivo importa; o custo de inicialização e o warm-up da JVM do Tika prejudicam workers de vida curta
  • Você precisa de 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 cerca de 1.400 tipos de arquivo)
  • Já existe um serviço de ingestão em JVM e adicionar bindings nativos não justifica a mudança arquitetural
  • Você depende da detecção de MIME do Tika em toda essa cauda longa

Meio-termo comum: manter o Tika para os formatos incomuns e usar o Office Oxide para .docx / .xlsx / .pptx / .doc / .xls / .ppt (que dominam o volume na maioria dos corpora empresariais).

Instalação

Python

pip install office-oxide

(Substitui os wrappers Python tika ou apache-tika e também a JVM em que você os rodava.)

Rust

[dependencies]
office_oxide = "0.1.0"

Java

Se você prefere continuar na JVM, use o Office Oxide via C FFI junto com JNA / JNR-FFI. Outra opção é executar office_oxide_cli como processo sidecar chamado via stdio — o mesmo motor, sem código de ponte para a JVM.

Guia rápido lado a lado — Python

Texto puro

Tika (modo REST)

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.

Sem inicialização de JVM, sem ida e volta via 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 executado no modo tika-server por trás de um 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 — abandone a JVM e o servidor, basta chamar a biblioteca diretamente. Se precisar de uma arquitetura sidecar (clientes em múltiplas linguagens), use o servidor MCP ou a CLI via stdio.

Comparação para usuários de JVM

Se o seu pipeline é Java/Kotlin/Scala e você não quer abrir mão da 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 de Go e C#.
    • Sidecar office_oxide_cli via ProcessBuilder. Faça stream da entrada pelo stdin, leia a saída pelo stdout. Reinicialização trivial, isolamento de falhas garantido.

Ambas as opções são mais rápidas do que usar o Tika para formatos Office — e evitam as estranhezas 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 em Markdown parcial ✓ (embutido to_markdown)
IR / JSON estruturado eventos XHTML SAX ✓ (DocumentIR tipado)
Templating com busca e substituição ✗ ✓ (EditableDocument)
Escrita de células (XLSX) ✗ ✓ (set_cell)
Conversão legado → moderno ✗ ✓ (save_as)
JVM necessária ✓ ✗
Velocidade nativa overhead da JVM menos de 1 ms por arquivo

Desempenho (somente formatos Office)

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

Pipeline Tempo real Observações
tika-server (REST), 8 workers ~3 h 40 m Inclui overhead HTTP
tika-app (JVM in-process), 8 workers ~1 h 50 m Melhor cenário para o Tika
office_oxide, 8 workers ~3 m Parsing nativo

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

Veja também