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 e l’estrazione di documenti: gli passi un file praticamente di qualunque tipo e lui ti restituisce testo semplice più un dizionario di metadati normalizzati. Il README del progetto parla di oltre mille formati supportati, e Tika ci arriva includendo direttamente 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 nulla al momento del parsing. In una pipeline dati è il primo stadio, poco appariscente ma fondamentale: il componente davanti a un indice di ricerca, a un set per e-discovery o a un corpus per LLM, che trasforma una massa eterogenea di file in qualcosa di uniforme. In pratica fa due cose: capisce cosa sia uno stream di byte, poi ne estrae testo e metadati.

È uno degli strumenti meno esigenti che abbia messo in piedi da parecchio tempo. Un solo jar, java -jar tika-app-3.3.2.jar --text file.pdf, niente file di configurazione, niente pesi di modello, nessun passaggio post-installazione, e ha girato senza problemi su un JDK all’avanguardia che lo stesso pomeriggio aveva mandato in stallo altri strumenti Java sullo stesso host. Però non era questa la parte che volevo testare; la domanda davvero verificabile è più ristretta. Quando l’input ti mente, cosa fa davvero Tika? Così ho costruito 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 diversi, poi ho aggredito il tutto con estensioni sbagliate, estensioni mancanti, nessun nome file, file a zero byte e binari tagliati a metà.

Il comportamento interessante sta nel rilevamento. Ho rinominato un PDF in .txt e ho chiesto a Tika che 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 di questo set rilevabili dal contenuto, il risultato è rimasto vero in tutte le 20 condizioni logiche uniche: tre condizioni basate sul nome file più una condizione senza nome file per ogni formato. Il harness ha eseguito il caso stream tre volte con etichette diverse, producendo 30 run grezze riuscite, ma quelle ripetizioni non sono prove indipendenti. PDF e RTF espongono byte riconoscibili; DOCX espone il suo contenitore; HTML e XML si possono identificare dal markup o dal contenuto della root. 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 scivola a text/plain nel momento in cui il nome file è sbagliato o assente. In questo caso la sua identità dipendeva interamente da .md.

Due precisazioni valide per tutti i numeri che seguono. 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 era intorno alle 3,9k stelle su GitHub quando ho controllato il 27 luglio 2026, ed è sotto licenza Apache-2.0, quindi tra le più tranquille possibili dal punto di vista commerciale. E non ho testato affatto l’OCR. Nessuna pagina scannerizzata, nessun PDF solo immagine. Tesseract e poppler non sono installati sulla macchina che ho usato, quindi ogni percorso OCR era bloccato prima ancora di iniziare. Qui non ci sono numeri OCR perché non ci sono numeri OCR, punto.

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

L’idea più comune è che Apache Tika sia un convertitore di documenti — gli passi un DOCX e ti restituisce Markdown pulito, con titoli e tabelle intatti. Non è questo, e chiarirlo subito lo fa apparire molto meglio.

Il percorso testato qui ha tre stadi rilevanti: un rilevatore di content-type, un dispatcher che passa i byte al parser giusto e l’handler di output --text della CLI, che emette testo piatto insieme ai metadati disponibili separatamente. In quel contratto di output non esistono oggetti Title, ListItem o una griglia di tabella ricostruita. Tika espone anche altri handler e API, incluso output orientato a XHTML/SAX; non li ho testati. Quindi ogni conclusione strutturale qui sotto riguarda tika-app --text, non è una dichiarazione che il toolkit non abbia da nessuna parte uno stream di eventi strutturato.

Sembra un limite, e da un certo punto di vista lo è. Ma significa anche che Tika non ha nulla da classificare male, ed è proprio questo il compromesso che i suoi cugini più rumorosi fanno nella direzione opposta.

Il rilevamento segue un ordine documentato: prima le firme byte, poi l’ispezione della root XML, poi il pattern del nome file, infine qualsiasi tipo fornito dall’utente (la documentazione di Tika sul detection lo descrive così). Solo dopo che il tipo è stato risolto il dispatcher passa i byte al parser bundlizzato corrispondente — PDFBox, POI, jsoup, TextAndCSVParser per la famiglia testuale.

