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 для рідкісних форматів і використовувати Office Oxide для .docx / .xlsx / .pptx / .doc / .xls / .ppt — вони домінують за обсягом у більшості корпоративних корпусів.

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

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 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.

Ні запуску 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:

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

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

Дивіться також