Recensione di Apache Tika: legge i byte, non il nome del file — finché non incontra Markdown

Apache Tika è il toolkit di Apache Software Foundation per l’analisi dei documenti: gli passi un file in quasi qualsiasi formato e lui ti restituisce testo semplice più un dizionario di metadati normalizzato. Il README del progetto dichiara più di mille tipi di file supportati, e Tika ci arriva includendo al proprio interno le librerie specialistiche — PDFBox per i PDF, Apache POI per i documenti Office, jsoup per l’HTML, un reader ODF per gli ODT — così tutto viene distribuito come un unico fat jar, senza dover scaricare altro al momento del parsing. In una pipeline dati è il primo passaggio senza gloria: il componente davanti a un indice di ricerca, a un set per e-discovery o a un corpus per LLM che trasforma un mucchio eterogeneo di file in qualcosa di uniforme. In pratica svolge due compiti: capire che cosa sia uno stream di byte, poi estrarne testo e metadati.

È lo strumento meno esigente che abbia installato da parecchio tempo. Un solo jar, java -jar tika-app-3.3.2.jar --text file.pdf, nessun file di configurazione, nessun peso di modello, nessun passaggio post-installazione, e ha funzionato senza problemi su una JDK all’avanguardia che nello stesso pomeriggio aveva bloccato altri tool Java sullo stesso host. Però non mi interessava verificare la promessa del catalogo; la domanda da testare era più precisa. Quando l’input ti racconta una bugia, cosa fa davvero Tika? Così ho creato un set di fixture controllate in cui ogni blocco di contenuto porta un token marcatore univoco, ho reso lo stesso documento logico in nove formati contenitore, poi ho attaccato il tutto con estensioni sbagliate, estensioni mancanti, nessun nome file, file a zero byte e binari scritti a metà.

Il comportamento davvero interessante sta nel rilevamento. Ho rinominato un PDF in .txt e ho chiesto a Tika cosa fosse; ha risposto application/pdf. Poi ho eliminato del tutto il nome file, ho passato i byte grezzi su stdin e ho ottenuto la stessa risposta. Sui cinque formati rilevabili tramite contenuto del mio set, questo ha retto in tutte le 20 condizioni logiche uniche: tre condizioni sul nome file più una condizione senza nome file per formato. Il harness ha eseguito il caso stream tre volte con etichette diverse, producendo 30 esecuzioni grezze riuscite, ma quelle ripetizioni non sono prove indipendenti. PDF e RTF espongono byte riconoscibili; DOCX espone il proprio contenitore; HTML e XML si possono identificare dal markup o dal contenuto radice. Meccanismi diversi, stesso risultato utile in questo set di fixture: l’estensione non ha prevalso sul contenuto. Poi c’è il regime dei formati testuali, dove Markdown scende a text/plain nel momento in cui il nome file è sbagliato o assente. Qui la sua identità dipendeva interamente da .md.

Due precisazioni valgono per ogni numero che segue. Ho testato Apache Tika 3.3.2 — verificato il 27 luglio 2026, era ancora l’ultima release stabile; la linea 4.0.0 esiste solo come build alpha e beta su Maven Central. Il progetto aveva circa 3,9k stelle su GitHub al controllo del 27 luglio 2026 ed è sotto licenza Apache-2.0, quindi praticamente la più tranquilla possibile dal punto di vista commerciale. E non ho testato affatto l’OCR. Neppure una pagina scannerizzata, neppure un PDF fatto solo di immagini. Tesseract e poppler non sono installati sulla macchina che ho usato, quindi ogni percorso OCR era bloccato prima di partire. Qui non ci sono numeri OCR, perché non ci sono numeri OCR e basta.

Cos’è Tika, una volta smesso di leggere il marketing sulla confezione

L’assunzione più comune è che Apache Tika sia un convertitore di documenti — gli dai un DOCX e ti restituisce Markdown pulito, con titoli e tabelle intatti. Non è quello, e chiarirlo subito lo fa apparire come uno strumento molto migliore.