Questa separazione tra detection e parsing non è un dettaglio interno. È il motivo per cui un file troppo danneggiato per essere parsato può comunque essere tipizzato correttamente, e diventa così il trucco più pratico che Tika offre quando le cose iniziano a rompersi.

Setup: un jar, un comando e un JVM poco schizzinoso

L’installazione è un download. tika-app-3.3.2.jar da Maven Central pesa circa 67 MB — un fat jar con tutti i parser inclusi — e poi basta java -jar tika-app-3.3.2.jar --text file.pdf. Nessun file di configurazione, nessun peso di modello, nessun passaggio post-installazione, nessuna catena di brew install da seguire.

La storia del JDK mi ha sorpreso. Ho eseguito tutto su OpenJDK 26.0.1, una build non LTS all’ultimo stadio, e --version, --text, --metadata e --detect hanno risposto tutti con exit 0, senza lamentele di compatibilità. Vale la pena dirlo, perché lo stesso giorno ho messo alla prova Apache Nutch sullo stesso host e il suo ciclo di crawl non partiva proprio su JDK 26 — richiede un LTS a 21 o inferiore, a causa della rimozione di SecurityManager nei JDK più nuovi. Tika non si è scomposto. Se hai evitato strumenti JVM proprio per quel tipo di problema, Tika non è il punto in cui ti colpisce.

Due deduzioni oneste sul setup. La CLI avvia un JVM nuovo a ogni invocazione, quindi il cold start conta davvero — eseguire 131 invocazioni nel mio harness ha richiesto circa un minuto, perlopiù di warmup del JVM. Se devi processare volumi alti, ti serve la libreria o la modalità server, non un loop shell attorno al jar. E la storia “senza dipendenze” ha un confine netto: l’estrazione del testo dai PDF non richiede nulla di esterno, ma l’OCR richiede tesseract e poppler. PDF con text layer, DOCX, ODT, RTF, HTML, XML, TXT, Markdown, CSV hanno tutti funzionato su un host che non aveva nessuno dei due installati. I documenti scannerizzati no, e non ho provato a fingere il contrario.

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

Il test delle estensioni bugiarde: detection MIME che ignora come hai chiamato il file

Otto formati, ciascuno presentato con un’estensione corretta, una deliberatamente sbagliata o nessuna estensione, più uno stream di byte senza nome file su stdin. Questo fa 32 condizioni logiche uniche. Il harness originale ha anche eseguito gli stessi identici byte stream una volta per ogni etichetta di nome file, ottenendo 48 esecuzioni grezze; quelle tre righe stream si riducono però a 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 da leggere con il glob.)

I cinque formati rilevabili dal contenuto — PDF, DOCX, RTF, HTML e XML — hanno restituito il tipo corretto in 20 condizioni uniche su 20 (e 30 su 30 esecuzioni grezze del harness, includendo i run stream duplicati). 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 firme byte fisse: PDF e RTF hanno header riconoscibili, DOCX è un contenitore basato su ZIP, mentre HTML/XML si identificano dal markup o dal contenuto della root. Meccanismi diversi, stesso risultato utile in queste fixture: l’estensione bugiarda non ha vinto.

Poi c’è il regime dei formati testuali. Markdown ha risolto in text/markdown solo quando l’estensione .md era presente e leggibile. Rinominandolo, togliendo l’estensione o inviandolo come stream, in questo test è scivolato 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 il loro tipo specifico in una sola delle quattro condizioni; il testo semplice era già text/plain, quindi non c’era nulla da cui potesse “collassare”. Il harness grezzo a 48 run resta utile come prova di ripetibilità, ma non come denominatore più grande.

Un dettaglio va a favore di Tika qui: 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 padre è un fallback molto migliore che affermare con sicurezza qualcosa di sbagliato, e il fatto che text/markdown sia un sottotipo documentato di text/plain rende questo comportamento fondato, non arbitrario.

C’è però una nota per CSV. Tika ha un rilevatore statistico per CSV, e al momento del parsing — confermato dal fatto che TextAndCSVParser compariva nella catena X-TIKA:Parsed-By — la mia griglia piccola, 2 colonne per 3 righe, è stata risolta come text/plain invece che 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 per CSV sia rotto; sto dicendo che su questa griglia è stata l’estensione a produrre text/csv.

