Skip to content
Office Oxide

Міграція з Apache Tika

Apache Tika — де-факто JVM-бібліотека для вилучення тексту з величезної кількості форматів — включно з DOCX, XLSX, PPTX та застарілими DOC, XLS, PPT. Якщо ваш конвеєр виключно для документів Office, Office Oxide — правильна заміна: ті самі шість форматів, без JVM, нативна швидкість, простіше розгортання.

Коли мігрувати

Перемикайтеся, якщо щось із цього про вас:

  • Ваш інжест працює лише з документами Office (вам не потрібні PDF, EPUB, RTF, ODT тощо, які також опрацьовує Tika)
  • Ви не хочете тягнути й налаштовувати JVM у контейнері / Lambda / десктопному застосунку
  • Ви хочете нативні біндинги для Python, Node.js, Go, C# чи Rust — а не лише Java-JAR
  • Важлива затримка на файл; старт JVM і прогрів Tika бʼють по короткоживучих воркерах
  • Потрібен структурований вивід Markdown / IR для LLM- і RAG-конвеєрів

Залишайтеся на Tika, якщо:

  • Ви інжестите довгий хвіст форматів, який Office Oxide не покриває (Tika опрацьовує ~1 400 типів файлів)
  • У вас уже є JVM-сервіс інжесту й додавання нативних біндингів не варте змін архітектури
  • Ви покладаєтесь на MIME-детекцію Tika по всьому цьому довгому хвосту

Часта серединка: залишити Tika для довгого хвоста, а .docx / .xlsx / .pptx / .doc / .xls / .ppt (які в більшості корпоративних корпусів домінують за обсягом) віддати Office Oxide.

Встановлення

Python

pip install office-oxide

(Замінює Python-обгортки tika або apache-tika плюс JVM, на якій ви їх запускали.)

Rust

[dependencies]
office_oxide = "0.1.0"

Java

Якщо ви відданий JVM, використовуйте Office Oxide через його C FFI плюс JNA / JNR-FFI. Або запускайте office_oxide_cli як sidecar-процес, що викликається через stdio — той самий двигун, без коду 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-сервер або CLI через stdio.

Поруч — користувачі JVM

Якщо ваш конвеєр Java/Kotlin/Scala і ви не хочете відмовлятися від JVM:

  • Залиште Tika для всього, що не Office.
  • Для Office-форматів викликайте office-oxide. Два варіанти:
    • JNA / JNR-FFI проти liboffice_oxide та C-заголовка в include/office_oxide_c/office_oxide.h. Той самий C API, який використовують біндинги Go та C#.
    • Sidecar office_oxide_cli через ProcessBuilder. Потокуйте вхід через stdin, читайте вихід зі stdout. Тривіально перезапускається, ізолює збої.

Обидва варіанти швидші за запуск Tika на Office-форматах — і уникають дивацтва «JVM поверх 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)
Конвертація legacy → modern ✗ ✓ (save_as)
Потрібна JVM ✓ ✗
Нативна швидкість накладні витрати JVM <1 мс на файл

Продуктивність (лише Office-формати)

Інжест мільйона Office-документів (мікс DOCX, XLSX, PPTX, DOC, XLS, PPT), виміряний проти tika-server:

Конвеєр Wall time Нотатки
tika-server (REST), 8 воркерів ~3 год 40 хв Включає накладні HTTP
tika-app (in-process JVM), 8 воркерів ~1 год 50 хв Найкращий випадок Tika
office_oxide, 8 воркерів ~3 хв Нативний парсинг

Цифри залежать від складу форматів; для інжест-орієнтованих Office-навантажень розрив зазвичай 30–60×.

Див. також