Il percorso testato qui ha tre fasi rilevanti: un rilevatore di content type, un dispatcher che assegna i byte al parser giusto, e il gestore di output --text della CLI, che emette testo piatto con i metadati disponibili separatamente. In quel contratto di output non esistono oggetti Title, né ListItem, né una griglia tabellare ricostruita. Tika espone anche altri handler e API, incluso un output orientato a XHTML/SAX; io non li ho testati. Ogni conclusione sulla struttura qui sotto riguarda quindi tika-app --text, non è un’affermazione secondo cui il toolkit non abbia da qualche parte uno stream di eventi strutturato.

Sembra un limite, e per un verso lo è. Ma significa anche che Tika non ha nulla da classificare male, ed è esattamente il compromesso che i suoi cugini più rumorosi fanno nella direzione opposta.

Il rilevamento segue un ordine documentato: prima le signature nei byte, poi l’ispezione della root XML, poi il glob del nome file, poi l’eventuale tipo che hai fornito tu (la documentazione di Tika sul detection lo descrive così). Solo quando il tipo è risolto il dispatcher passa i byte al parser bundled corrispondente — PDFBox, POI, jsoup, TextAndCSVParser per la famiglia testuale.

Quella separazione tra detection e parsing non è un dettaglio interno. È il motivo per cui un file troppo rotto per essere parsato può comunque essere classificato correttamente, che poi diventa il trucco più utile che Tika offre quando le cose iniziano a rompersi.

Setup: un jar, un comando e una JVM che non fa storie

L’installazione è un download. tika-app-3.3.2.jar da Maven Central pesa circa 67 MB — un fat jar che incorpora ogni parser — e poi basta java -jar tika-app-3.3.2.jar --text file.pdf. Nessun file di config, nessun peso di modello, nessun passaggio post-installazione, nessuna catena di brew install da dover percorrere.

La storia della JDK mi ha sorpreso. Ho eseguito tutto su OpenJDK 26.0.1, una build non LTS all’avanguardia, e --version, --text, --metadata e --detect hanno tutte restituito exit 0 senza problemi di compatibilità. Vale la pena dirlo, perché nello stesso host e nella stessa sessione ho messo alla prova anche Apache Nutch e il suo ciclo di crawl non voleva saperne di partire su JDK 26: richiede una LTS alla 21 o inferiore, a causa della rimozione del SecurityManager nelle JDK più recenti. Tika non ha battuto ciglio. Se hai evitato gli strumenti JVM proprio per questo tipo di fastidio, Tika non è il posto in cui ti si presenta.

Due deduzioni oneste sul setup. La CLI avvia una JVM nuova a ogni invocazione, quindi il cold start si sente — 131 invocazioni per il mio harness hanno richiesto circa un minuto, quasi tutto in warmup della JVM. Se devi processare file in quantità, ti conviene usare la libreria o la modalità server, non un ciclo shell attorno al jar. E la storia del “senza dipendenze” ha un confine netto: l’estrazione del livello testo dei PDF non richiede nulla di esterno, ma l’OCR richiede tesseract e poppler. PDF con layer testuale, DOCX, ODT, RTF, HTML, XML, TXT, Markdown, CSV hanno tutti funzionato su un host dove non era installato nessuno dei due. I documenti scannerizzati non avrebbero funzionato, e non ho finto il contrario.

Il contrasto è ancora più netto rispetto alla libreria sorella che ho testato lo stesso giorno, unstructured, il cui percorso per i PDF elettronici era bloccato del tutto perché importare il modulo PDF trascina lo stack di inferenza (torch e simili) al caricamento — prima ancora del dispatch della strategia, quindi nemmeno la strategia “fast” si può importare senza quello. Tika ha estratto il layer testuale dello stesso PDF con un semplice java -jar.

Il test dell’estensione bugiarda: rilevamento MIME che ignora il nome del file

Otto formati, ciascuno presentato con un’estensione corretta, un’estensione volutamente sbagliata o nessuna estensione, più uno stream di byte senza nome su stdin. Questo fa 32 condizioni logiche uniche. Il harness originale ha anche eseguito gli stessi byte dello stream una volta per ogni etichetta di nome file, ottenendo 48 esecuzioni grezze; quelle tre righe dello stream collassano in una sola condizione perché stdin non porta un nome file.