Perché conta in una pipeline reale di upload

Lo scenario concreto è un router di upload. Immagina di accettare file dagli utenti e instradarli per tipo: i PDF al parser delle fatture, i fogli di calcolo all’importatore contabile, tutto il resto a un indice testuale. Se ti fidi dell’estensione, chi carica un PDF chiamato notes.txt finisce nel ramo sbagliato — e questo è il caso benigno; la versione ostile è un file poliglotta con estensione rassicurante.

Per le fixture binarie e di markup testate qui, Tika ha instradato in base al contenuto anche dopo la scomparsa del nome file, cosa utile quando un object store o un handler di body HTTP l’hanno già eliminato. Questo risultato non copre la lunga coda dei file ambigui o dei poliglotti. Le fixture testuali della famiglia text si sono comportate diversamente: quando la pipeline ha rimosso i nomi file, Markdown e CSV sono arrivati come text/plain, quindi le regole basate sui loro media type specifici non sono più scattate. Conserva il nome originale come metadato sidecar, invece di aspettarti che il content-detection lo ricostruisca.

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

La fedeltà è il secondo asse, e qui si divide nettamente in due. Ho reso un documento canonico (titoli, due paragrafi di 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 rendering di carrier. Ogni blocco contiene un token unico — zztitle1, zzitem3, zztblcell_beta e così via — quindi “sopravvissuto” versus “perso” è un controllo esatto di sottostringa, non una valutazione soggettiva.

Il richiamo dei token-marcatore è tornato 1.000 su tutti e quattordici i rendering. Nessun token inserito è sparito: ogni cella di tabella marcata, ogni elemento di lista e ogni heading erano presenti. Tre ripetizioni locali per carrier dopo il warmup hanno restituito output --text identico a livello di byte. Questo oracolo non dice nulla su caratteri non marcati, ordine, whitespace, normalizzazione Unicode, contenuti ripetuti, link, header, note a piè di pagina o oggetti incorporati. È un controllo sulla presenza dei blocchi, non una prova di fedeltà completa del documento.

L’output di testo piatto rinuncia a gran parte della struttura sorgente.

Ecco come esce dal --text il documento tabellare HTML:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

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

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

Tika non re-renderizza mai un marcatore che non ha ricevuto come testo. Stesso contenuto in entrambi i casi, ma output dall’aspetto diverso.

Il caso Markdown lo mostra in modo limpido. Dai a Tika un file .md con una tabella pipe e i pipe tornano verbatim, il che sembra conservazione della struttura. Non lo è. Tika l’ha trattato come testo e ha restituito i byte. Nessuno ha capito che quella fosse una tabella.

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

La solita cautela vale per ogni numero di fedeltà qui: vengono da fixture sintetiche controllate, su una macchina, una versione, un JDK. Dimostrano che i blocchi marcati erano presenti nell’output. Non stabiliscono una preservazione carattere per carattere né accuratezza su un corpus reale e sporco.

Metadati: normalizzati, e piacevolmente restii a inventare

Ho incorporato valori noti di autore, titolo e data di creazione in ogni carrier che ha un layer di metadati, poi ho controllato cosa fosse tornato indietro.

Autore e titolo sono stati recuperati su 4 carrier con metadati su 4 e — ed è la parte che vale la pena avere — sono normalizzati. Un <meta name="author"> HTML, una proprietà core di DOCX, una voce /Author del PDF e un elemento dc:creator dell’ODT arrivano tutti sotto la stessa chiave dc:creator. Scrivi un solo consumer, non quattro.

created è la vibrazione onesta. DOCX e ODT hanno restituito il mio timestamp esatto del 2021. Il PDF ha restituito una data di creazione, ma era quella timbrata dalla libreria generatrice al momento della build, non il valore che intendevo incorporare — quindi la conto come presente, non recuperata. E i formati senza layer di metadati non hanno mostrato nulla, che è la risposta corretta. Tika non inventa un autore dal corpo del testo.

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

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

Il harness sottostante, le fixture generate, il JSON grezzo, il checksum del jar e il manifest dell’ambiente non sono linkati pubblicamente qui, quindi un lettore esterno non può riprodurre in modo indipendente gli stessi denominatori esatti. Tratta le tabelle come osservazioni riportate, non come evidenza verificabile da terzi.

L’estrazione fallisce in modo rumoroso, e questi fallimenti hanno tutti 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 elegante. Sicuro per il processo in questi casi — niente hang, niente segfault — ma il chiamante deve controllare exit status e stderr, non solo cercare una stringa vuota.

Detection e parsing sono separati. Su entrambi i binari troncati, --detect ha restituito exit 0 con il tipo atteso a partire dal contenuto iniziale integro; poi il parser ha fallito sul corpo corrotto. Una pipeline può quindi usare la detection come segnale di triage separato prima o dopo un parsing fallito. Se convenga fare detect-first come default dipende dalla modalità di deployment: questo test non ha confrontato detect-first con parse-only, e due JVM CLI nuove di zecca potrebbero essere il compromesso sbagliato ad alto volume.

Il rilevamento della codifica 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, indistinguibile da UTF-8 sui byte ASCII. Non è un errore, è un pareggio.

Tika accanto a unstructured: stessi tipi di file, lavori diversi

Entrambi sono stati esercitati 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 invece si basa sul tipo di elemento, il percorso --text di Tika non può fornire quel contratto.

Nessuno dei due ha numeri sui documenti scannerizzati.

Pro e contro

Pro

• La detection del content-type ha ignorato i nomi file bugiardi in 20/20 condizioni uniche sui cinque fixture rilevabili dal contenuto; anche le esecuzioni stream duplicate concordavano.
• Tutti i marker inseriti sono sopravvissuti in tutti e 14 i rendering dei carrier, incluse le celle di tabella e gli elementi di lista marcati.
• Ripetibile in tre rerun locali: ogni carrier 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 carrier con metadati.
• Davvero senza dipendenze per i formati testati: layer testuale PDF, DOCX, ODT, RTF, HTML si parsano da un solo jar senza binari esterni.
• Funziona senza problemi su OpenJDK 26 — nessun vincolo da 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 firma sono scivolate a text/plain quando il nome file mancava o era sbagliato.
• --text non restituisce tipi di elemento; le griglie delle tabelle si appiattiscono in righe unite da tabulazioni e i marcatori strutturali delle liste spariscono.
• L’estrazione lancia eccezioni non catturate su input vuoti e corrotti; i due casi appaiono identici solo guardando la chiamata di estrazione.
• Jar da 67 MB più un cold start del JVM per ogni invocazione in modalità CLI.
• OCR e PDF scannerizzati non sono stati testati qui — tesseract e poppler non erano presenti, quindi non viene fatta alcuna affermazione su quel percorso.
• Ogni numero qui è ground truth sintetico su una sola macchina, una sola versione. Accuratezza su corpus reale, file cifrati, documenti incorporati/ricorsivi e throughput su larga scala non sono stati misurati.

Chi dovrebbe usarlo, e chi no

Tika è adatto quando l’input sono file che hai già in mano e l’output deve essere testo più metadati indicizzabili da una macchina. Indicizzazione per ricerca, e-discovery, elaborazione di archivi, alimentazione di un corpus per LLM, costruzione del livello di validazione del content-type in una pipeline di upload. È utile come primo stadio di triage e normalizzazione davanti a qualcosa di più intelligente: rileva i tipi testati, estrae testo piatto e inoltra il tutto 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 layout del documento. Evitalo se i tuoi documenti sono scansioni, almeno finché non hai installato tesseract e non hai fatto i tuoi numeri, perché io non ne ho. Per lavori ad alto volume, confronta la libreria o la modalità server con la CLI su documenti rappresentativi. L’avvio del processo era visibile in questo harness su file piccoli, ma throughput e costo in risorse non sono stati misurati.

Il punto che spesso sorprende: se il tuo layer di storage rimuove i nomi file e gestisci Markdown o CSV, non affidarti a Tika per distinguerli dal testo semplice. Tieni il nome originale.

Alternative, e dove si colloca Thunderbit

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

È proprio questo il confine in cui può entrare un servizio gestito di estrazione web, incluso il nostro Thunderbit: recupera pagine live, mentre Tika analizza file già in tuo possesso. Questo articolo non ha confrontato quei servizi con Tika, e non sono sostituti per lo stesso input.

La divisione pulita: Tika per i documenti che hai già, un’API di estrazione gestita per le pagine web che devi andare a prendere. Molte pipeline usano entrambe — crawling ed estrazione lato web, Tika sugli allegati PDF e DOCX che tornano indietro.

Se stai confrontando il panorama open source più ampio, ho scritto il confronto completo tra scraper open source, una rassegna dei progetti di web scraping più utili su GitHub, una recensione pratica di Crawl4AI che copre l’approccio Markdown con 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 marker che la tua pipeline non può permettersi di perdere.

Il detector è stata la parte più forte di questa prova. Ha restituito il tipo atteso in 20 condizioni uniche su 20 per i cinque fixture rilevabili dal contenuto, inclusi gli stream senza nome file. Tutti i marker inseriti sono sopravvissuti in quattordici rendering, e l’output si è ripetuto byte per byte in tre rerun locali. Evidenza utile. Ma pur sempre evidenza sintetica. Farlo da un solo jar su questo JDK, senza binari esterni per i percorsi non OCR testati, ha reso il deployment piacevolmente noioso.

Va dimensionato nel modo giusto, però. Ogni tabella che gli passi torna come righe unite da tabulazioni. Ogni marcatore strutturale di lista scompare. Markdown e CSV perdono la loro identità nel momento in cui il nome file sparisce. File vuoti e file corrotti generano la stessa forma di errore, e per distinguerli ti serve la chiamata separata a detect. E sull’OCR, che è la domanda che interessa a molti utenti Tika, non ho nulla da offrire: non sono riuscito a eseguirlo, e non ho intenzione di stimarlo.

Dentro questi confini, Tika fa un lavoro poco spettacolare ma sorprendentemente affidabile. Legge i byte, non l’etichetta sulla confezione. Basta non chiedergli che forma avessero quei byte.

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

FAQ

Apache Tika riconosce 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 nel loro media type atteso in tutte le 20 condizioni logiche uniche (30 run grezzi con esecuzioni stream duplicate), comprese estensioni fuorvianti, assenza di estensione e stream senza nome file. Un PDF chiamato .txt è stato comunque rilevato come application/pdf. Markdown e il piccolo fixture CSV dipendevano invece dalle informazioni sul nome file e sono scivolati a text/plain quando mancavano o erano sbagliate.

Tika preserva tabelle e struttura dei documenti? Non nella modalità --text testata qui. Le griglie delle tabelle sono tornate come righe unite da tabulazioni, senza semantica di cella o intestazione, e i marcatori strutturali delle liste (<li> HTML, stile DOCX List Bullet) sono spariti. Tutti i marker inseriti sono sopravvissuti in tutti e 14 i rendering dei carrier, ma questo non dimostra una fedeltà completa del contenuto, e --text non fornisce tipizzazione degli elementi. Se ti servono elementi tipizzati o tabelle ricostruite, prova un altro handler di output di Tika oppure usa un altro strumento insieme a Tika.

Apache Tika può fare OCR sui PDF scannerizzati? Tika supporta l’OCR tramite Tesseract, ma non l’ho testato, e nessuno di questi risultati è una dichiarazione su quel punto. Tesseract e poppler non erano presenti sul mio host di test, quindi tutti i percorsi OCR e per immagini scannerizzate erano bloccati prima di partire. Non ci sono numeri OCR in questo test. Se l’OCR è il tuo caso d’uso, installa tesseract e misuralo tu stesso — considera quella parte di Tika 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 file vuoti e corrotti sono indistinguibili dalla sola chiamata di estrazione. La detection però resta robusta: --detect ha restituito exit 0 con il tipo corretto su entrambi i binari troncati, rendendola una fase di triage affidabile prima di spendere un parsing.

Cosa non ha coperto il test di Tika? Quattro cose, in modo esplicito. OCR e immagini scannerizzate (bloccate, non testate). 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 sporchi. Costo delle risorse, throughput e memoria di picco, che non ho misurato. E la lunga coda della promessa dei “mille formati”: ho testato nove formati rappresentativi e senza dipendenze esterne, non il catalogo completo. Tutto qui è Tika 3.3.2 su OpenJDK 26.0.1, macOS arm64, su una sola macchina.