Apache Tika je nástroj na parsování dokumentů od Apache Software Foundation: dáte mu soubor téměř libovolného typu a on vrátí čistý text spolu s normalizovaným slovníkem metadat. README projektu uvádí víc než tisíc podporovaných formátů a Tika toho dosahuje tak, že si potřebné specializované knihovny balí sama — PDFBox pro PDF, Apache POI pro Office dokumenty, jsoup pro HTML, čtečku ODT pro ODF — takže celé řešení přijde jako jediný fat JAR, bez nutnosti cokoli stahovat až ve chvíli parsování. V datovém pipeline je to ten nenápadný první krok: komponenta před vyhledávacím indexem, sadou pro e-discovery nebo korpusem pro LLM, která z hromady různorodých souborů udělá něco jednotného. Ve skutečnosti má dvě úlohy: zjistit, co datový proud je, a pak z něj vytáhnout text i metadata.
Je to nejméně náročný nástroj, který jsem za dlouhou dobu nastavoval. Jeden JAR, java -jar tika-app-3.3.2.jar --text file.pdf, žádný konfigurační soubor, žádné modelové váhy, žádný post-install krok, a navíc běžel bez problémů na nejnovějším JDK, které na stejném hostu toho samého odpoledne zastavilo jiné Java nástroje. Ale nechtěl jsem testovat katalogové tvrzení; zajímala mě užší, ověřitelná otázka. Co se stane, když vám vstup lže? Tak jsem připravil kontrolovanou sadu fixture: každý blok obsahu dostal unikátní značkový token, stejný logický dokument jsem vyrenderoval do devíti různých nosičových formátů a pak jsem na celý balík zaútočil špatnými příponami, chybějícími příponami, úplně bez názvu souboru, nulobajtovými soubory i napůl zapsanými binárkami.
Detekce je místo, kde se děje to zajímavé. Přejmenoval jsem PDF na .txt a zeptal se Tiky, co to je; odpověď byla application/pdf. Pak jsem smazal název souboru úplně, poslal syrová data přes stdin a dostal jsem stejnou odpověď. Ve všech pěti formátech z téhle sady, které šly detekovat podle obsahu, to platilo ve všech 20 unikátních logických podmínkách: tři stavy názvu souboru plus jeden stav bez názvu pro každý formát. Testovací harness sice spustil streamový případ třikrát pod různými štítky, takže vzniklo 30 úspěšných syrových běhů, ale tyhle opakované běhy nejsou nezávislý důkaz. PDF a RTF mají rozpoznatelné bajty; DOCX se pozná podle kontejneru; HTML a XML lze identifikovat podle značek nebo kořenového obsahu. Jiný mechanismus, stejný užitečný výsledek v téhle sadě: přípona nepřebila obsah. A pak je tu rodina textových formátů, kde Markdown spadne na text/plain ve chvíli, kdy je název souboru špatný nebo chybí úplně. Jeho identita zde stála čistě na .md.
Dvě hranice pro všechna čísla, která následují. Testoval jsem Apache Tika 3.3.2 — ověřeno 27. července 2026, že stále šlo o nejnovější stabilní vydání; větev 4.0.0 existovala na Maven Central jen jako alfa a beta buildy. Projekt měl v době kontroly zhruba 3,9 tisíce hvězdiček na GitHubu a licenci Apache-2.0, což je z pohledu komerčního použití asi tak nejméně otravné licencování, jaké můžete dostat. A OCR jsem vůbec netestoval. Ani jednu naskenovanou stránku, ani jedno PDF jen s obrázkem. Na stroji, kde jsem to spouštěl, nebyly nainstalované Tesseract ani poppler, takže každá OCR cesta byla zablokovaná už před startem. Žádná OCR čísla tu nejsou, protože žádná OCR čísla neexistují, tečka.
Co Tika je, když přestanete číst marketing na krabici
Běžná představa je, že Apache Tika je převodník dokumentů — pošlete mu DOCX a dostanete zpět čistý Markdown se zachovanými nadpisy a tabulkami. To ale není ono a čím dřív je to jasné, tím lépe ten nástroj působí.
Cesta, kterou jsem testoval, má tři relevantní fáze: detektor typu obsahu, dispatcher, který předá data správnému parseru, a výstupní handler CLI --text, který vedle samostatně dostupných metadat vrací plochý text. V tomhle výstupním kontraktu nejsou žádné objekty Title, žádné ListItem ani znovu složená tabulková mřížka. Tika ale nabízí i jiné handlery a API, včetně výstupu orientovaného na XHTML/SAX; ty jsem netestoval. Všechna níže uvedená tvrzení o struktuře se proto týkají jen tika-app --text, ne tvrzení, že toolkit nikde neumí strukturovaný proud událostí.
To zní jako omezení, a v jedné rovině to omezení opravdu je. Jenže zároveň to znamená, že Tika nemá co špatně klasifikovat, a přesně to je obchod, který její hlučnější sourozenci dělají opačným směrem.
Samotná detekce běží v dokumentovaném pořadí: nejdřív podpisové bajty, pak kontrola XML rootu, potom glob názvu souboru a nakonec typ, který jste zadali sami (dokumentace detekce od Tiky to takhle popisuje). Teprve když je typ určen, dispatcher předá data odpovídajícímu zabalenému parseru — PDFBox, POI, jsoup, TextAndCSVParser pro textovou rodinu.
To rozdělení na detekci a parsování není jen interní drobnost. Právě proto může soubor, který je příliš poškozený na parsování, být přesto správně určený podle typu. A to je v praxi nejzajímavější trik, který Tika nabízí ve chvíli, kdy se věci začnou kazit.
Nastavení: jeden JAR, jeden příkaz a JVM, kterou nic nerozhodí
Instalace je download. tika-app-3.3.2.jar z Maven Central má asi 67 MB — je to fat JAR s každým parserem uvnitř — a potom už stačí java -jar tika-app-3.3.2.jar --text file.pdf. Žádný konfigurační soubor, žádné modelové váhy, žádný post-install krok, žádný řetězec brew install, který byste museli rozmotávat.
Překvapil mě příběh s JDK. Celé jsem to spustil na OpenJDK 26.0.1, tedy na nejnovější nelong-term build, a --version, --text, --metadata i --detect všechny vrátily exit 0 bez jakýchkoli kompatibilitních poznámek. To stojí za zmínku, protože jsem ve stejný den na stejném hostu zkoušel i Apache Nutch a jeho crawl cyklus na JDK 26 vůbec neběžel — kvůli odstranění SecurityManageru v novějších JDK potřebuje LTS na úrovni 21 nebo níže. Tice to bylo jedno. Pokud se JVM nástrojům vyhýbáte kvůli tomuhle konkrétnímu typu bolesti, Tika není místo, kde vás dožene.
K nastavení mám ale i dvě poctivé výhrady. CLI spouští při každém volání novou JVM, takže cold start je reálný — 131 invokací v mém harnessu trvalo asi minutu, většinou kvůli rozběhu JVM. Když zpracováváte soubory ve velkém, chcete knihovnu nebo server mode, ne shellový cyklus nad JARem. A příběh bez závislostí má tvrdý okraj: exktrakce textové vrstvy z PDF nepotřebuje nic externího, ale OCR potřebuje tesseract a poppler. PDF s textovou vrstvou, DOCX, ODT, RTF, HTML, XML, TXT, Markdown i CSV se na hostu bez těchto binárek parsovaly bez problémů. Naskenované dokumenty by neprošly a já jsem to ani nezkoušel předstírat.
Ten kontrast je ještě ostřejší ve srovnání se sesterskou knihovnou unstructured, kterou jsem testoval tentýž den: její cesta pro elektronická PDF byla úplně zablokovaná, protože import PDF modulu při načtení sahá na inference stack (torch a spol.) — ještě před dispatch strategií, takže se bez toho neimportuje ani „rychlá“ strategie. Tika stejné PDF s textovou vrstvou parsovala obyčejným java -jar.
Test lživých přípon: detekce MIME typu ignoruje, jak jste soubor pojmenovali
Osm formátů, každý ve variantě se správnou příponou, s úmyslně špatnou příponou nebo bez přípony, plus proud bajtů bez názvu na stdin. To je 32 unikátních logických podmínek. Původní harness navíc spouštěl stejné syrové bajty jednou pod každým názvem souboru, takže vzniklo 48 syrových běhů; tři streamové řádky se ale skládají do jedné podmínky, protože stdin žádný název souboru nenese.
| Fixture | Skutečný typ | Přejmenováno na | Správná přípona | Lživá přípona | Bez přípony | Syrový stream, bez názvu souboru |
|---|---|---|---|---|---|---|
application/pdf | .txt | ✅ | ✅ | ✅ | ✅ | |
| DOCX | OOXML wordprocessingml | .jpg | ✅ | ✅ | ✅ | ✅ |
| RTF | application/rtf | .html | ✅ | ✅ | ✅ | ✅ |
| HTML | text/html | .csv | ✅ | ✅ | ✅ | ✅ |
| XML | application/xml | .txt | ✅ | ✅ | ✅ | ✅ |
| Prostý text | text/plain | .pdf | ✅ | ✅ | ✅ | ✅ |
| Markdown | text/markdown | .pdf | ✅ | ❌ text/plain | ❌ text/plain | ❌ text/plain |
| CSV | text/csv | .txt | ✅ | ❌ text/plain | ❌ text/plain | ❌ text/plain |
(Streamový sloupec sjednocuje všechny tři případy s různou příponou, protože bez názvu souboru není co číst globem.)
Pět formátů detekovatelných podle obsahu — PDF, DOCX, RTF, HTML a XML — trefilo správný typ ve 20 z 20 unikátních podmínek (a ve 30 z 30 syrových běhů harnessu, včetně duplikovaných streamových spuštění). PDF pojmenované report.txt zůstalo PDF. DOCX pojmenované photo.jpg zůstalo DOCX. Ani jeden z nich název souboru nepotřeboval. To neznamená, že všech pět používá pevné podpisové bajty: PDF a RTF mají rozpoznatelné hlavičky, DOCX je ZIPový kontejner a HTML/XML se poznají podle značek nebo kořenového obsahu. Jiný mechanismus, stejný užitečný výsledek. V téhle sadě lživá přípona nevyhrála.
Pak je tu režim textových formátů. Markdown se jako text/markdown rozpoznal jen tehdy, když byla přítomná a čitelná přípona .md. Když ho přejmenujete, odstraníte příponu nebo pošlete jako stream, v tomhle testu spadl na text/plain. CSV se v téhle záměrně malé mřížce chovalo stejně: text/csv přišlo jen z globu .csv. Při počítání unikátních podmínek se Markdown i CSV jako specifický typ objevily jen v jedné ze čtyř podmínek; prostý text už byl text/plain, takže z čeho „padat“ neměl. Syrový 48běhový harness zůstává užitečný jako záznam opakovatelnosti, ale ne jako větší jmenovatel.
Jeden detail hraje Tice do karet: lživá přípona také nevyhrává. Můj Markdown fixture přejmenovaný na .pdf se vrátil jako text/plain, ne jako application/pdf. Tika lži nevěřila, jen nedokázala pravdu potvrdit. Přechod na nadřazený typ je mnohem lepší selhání než sebejisté tvrzení něčeho špatného a to, že text/markdown je v dokumentaci podtyp text/plain, dává tomuto fallbacku jasný smysl.
U CSV je ale jedna důležitá výjimka. Tika má statistický CSV detektor a při parsování — potvrzeno tím, že se TextAndCSVParser objevil v řetězci X-TIKA:Parsed-By — se můj malý grid 2 sloupce × 3 řádky vyhodnotil jako text/plain, nikoli text/csv. To je jediný pozorovaný případ na záměrně minimální sadě. Větší nebo uvozkované CSV může detektor klidně aktivovat. Netvrdím, že detekce CSV podle obsahu je rozbitá; tvrdím, že na téhle mřížce byla přípona tím, co dalo vzniknout text/csv.
Proč na tom záleží v reálném upload pipeline
Konkrétní scénář je router nahrávaných souborů. Předpokládejme, že přijímáte uploady od uživatelů a směrujete je podle typu: PDF do parseru faktur, tabulky do importéru účetnictví, všechno ostatní do textového indexu. Pokud věříte příponě, PDF přejmenované na notes.txt skončí ve špatné větvi — a to je ještě benigní případ; nepřátelská verze je polyglot soubor s „přátelskou“ příponou.
U binárních a značkovacích fixture z tohohle testu Tika směrovala podle obsahu i poté, co název souboru zmizel, což je užitečné, když blob storage nebo handler HTTP body název zahodí. Ten výsledek ale nepokrývá dlouhý ocas Tiky, nejednoznačné soubory ani polygloty. Testované textové formáty se chovaly jinak: když pipeline názvy souborů odstranila, Markdown i CSV přišly jako text/plain, takže pravidla navázaná na jejich konkrétní MIME typ přestala fungovat. Zachovejte původní název jako doprovodné metadata, nečekejte, že ho detekce obsahu rekonstruuje.
Planted obsah přežil. --text ale strukturu zploštil.
Druhý rozměr je fidelity a ten se dělí čistě na dvě části. Jeden kanonický dokument (nadpisy, dva odstavce těla, odrážkový seznam, číslovaný seznam, závěrečný odstavec) jsem vyrenderoval do HTML, Markdownu, prostého textu, DOCX, PDF, RTF, ODT a XML, plus jeden tabulkový dokument do HTML, Markdownu, textu, DOCX, CSV a XML. Čtrnáct nosičových renderů. Každý blok má jedinečný token — zztitle1, zzitem3, zztblcell_beta a podobně — takže „přežil“ versus „zmizel“ je přesná kontrola substringu, ne subjektivní dojem.
Recall značkových tokenů vyšel 1.000 u všech čtrnácti renderů. Nezmizel jediný planted token: každá označená tabulková buňka, položka seznamu i nadpis byla přítomná. Tři lokální opakování po zahřátí pro každý nosič vrátila byte-identický výstup --text. Tenhle oracle ale neříká nic o neoznačených znacích, pořadí, mezerách, normalizaci Unicode, opakovaném obsahu, odkazech, hlavičkách, poznámkách pod čarou ani vložených objektech. Je to kontrola přítomnosti bloků, ne důkaz úplné věrnosti dokumentu.
Plochý textový výstup se vzdává většiny zdrojové struktury.
Takhle vypadá HTML tabulkový dokument po --text:
Tool Throughput
zztblcell_alpha 120
zztblcell_beta 95
Řádky oddělené tabulátory. Hlavičkový řádek není označený jako hlavička. Žádná mřížka, žádné hranice buněk kromě tabulátoru, žádný způsob, jak poznat, že to kdy byla <table>. DOCX tabulka se zploští úplně stejně.
Seznamy jsou trochu jemnější a rozdělují se podle toho, co ve zdroji skutečně bylo:
| Co byl odrážkový znak ve zdroji | Nosiče | Co vrací --text |
|---|---|---|
Doslovný znak — všechny tyto rendery zapsaly - jako normální text | prostý text, Markdown, RTF, ODT, PDF | - zůstane, protože Tika předává znaky dál |
Skutečná struktura — HTML <li>, DOCX styl List Bullet | HTML, DOCX | značka úplně zmizí a dostanete jen text položky: v HTML odsazený tabem, v DOCX obyčejný řádek bez ozdob |
Tika nikdy nepřekreslí značku, kterou nedostala jako text. Stejný obsah, jinak vypadající výstup.
Markdownový případ to ukazuje úplně jasně. Když Tice dáte .md soubor s pipe tabulkou, pipe znaky se vrátí doslova, což vypadá jako zachování struktury. Ale není. Tika to prostě parsovala jako text a vrátila bajty zpět. Nic nerozumělo tomu, že šlo o tabulku.
Takže měřený kontrakt je užší: všechny planted markery přežily, ale --text nezachoval typované elementy ani rekonstruovatelnou mřížku tabulky. Nazývat to vadou parseru by minulo pointu. Plochá extrakce se záměrně vyhýbá problému klasifikace elementů; zároveň ale nemůže uspokojit downstream spotřebitele, který tyto typy potřebuje. Pokud chcete typované bloky nebo znovu složené tabulky, --text je jen jedna komponenta stacku, ne celý stack. Jiné handlery Tiky mohou odhalit více struktury, ale ty mimo tenhle běh byly mimo záběr.
Obvyklá výhrada ke všem číslům fidelity tady: pocházejí z řízených syntetických fixture na jednom stroji, jedné verzi a jednom JDK. Ukazují, že označené bloky byly ve výstupu přítomné. Neprokazují znak po znaku přesnost ani správnost na chaotickém reálném korpusu.
Metadata: normalizovaná a příjemně neochotná si něco vymýšlet
Do každého nosiče, který má metadata vrstvu, jsem vložil známé hodnoty author, title a creation-date a pak jsem kontroloval, co se vrátilo.
| Nosič | author → dc:creator | title → dc:title | created → dcterms:created |
|---|---|---|---|
HTML (<meta name=author>, <title>) | ✅ | ✅ | neuloženo v metadatech |
| DOCX (core properties) | ✅ | ✅ | ✅ přesně 2021-03-15T09:30:00Z |
| PDF (info dict) | ✅ | ✅ | přítomno, ale šlo o časové razítko generátoru — nehodnoceno |
ODT (meta.xml) | ✅ | ✅ | ✅ přesně 2021-03-15T09:30:00Z |
| TXT / MD / CSV / RTF / XML | žádná metadata vrstva | — | — |
Author i title byly obnoveny na 4 ze 4 nosičů s metadatovou vrstvou a — to je ta důležitá část — jsou normalizované. HTML <meta name="author">, DOCX core property, PDF položka /Author i ODT prvek dc:creator dorazí pod stejným klíčem dc:creator. Nepíšete čtyři consumer aplikace, ale jednu.
created je poctivé zakolísání. DOCX a ODT vrátily přesně můj vložený timestamp z roku 2021. PDF vrátilo datum vytvoření, ale šlo o datum, které do něj při buildu otiskla moje generující knihovna, ne o hodnotu, kterou jsem chtěl vložit — takže ho hodnotím jako přítomné, ne obnovené. A formáty bez metadata vrstvy nevrátily nic, což je správná odpověď. Tika si autorství z textového těla nevymýšlí.
Schválně rozbité soubory a z toho plynoucí trik na triage
Čtyři nepřátelské vstupy. Nulobajtový soubor. Platné PDF záhlaví, ale tělo uříznuté. Zkrácený ZIP s DOCX. A UTF-8 soubor s vícibajtovými znaky, bez BOM a bez deklarace kódování. To jsou lokální tvary fixture, ne prahy Tiky.
Podkladový harness, vygenerované fixture, syrové JSONy, checksum JARu a manifest prostředí tady veřejně neodkazuji, takže externí čtenář nemůže nezávisle reprodukovat přesné jmenovatele. Berte tabulky jako hlášená pozorování, ne jako důkaz ověřitelný třetí stranou.
| Vstup | --text / --json | Co to vyhodilo | --detect |
|---|---|---|---|
| Nulobajtový soubor | exit 1, prázdný stdout | ZeroByteFileException: InputStream must have > 0 bytes | exit 0 → text/plain s názvem souboru, application/octet-stream ze streamu |
| Zkrácené PDF | exit 1, prázdný stdout | TikaException: TIKA-198: Illegal IOException from PDFParser | exit 0 → application/pdf |
| Zkrácený DOCX | exit 1, prázdný stdout | POI FATAL: "XML document structures must start and end within the same entity" | exit 0 → typ OOXML |
| UTF-8, bez BOM, bez deklarace | exit 0 | nic | exit 0 → text/plain, charset UTF-8 |
Extrakce selhává nahlas a tato selhání mají stejný vnější tvar. Nulobajtový soubor, zkrácené PDF i zkrácený DOCX skončily výjimkou, exitem 1 a prázdným stdout. CLI selhání neschová do elegantního prázdného výsledku. Z pohledu procesu bezpečné chování — žádný hang, žádný segfault — ale volající musí kontrolovat exit status a stderr, ne jen prázdný řetězec.
Detekce je oddělená od parsování. U obou zkrácených binárek --detect vrátil exit 0 s očekávaným typem z nepoškozeného úvodního obsahu; parser pak selhal na rozbitém těle. Pipeline tedy může použít detekci jako samostatný triage signál před parsem nebo po něm. Zda je detect-first dobrý výchozí režim, závisí na nasazení: tenhle test nebenchmarkoval detect-first proti parse-only a dvě nové CLI JVM by při velkém objemu mohly být špatný obchod.
Detekce kódování funguje. UTF-8 soubor bez BOM a bez deklarace byl dekódován jako UTF-8 a 日本語テスト prošlo beze změny. Malá poznámka pro každého, kdo čte metadata slovníky: mé čistě ASCII fixture hlásí charset=ISO-8859-1, což je na ASCII bajtech od UTF-8 nerozeznatelné. To není chyba, to je remíza.
Tika vedle unstructured: stejné typy souborů, jiná práce
Oba nástroje jsem zkoušel ve stejné výzkumné session, ale tohle je taxonomie výstupních kontraktů, ne symetrický benchmark. Nástroje byly hodnoceny podle různých výsledků.
Související recenze: Recenze Unstructured.
| Apache Tika | unstructured | |
|---|---|---|
| Na čem jsem to měřil | věrnost obsahu: něco se neztratilo? | věrnost klasifikace elementů: měl každý blok správný typ? |
| Výsledek | všechny planted markery byly přítomné ve všech čtrnácti renderech | v samostatném klasifikačním testu měla prostá textová tabulka recall Table 0.000 a jeden nadpis s přítomným slovesem byl klasifikován jako narativní text |
| Vrácené typované elementy | žádné — struktura se nevrátila | Title, NarrativeText, ListItem, Table — přesně to, co Tika odmítá dělat |
| OCR | blokováno na mém hostu, chyběl tesseract | blokováno na mém hostu, chyběl tesseract |
Plochý výstup, který zachovává markery, versus typované elementy s pozorovanými chybami klasifikace. Vyberte podle toho, co downstream spotřebitel potřebuje. Pokud jde o vyhledávací index nebo kontextové okno LLM, může stačit plochý text. Pokud závisí na typu elementu, cesta --text v Tice tenhle kontrakt dodat neumí.
Naskenované dokumenty nemá ani jeden z nás změřené.
Klady a zápory
Klady
- Detekce typu obsahu ignorovala lživé názvy souborů v 20/20 unikátních podmínkách napříč pěti formáty detekovatelnými podle obsahu; souhlasily i duplicitní streamové běhy.
- Ve všech 14 nosičových renderech přežil každý planted marker, včetně označených tabulkových buněk a položek seznamu.
- Opakovatelné ve třech lokálních rerunech: každý nosič vrátil v tomto prostředí byte-identický text.
- Metadata byla napříč formáty normalizovaná —
dc:creator/dc:title/dcterms:createdbez ohledu na zdrojový formát, obnovená na 4/4 nosičích s metadaty. - Skutečně bez závislostí pro formáty, které jsem testoval: PDF textová vrstva, DOCX, ODT, RTF, HTML se parsují z jednoho JARu bez externích binárek.
- Na OpenJDK 26 běží bez problémů — žádný limit jen na LTS.
- Detekce zůstává správná (exit 0) i na zkrácených binárkách, takže při selhání parsování dostanete spolehlivý triage signál.
- Apache-2.0, zralé, aktivně udržované.
Zápory
- Identita Markdownu a CSV závisí výhradně na příponě; 10 z 18 buněk bez podpisu spadlo na
text/plain, jakmile název souboru chyběl nebo byl špatný. --textnevrací typované elementy; tabulky se zploštily na řádky oddělené tabulátory a strukturální značky seznamů zmizely.- Exktrakce na prázdných a poškozených vstupech hází neodchycenou chybu; oba případy vypadají z pohledu samotného extraction call stejně.
- JAR má 67 MB a v CLI režimu při každém spuštění probíhá cold start JVM.
- OCR a PDF ze skenů tady nebyly vůbec testovány — tesseract ani poppler nebyly přítomné, takže o téhle cestě nepadá žádné tvrzení.
- Každé číslo v tomhle textu je syntetická ground truth na jednom stroji, jedné verzi. Přesnost na reálném korpusu, šifrované soubory, vnořené/rekurzivní dokumenty a výkon ve velkém měřítku měřeny nebyly.
Pro koho se hodí a pro koho ne
Tika dává smysl, když jsou vaším vstupem souborové dokumenty, které už máte, a výstupem má být text plus metadata, která může stroj indexovat. Vyhledávací indexace, e-discovery, zpracování archivu, krmení korpusu pro LLM, budování vrstvy validace typu obsahu v upload pipeline. Hodí se jako první triage a normalizační krok před něčím chytřejším: detekovat testované typy, vytáhnout plochý text a předat ho dál s explicitními kontrolami pro obsah, který si pipeline nemůže dovolit ztratit.
Vynechte ji — nebo přesněji, nezůstávejte u --text — pokud potřebujete typované elementy, rekonstruované tabulky nebo rozvržení dokumentu. Vynechte ji, pokud jsou vaše dokumenty skeny, alespoň dokud nenainstalujete tesseract a neuděláte si vlastní měření, protože já žádná nemám. Pro objemovou práci benchmarkujte knihovnu nebo server mode proti CLI na reprezentativních dokumentech. Spuštění procesu bylo v tomhle malém harnessu viditelné, ale throughput ani náklady na zdroje změřeny nebyly.
A jedna věc, která lidi často nachytá: pokud vám storage vrstva odstraňuje názvy souborů a pracujete s Markdownem nebo CSV, nespoléhejte na to, že je Tika rozliší od prostého textu. Původní název si ponechte.
Alternativy a kde stojí Thunderbit
Nejdřív férové vymezení, protože poctivé srovnání je tady hlavně o vstupech, ne o kvalitě. Tika je zdarma, Apache-2.0, self-hosted toolkit pro parsování souborů. Souborů, které už máte na disku nebo v bucketu. Nestahuje stránky, nespouští JavaScript, neřeší anti-bot ochrany a nepředstírá, že ano.
To je hranice, kde může do architektury vstoupit spravovaná služba pro web extraction, včetně naší Thunderbit: ta stahuje živé stránky, zatímco Tika parsuje soubory, které už máte v držení. Tenhle článek tyhle služby proti Tice nebenchmarkoval a nejsou to náhrady pro stejný vstup.
Čisté rozdělení: Tika pro dokumenty, které už máte, spravované extraction API pro webové stránky, které si musíte teprve vzít. Mnoho pipeline používá obojí — crawl a extrakci na webu a Tiku pro PDF a DOCX přílohy, které se vrátí zpět.
Pokud srovnáváte širší open-source pole, sepsal jsem úplné srovnání open-source scraperů, přehled nejužitečnějších scraping projektů na GitHubu, praktickou recenzi Crawl4AI zaměřenou na Markdown přístup s podporou prohlížeče a širší přehled scraping nástrojů. Pro no-code cestu je tu také návod, jak scrapovat web pomocí AI.
Vyzkoušejte Thunderbit pro extrakci webových dat
Verdikt
Měli byste Apache Tiku používat? Ano, pokud je vaším úkolem převádět heterogenní soubory na plochý text a normalizovaná metadata a pokud si kontrolujete pole nebo markery, které si váš vlastní pipeline nemůže dovolit ztratit.
Detektor byl nejsilnější částí tohohle běhu. Ve 20 z 20 unikátních podmínek pro pět formátů detekovatelných podle obsahu vrátil očekávaný typ, včetně streamů bez názvu souboru. Každý planted marker přežil ve čtrnácti renderech a výstup se ve třech lokálních rerunech opakoval byte po bytu. Užitečný důkaz. Pořád syntetický důkaz. To, že to běželo z jednoho JARu na tomhle JDK a bez externích binárek pro netestované OCR cesty, udělalo nasazení příjemně nudným.
Jen ji nastavte správně. Každá tabulka, kterou jí pošlete, se vrátí jako řádky oddělené tabulátory. Každá strukturální značka seznamu zmizí. Markdown a CSV ztratí identitu ve chvíli, kdy název souboru zmizí. Prázdné a poškozené soubory házejí stejný typ selhání a bez separátního volání detect je nerozlišíte. A na OCR, což je pro hodně uživatelů Tiky nejdůležitější otázka, nemám co nabídnout: nemohl jsem to spustit a nebudu odhadovat.
Uvnitř těchto hranic dělá Tika nenápadnou práci s neobvyklou spolehlivostí. Čte bajty, ne štítek na krabici. Jen se jí neptejte, jakého byly tvaru.
Vyzkoušejte Thunderbit pro extrakci webových dat Get Started Free
Často kladené otázky
Rozpozná Apache Tika typ souboru správně, i když je přípona špatně?
U pěti formátů detekovatelných podle obsahu, které jsem testoval, ano. PDF, DOCX, RTF, HTML a XML se ve všech 20 unikátních logických podmínkách (30 syrových běhů s duplicitními streamy) vyhodnotily na očekávaný MIME typ, včetně klamavých přípon, chybějících přípon i streamů bez názvu souboru. PDF pojmenované .txt se pořád detekovalo jako application/pdf. Markdown a malá CSV fixture závisely na informaci o názvu souboru a při jejím chybění nebo záměně spadly na text/plain.
Zachová Tika tabulky a strukturu dokumentu?
Ne v testovaném režimu --text. Tabulky se vrátily jako řádky oddělené tabulátory bez sémantiky buněk nebo hlaviček a strukturální značky seznamů (HTML <li>, styl List Bullet v DOCX) zmizely. Každý planted marker přežil ve všech 14 nosičových renderech, ale to neprokazuje úplnou věrnost obsahu a --text nenabízí typování elementů. Pro typované elementy nebo rekonstruované tabulky otestujte jiný výstupní handler Tiky nebo použijte jiný nástroj vedle ní.
Umí Apache Tika OCR na naskenovaných PDF? Tika podporuje OCR přes Tesseract, ale já jsem to netestoval a žádný z těchto výsledků to netvrdí. Tesseract ani poppler na mém testovacím hostu nebyly, takže každá OCR a scanned-image cesta byla zablokovaná ještě před spuštěním. V tomhle testování nejsou žádná OCR čísla. Pokud je OCR váš use case, nainstalujte tesseract a otestujte si to sami — tuhle část Tiky tu berte jako neověřenou.
Co Tika dělá s prázdnými nebo poškozenými soubory?
Selže nahlas, ne potichu. Nulobajtový soubor vyhodí ZeroByteFileException; zkrácené PDF vyhodí TikaException z PDFParseru; zkrácený DOCX vyhodí POI XML chybu. Všechny tři končí exitem 1 a prázdným stdout, takže prázdný a poškozený soubor jsou z pohledu samotného extraction callu nerozlišitelné. Detekce je ale robustní — --detect vrátil exit 0 se správným typem u obou zkrácených binárek, takže je to spolehlivý triage krok před tím, než utratíte parse.
Co testování Tiky nepokrylo? Čtyři věci, explicitně. OCR a naskenované obrazy (blokováno, netestováno). Přesnost na reálném korpusu — všechny výsledky jsou kontrolované syntetické fixture s vloženými marker tokeny, takže měří věrnost vůči známým štítkům, ne přesnost na chaotických reálných dokumentech. Náklady na zdroje, throughput a peak memory, což jsem neměřil. A dlouhý ocas tvrzení o „tisíci typech souborů“: testoval jsem devět reprezentativních formátů bez externích závislostí, ne celý katalog. Všechno tady je Tika 3.3.2 na OpenJDK 26.0.1, macOS arm64, jeden stroj.