(La colonna stream comprime tutte e tre le condizioni di estensione, perché senza nome file non c’è nulla che il glob possa leggere.)

I cinque formati rilevabili dal contenuto — PDF, DOCX, RTF, HTML e XML — hanno restituito il tipo corretto in 20 condizioni su 20 uniche (e 30 su 30 esecuzioni grezze del harness, includendo le ripetizioni dello stream). Un PDF chiamato report.txt è rimasto un PDF. Un DOCX chiamato photo.jpg è rimasto un DOCX. Nessuno dei due aveva bisogno del nome file. Questo non significa che tutti e cinque usino signature fisse nei byte: PDF e RTF hanno header riconoscibili, DOCX è un contenitore basato su ZIP, e HTML/XML vengono identificati dal markup o dal contenuto radice. In queste fixture, l’estensione bugiarda non ha vinto.

Poi c’è il regime dei formati testuali. Markdown ha risolto a text/markdown solo quando l’estensione .md era presente e leggibile. Rinominandolo, togliendo l’estensione o inviandolo come stream, in questo test è degradato a text/plain. CSV si è comportato allo stesso modo su questa griglia volutamente piccola: text/csv è arrivato solo dal glob .csv. Contando le condizioni uniche, Markdown e CSV hanno risolto al loro tipo specifico in una sola delle quattro condizioni; il testo semplice era già text/plain, quindi non c’era nulla da cui “degradare”. Il harness grezzo da 48 esecuzioni resta utile come prova di ripetibilità, ma non come denominatore più ampio.

C’è però un dettaglio che gioca a favore di Tika: nemmeno l’estensione bugiarda vince. La mia fixture Markdown rinominata in .pdf è tornata text/plain, non application/pdf. Tika non ha creduto alla bugia; semplicemente non ha potuto confermare la verità. Degradare al tipo genitore è un comportamento molto migliore rispetto ad affermare con sicurezza qualcosa di sbagliato, e il fatto che text/markdown sia un sottotipo documentato di text/plain rende questo fallback una scelta di principio, non arbitraria.

C’è però una nota specifica sul CSV. Tika dispone di un rilevatore statistico per CSV e, al momento del parsing — confermato dal fatto che TextAndCSVParser compare nella catena X-TIKA:Parsed-By — la mia griglia piccola da 2 colonne per 3 righe ha risolto a text/plain invece che a text/csv. È una singola osservazione su una fixture volutamente minimale. Un CSV più grande o con virgolette potrebbe benissimo attivare il rilevatore. Non sto dicendo che il content detection del CSV sia rotto; sto dicendo che su questa griglia è stata l’estensione a produrre text/csv.

Perché conta in una pipeline di upload reale

Lo scenario concreto è un router di upload. Supponiamo che tu accetti file caricati dagli utenti e li instradi per tipo: PDF al parser delle fatture, fogli di calcolo all’importatore del ledger, tutto il resto a un indice testuale. Se ti fidi dell’estensione, qualcuno che carica un PDF chiamato notes.txt finisce nel ramo sbagliato — e questo è il caso benigno; la versione ostile è un file poliglota con un’estensione rassicurante.

Per le fixture binarie e di markup testate qui, Tika ha instradato in base al contenuto anche dopo che il nome file era sparito, il che è utile quando un object store o un handler del body HTTP l’ha già scartato. Questo risultato non copre la coda lunga di Tika, i file ambigui o i poliglotti. Le fixture testuali della famiglia testata hanno però reagito diversamente: quando la pipeline eliminava i nomi file, Markdown e CSV arrivavano come text/plain, quindi le regole basate sui loro media type specifici smettevano di attivarsi. Conserva il nome file originale come metadato laterale, invece di aspettarti che il content detection lo ricostruisca.

Il contenuto inserito è sopravvissuto. --text ha appiattito la struttura.

La fedeltà è il secondo asse, e si divide in modo netto in due. Ho reso un documento canonico (titoli, due paragrafi del corpo, un elenco puntato, un elenco numerato, un paragrafo finale) in HTML, Markdown, testo semplice, DOCX, PDF, RTF, ODT e XML, più un documento tabellare in HTML, Markdown, testo, DOCX, CSV e XML. Quattordici renderizzazioni come formato contenitore. Ogni blocco porta un token univoco — zztitle1, zzitem3, zztblcell_beta e così via — quindi “sopravvissuto” contro “perso” è un controllo esatto di sottostringa, non una valutazione soggettiva.

Il recall dei token marcatore è tornato pari a 1.000 su tutte e quattordici le renderizzazioni. Nessun token inserito è sparito: ogni cella di tabella taggata, elemento di lista e titolo era presente. Tre ripetizioni locali per contenitore dopo il warmup hanno restituito output --text identici a livello di byte. Questo oracolo non dice nulla sui caratteri non taggati, sull’ordine, sugli spazi bianchi, sulla normalizzazione Unicode, sul contenuto ripetuto, sui link, sugli header, sulle note a piè di pagina o sugli oggetti incorporati. È un controllo di presenza dei blocchi, non una prova di fedeltà completa del documento.

L’output in testo piatto abbandona gran parte della struttura sorgente.

Ecco come esce il documento con tabella HTML da --text:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

Righe unite da tabulazioni. La riga di intestazione non viene marcata come intestazione. Non c’è una griglia, non ci sono confini di cella oltre al tab, nessun modo per capire che fosse mai stato un <table>. La tabella nel DOCX si appiattisce allo stesso modo.

Le liste sono più sottili e si dividono in base a ciò che il sorgente conteneva davvero:

Tika non reinterpreta mai un marcatore che non ha ricevuto come testo. Stesso contenuto in entrambi i casi; output dall’aspetto diverso.

Il caso Markdown chiarisce il punto in modo pulito. Dai a Tika un file .md con una tabella pipe e le pipe tornano verbatim, il che sembra preservazione della struttura. Non lo è. Tika l’ha trattato come testo e ha restituito i byte. Nessuno ha capito che si trattasse di una tabella.

Quindi il contratto misurato è più ristretto: tutti i token inseriti sono sopravvissuti, mentre --text non ha preservato gli elementi tipizzati né una griglia tabellare ricostruibile. Chiamarlo un difetto del parser perderebbe il punto. L’estrazione in testo piatto evita deliberatamente il problema della classificazione degli elementi; allo stesso tempo non può soddisfare un consumer downstream che ha bisogno di quei tipi di elementi. Se ti servono blocchi tipizzati o tabelle ricostruite, --text è un componente dello stack, non lo stack. Altri handler di Tika possono esporre più struttura, ma erano fuori da questa prova.

La solita avvertenza vale per ogni numero di fedeltà qui: provengono da fixture sintetiche controllate su una macchina, una versione, una JDK. Mostrano che i blocchi etichettati erano presenti nell’output. Non dimostrano una preservazione carattere per carattere né accuratezza su un corpus reale e disordinato.

Metadati: normalizzati, e fortunatamente poco inclini a inventare

Ho incorporato valori noti di autore, titolo e data di creazione in ogni contenitore che possiede un layer di metadati, poi ho verificato cosa tornasse indietro.

Autore e titolo sono stati recuperati su 4 contenitori con metadati su 4 e — questa è la parte importante — vengono normalizzati. Un <meta name="author"> HTML, una proprietà core di DOCX, una voce /Author nel PDF e un elemento dc:creator nell’ODT arrivano tutti sotto la stessa chiave dc:creator. Scrivi un solo consumer, non quattro.

created è la lieve oscillazione onesta. DOCX e ODT hanno restituito il mio timestamp incorporato esatto del 2021. Il PDF ha restituito una data di creazione, ma era la data impressa dalla libreria generatrice al momento della build, non il valore che intendevo incorporare — quindi lo considero presente, non recuperato. E i formati senza layer di metadati non hanno esposto nulla, che è la risposta corretta. Tika non si inventa un autore dal corpo del testo.

Romperlo di proposito, e il trucco di triage che ne deriva

Quattro input ostili. Un file a zero byte. Un PDF valido con il corpo troncato. Uno ZIP DOCX troncato. E un file UTF-8 con caratteri multibyte, senza BOM e senza dichiarazione di encoding. Si tratta di forme di fixture locali, non di soglie di Tika.

Il harness sottostante, le fixture generate, il JSON grezzo, il checksum del jar e il manifest dell’ambiente non sono collegati in questa bozza. Un lettore esterno quindi non può ancora riprodurre in modo indipendente i denominatori esatti. Considera le tabelle come osservazioni riportate; per la pubblicazione bisogna allegare un bundle stabile prima di usare questi numeri come prova di terze parti.

L’estrazione fallisce in modo rumoroso, e questi errori condividono la stessa forma esterna. Il file a zero byte, il PDF troncato e il DOCX troncato hanno tutti prodotto un’eccezione, exit 1 e stdout vuoto. La CLI non ingoia il fallimento trasformandolo in un risultato vuoto e pulito. Sicuro dal punto di vista del processo in questi casi — nessun hang, nessun segfault — ma il chiamante deve controllare exit status e stderr, non limitarsi a guardare una stringa vuota.

La detection è separata dal parsing. Su entrambi i binari troncati, --detect ha restituito exit 0 con il tipo atteso dal contenuto iniziale intatto; poi il parser è fallito sul corpo rotto. Una pipeline può quindi usare la detection come segnale di triage separato, prima o dopo un parsing fallito. Se convenga fare detection prima dipende dalla modalità di deployment: questo test non ha confrontato detect-first e parse-only, e due JVM fresh da CLI potrebbero essere il compromesso sbagliato su scala.

Il rilevamento della charset funziona. Il file UTF-8 senza BOM e senza dichiarazione è stato decodificato come UTF-8 e 日本語テスト è passato intatto. Piccola nota per chi legge i dizionari di metadati: le mie fixture puramente ASCII riportano charset=ISO-8859-1, che sugli byte ASCII è indistinguibile da UTF-8. Non è una mancata rilevazione, è un pareggio.

Tika a confronto con unstructured: stessi tipi di file, lavori diversi

Li ho usati entrambi nella stessa sessione di ricerca, ma questa è una tassonomia dei contratti di output, non un benchmark simmetrico. Gli strumenti sono stati valutati su risultati diversi.

Recensione correlata: recensione di Unstructured.

Output piatto che preserva i marker contro elementi tipizzati con errori di classificazione osservati. Scegli in base a ciò che serve al consumer downstream. Se è un indice di ricerca o una finestra di contesto per LLM, il testo piatto può bastare. Se si basa sul tipo di elemento, il percorso --text di Tika non può fornire quel contratto.

Nessuno dei due ha numeri su documenti scannerizzati.

Pro e contro

Pro

• Il content-type detection ha ignorato i nomi file bugiardi in 20/20 condizioni uniche sui cinque fixture rilevabili dal contenuto; anche le esecuzioni duplicate dello stream concordavano.
• Ogni marcatore inserito è sopravvissuto in tutte e 14 le renderizzazioni dei contenitori, comprese le celle di tabella e gli elementi di lista etichettati.
• Ripetibile in tre riesecuzioni locali: ogni contenitore ha restituito testo identico a livello di byte in questo ambiente.
• Metadati normalizzati tra i formati — dc:creator / dc:title / dcterms:created indipendentemente dal formato sorgente, recuperati su 4/4 contenitori con metadati.
• Davvero senza dipendenze per i formati testati: layer testo dei PDF, DOCX, ODT, RTF, HTML parse da un solo jar senza binari esterni.
• Funziona bene su OpenJDK 26 — nessun vincolo solo LTS.
• La detection resta corretta (exit 0) anche sui binari troncati, offrendo un segnale di triage affidabile quando il parsing fallisce.
• Apache-2.0, maturo, mantenuto attivamente.

Contro

• L’identità di Markdown e CSV dipende interamente dall’estensione del file; 10 celle su 18 senza signature sono collassate a text/plain quando il nome file mancava o era sbagliato.
• --text non restituisce tipi di elemento; le griglie tabellari si appiattiscono in righe unite da tabulazioni e i marcatori strutturali delle liste spariscono.
• L’estrazione lancia eccezioni non gestite su input vuoti e corrotti; i due casi appaiono identici osservando solo la chiamata di estrazione.
• Jar da 67 MB più un cold start della JVM a ogni invocazione in modalità CLI.
• OCR e PDF scannerizzati non sono stati affatto testati qui — tesseract e poppler non erano presenti, quindi non faccio alcuna affermazione su quel percorso.
• Ogni numero qui è ground truth sintetico su una macchina, una versione. Accuratezza su corpus reale, file cifrati, documenti annidati/ricorsivi e throughput su larga scala non sono stati misurati.

Chi dovrebbe usarlo, e chi no

Tika è adatto quando il tuo input sono file che hai già e l’output richiesto è testo più metadati che una macchina possa indicizzare. Indicizzazione per la ricerca, e-discovery, elaborazione di archivi, alimentazione di un corpus per LLM, costruzione del livello di validazione content-type di una pipeline di upload. È utile come primo passaggio di triage e normalizzazione davanti a qualcosa di più intelligente: rilevare i tipi testati, estrarre testo piatto e passarlo avanti con controlli espliciti su ciò che la tua pipeline non può permettersi di perdere.

Evitalo — o meglio, non fermarti a --text — se ti servono elementi tipizzati, tabelle ricostruite o il layout del documento. Evitalo se i documenti sono scansioni, almeno finché non avrai installato tesseract e fatto i tuoi numeri, perché io non ne ho. Per lavori su grandi volumi, fai un benchmark della libreria o della modalità server rispetto alla CLI su documenti rappresentativi. Lo startup del processo era evidente in questo harness su file piccoli, ma throughput e costo in risorse non sono stati misurati.

La trappola più comune: se il tuo layer di storage rimuove i nomi file e gestisci Markdown o CSV, non affidarti a Tika per distinguerli dal testo semplice. Conserva il nome originale.

Alternative, e dove si colloca Thunderbit

Prima un inquadramento corretto, perché qui il confronto onesto riguarda gli input, non la qualità. Tika è un toolkit gratuito, Apache-2.0 e self-hosted per parsare file. File che hai su disco o in un bucket. Non recupera pagine, non esegue JavaScript, non gestisce anti-bot e non finge di farlo.

È proprio quel confine che permette a un servizio gestito di estrazione web, incluso il nostro Thunderbit, di entrare nell’architettura: recupera pagine live, mentre Tika analizza file già in tuo possesso. Questo articolo non ha messo a confronto quei servizi con Tika, e non sono sostituti per lo stesso input.

La separazione pulita è questa: Tika per i documenti già in tuo possesso, un’API di estrazione gestita per le pagine web che devi andare a prendere. Molte pipeline usano entrambi — crawling ed estrazione sul lato web, Tika sugli allegati PDF e DOCX che tornano indietro.

Se stai valutando il panorama open source più ampio, ho scritto il confronto completo degli scraper open source, una rassegna dei progetti di web scraping più utili su GitHub, una recensione pratica di Crawl4AI che copre l’approccio Markdown basato sul browser, e un riepilogo più ampio degli strumenti di scraping. Per il percorso no-code c’è anche una guida su come scrapare un sito usando l’AI.

Prova Thunderbit per l’estrazione di dati web

Verdetto

Conviene usare Apache Tika? Sì, se il tuo lavoro consiste nel trasformare file eterogenei in testo piatto e metadati normalizzati, e se convalidi i campi o i marcatori che la tua pipeline non può permettersi di perdere.

La parte migliore di questa prova è stata il rilevatore. Ha restituito il tipo atteso in 20 condizioni uniche su 20 per i cinque fixture rilevabili dal contenuto, compresi gli stream senza nome file. Ogni marcatore inserito è sopravvissuto in tutte e quattordici le renderizzazioni, e l’output si è ripetuto byte per byte in tre riesecuzioni locali. Prove utili. Rimangono però prove sintetiche. Farlo da un solo jar su questa JDK, senza binari esterni per i percorsi non OCR testati, ha mantenuto il deployment piacevolmente noioso.

Va però dimensionato correttamente. Ogni tabella che gli passi ritorna come righe unite da tabulazioni. Ogni marcatore strutturale delle liste scompare. Markdown e CSV perdono la loro identità appena il nome file viene meno. I file vuoti e quelli corrotti generano la stessa forma di errore, e per distinguerli servirà una chiamata detect separata. E sull’OCR, la domanda che molti utenti di Tika considerano la più importante, non ho nulla da offrire: non ho potuto eseguirlo e non voglio fare stime.

Dentro questi limiti, Tika fa un lavoro poco appariscente con una affidabilità insolita. Legge i byte, non l’etichetta sulla scatola. Basta non chiedergli che forma avessero quei byte.

Prova Thunderbit per l’estrazione di dati web Get Started Free

FAQ

Apache Tika rileva correttamente i tipi di file se l’estensione è sbagliata? Per i cinque fixture rilevabili dal contenuto testati qui, sì. PDF, DOCX, RTF, HTML e XML hanno risolto al tipo media atteso in tutte le 20 condizioni logiche uniche (30 esecuzioni grezze con stream duplicati), comprese estensioni fuorvianti, assenza di estensione e stream senza nome file. Un PDF chiamato .txt è stato comunque rilevato come application/pdf. Markdown e la piccola fixture CSV dipendevano dalle informazioni sul nome file e sono degradati a text/plain quando mancavano o erano sbagliate.

Tika preserva tabelle e struttura del documento? Non nella modalità --text testata qui. Le griglie tabellari sono tornate come righe unite da tabulazioni, senza semantica di celle o intestazioni, e i marcatori strutturali delle liste (un <li> HTML, uno stile DOCX List Bullet) sono scomparsi. Tutti i marcatori inseriti sono sopravvissuti in tutte e 14 le renderizzazioni dei contenitori, ma questo non prova una fedeltà completa del contenuto, e --text non fornisce alcuna tipizzazione degli elementi. Per elementi tipizzati o tabelle ricostruite, prova un altro handler di output di Tika o usa un altro strumento insieme a esso.

Apache Tika può fare OCR sui PDF scannerizzati? Tika supporta l’OCR tramite Tesseract, ma non l’ho testato e nessuno di questi risultati riguarda quel caso. Tesseract e poppler non erano presenti sul mio host di test, quindi ogni percorso OCR e per immagini scannerizzate era bloccato prima ancora di partire. In questo test non esiste alcun numero OCR. Se il tuo caso d’uso è l’OCR, installa tesseract e fai tu stesso il benchmark: considera quella parte di Tika come non verificata qui.

Cosa fa Tika con file vuoti o corrotti? Fallisce in modo esplicito, non silenzioso. Un file da 0 byte genera ZeroByteFileException; un PDF troncato genera una TikaException da PDFParser; un DOCX troncato genera un errore XML di POI. Tutti e tre escono con 1 e stdout vuoto, quindi il vuoto e il corrotto sono indistinguibili osservando solo la chiamata di estrazione. La detection, invece, resta robusta — --detect ha restituito exit 0 con il tipo corretto su entrambi i binari troncati, rendendola un passaggio di triage affidabile prima di spendere tempo nel parsing.

Cosa non ha coperto il test di Tika? Quattro cose, esplicitamente. OCR e immagini scannerizzate (bloccati, non testati). Accuratezza su corpus reale — tutti i risultati sono fixture sintetiche controllate con token marcatore inseriti, quindi misurano la fedeltà rispetto a etichette note e non l’accuratezza su documenti reali e disordinati. Costo in risorse, throughput e memoria massima, che non ho misurato. E la coda lunga della promessa dei “mille tipi di file”: ho testato nove formati rappresentativi e privi di dipendenze, non il catalogo completo. Tutto qui è Tika 3.3.2 su OpenJDK 26.0.1, macOS arm64, su una singola macchina.