Análise do Apache Tika: Ele Lê os Bytes, Não o Nome do Arquivo — Até Encontrar Markdown

Apache Tika é o kit de ferramentas de análise de documentos da Apache Software Foundation: mande praticamente qualquer tipo de arquivo e ele devolve texto simples mais um conjunto padronizado de metadados. O README do projeto promete suporte a mais de mil tipos de arquivo, e o Tika chega lá empacotando as bibliotecas especializadas por conta própria — PDFBox para PDFs, Apache POI para documentos do Office, jsoup para HTML, um leitor ODF para ODT — então tudo vem num único fat jar, sem precisar baixar nada na hora da análise. Em um pipeline de dados, ele entra como a primeira etapa pouco glamourosa: o componente antes de um índice de busca, de um conjunto de e-discovery ou de um corpus para LLM, transformando uma pilha heterogênea de arquivos em algo uniforme. No fim, são duas tarefas: descobrir o que um fluxo de bytes é e depois extrair dele o texto e os metadados.

É a ferramenta menos exigente que eu configurei em muito tempo. Um jar, java -jar tika-app-3.3.2.jar --text file.pdf, sem arquivo de configuração, sem pesos de modelo, sem etapa pós-instalação — e ela rodou sem problema em um JDK de ponta que derrubou outras ferramentas Java no mesmo host naquela mesma tarde. Mas eu não queria testar a promessa do catálogo; a pergunta testável é mais específica. Quando a entrada mente para você, o que o Tika realmente faz? Então montei um conjunto controlado de testes em que cada bloco de conteúdo carregava um token-marcador único, renderizei o mesmo documento lógico em nove formatos de saída e depois ataquei tudo com extensões erradas, extensões ausentes, nenhum nome de arquivo, arquivos vazios e binários parcialmente escritos.

A detecção é onde aparece o comportamento mais interessante. Renomeei um PDF para .txt e perguntei ao Tika o que era; ele respondeu application/pdf. Depois apaguei o nome do arquivo por completo, enviei os bytes brutos via stdin e recebi a mesma resposta. Nos cinco formatos detectáveis por conteúdo do meu conjunto, isso se manteve em todas as 20 condições lógicas únicas: três condições de nome de arquivo mais uma condição de stream sem nome por formato. O harness executou o caso de stream três vezes sob rótulos diferentes, gerando 30 execuções brutas bem-sucedidas, mas essas repetições não contam como evidência independente. PDF e RTF expõem bytes reconhecíveis; DOCX expõe seu contêiner; HTML e XML podem ser identificados por marcação ou conteúdo raiz. Mecanismos diferentes, mesmo resultado útil neste conjunto de testes: a extensão não venceu o conteúdo. Já na família de texto, Markdown cai para text/plain no instante em que o nome do arquivo está errado ou desaparece. Aqui, a identidade dele dependeu totalmente de .md.

Duas observações antes de qualquer número abaixo. Testei o Apache Tika 3.3.2 — verificado em 27 de julho de 2026, ainda era a versão estável mais recente; a linha 4.0.0 existia apenas como builds alpha e beta no Maven Central. O projeto tinha cerca de 3,9 mil estrelas no GitHub quando verifiquei em 27 de julho de 2026 e usa licença Apache-2.0, o que é praticamente o cenário mais tranquilo possível do ponto de vista comercial. E não testei OCR em hipótese alguma. Nenhuma página escaneada, nenhum PDF só de imagem. Tesseract e poppler não estão instalados na máquina em que rodei isso, então qualquer caminho de OCR já estava bloqueado antes de começar. Não há números de OCR aqui porque não há números de OCR, ponto final.

O que o Tika é, depois que você para de ler o marketing da embalagem

A suposição mais comum é que o Apache Tika seja um conversor de documentos — você envia um DOCX e recebe Markdown limpo, com títulos e tabelas intactos. Não é isso, e quanto antes isso ficar claro, melhor a ferramenta parece.

O caminho testado aqui tem três etapas relevantes: um detector de tipo de conteúdo, um dispatcher que encaminha os bytes para o parser certo e o manipulador de saída --text da CLI, que emite texto plano junto com metadados disponíveis separadamente. Nesse contrato de saída não existem objetos Title, nem ListItem, nem uma grade de tabela reconstruída. O Tika também expõe outros handlers e APIs, incluindo saída orientada a XHTML/SAX; eu não testei esses caminhos. Portanto, toda conclusão sobre estrutura abaixo diz respeito a tika-app --text, e não a uma afirmação de que a ferramenta não tenha um fluxo de eventos estruturado em nenhum lugar.

Isso soa como limitação, e em certo sentido é mesmo. Mas também significa que o Tika não tem como classificar errado o que recebeu, e é exatamente esse o compromisso que ferramentas mais “barulhentas” fazem na direção oposta.

A detecção em si segue uma ordem documentada: primeiro bytes de assinatura, depois inspeção do elemento raiz XML, depois o glob do nome do arquivo e, por fim, qualquer tipo que você tenha informado manualmente (a documentação de detecção do Tika descreve isso). Só depois de resolver o tipo é que o dispatcher entrega os bytes ao parser correspondente empacotado — PDFBox, POI, jsoup, TextAndCSVParser para a família de texto.

Essa separação entre detectar e analisar não é detalhe interno. É por isso que um arquivo quebrado demais para ser analisado ainda pode ser identificado corretamente — e isso vira o truque mais prático que o Tika oferece quando as coisas começam a falhar.

Configuração: um jar, um comando e um JVM pouco exigente

Instalar é baixar. O tika-app-3.3.2.jar no Maven Central tem cerca de 67 MB — um fat jar com todos os parsers inclusos — e depois disso é só java -jar tika-app-3.3.2.jar --text file.pdf. Sem arquivo de configuração, sem pesos de modelo, sem etapa pós-instalação, sem uma cadeia de brew install para percorrer.

A história do JDK me surpreendeu. Rodei tudo em OpenJDK 26.0.1, uma build de ponta e não-LTS, e --version, --text, --metadata e --detect devolveram exit code 0 sem nenhuma reclamação de compatibilidade. Vale destacar isso porque também testei o Apache Nutch no mesmo host na mesma sessão, e o ciclo de crawl dele não funcionou no JDK 26 de jeito nenhum — ele exige um LTS na versão 21 ou inferior, por causa da remoção do SecurityManager nos JDKs mais novos. O Tika não se importou. Se você vem evitando tooling JVM por esse tipo específico de dor, não é no Tika que isso pega.

Duas deduções honestas sobre a configuração. A CLI sobe uma JVM nova a cada invocação, então o tempo de inicialização fria é real — rodar 131 invocações no meu harness levou cerca de um minuto, em grande parte aquecendo a JVM. Se você processa arquivos em volume, quer a biblioteca ou o modo servidor, não um loop de shell em cima do jar. E há um limite duro na história de “sem dependências”: extração de texto da camada textual do PDF não precisa de nada externo, mas OCR precisa de tesseract e poppler. PDFs com camada de texto, DOCX, ODT, RTF, HTML, XML, TXT, Markdown e CSV foram analisados em um host sem nenhum dos dois instalados. Documentos escaneados não teriam sido, e eu não tentei fingir o contrário.

Esse contraste fica ainda mais nítido quando comparado à biblioteca irmã que testei no mesmo dia, unstructured, cujo caminho para PDF eletrônico foi bloqueado completamente porque importar seu módulo de PDF puxa a pilha de inferência (torch e afins) no carregamento — antes mesmo do despacho por estratégia, então nem a estratégia “fast” consegue ser importada sem isso. O Tika analisou a camada textual do mesmo PDF com um simples java -jar.

O teste da extensão mentirosa: detecção de mime type que ignora o nome que você deu ao arquivo

Oito formatos, cada um apresentado com extensão correta, extensão deliberadamente errada ou sem extensão, além de um stream de bytes sem nome no stdin. Isso gera 32 condições lógicas únicas. O harness original também executou os mesmos bytes de stream uma vez sob cada rótulo de nome de arquivo, totalizando 48 execuções brutas; essas três linhas de stream se reduzem a uma condição porque stdin não carrega nome de arquivo.

(A coluna de stream junta as três condições de extensão, porque sem nome de arquivo não há nada para o glob ler.)

Os cinco formatos detectáveis por conteúdo — PDF, DOCX, RTF, HTML e XML — chegaram ao tipo correto em 20 de 20 condições únicas (e 30 de 30 execuções brutas do harness, incluindo as execuções de stream duplicadas). Um PDF chamado report.txt continuou sendo PDF. Um DOCX chamado photo.jpg continuou sendo DOCX. Nenhum deles precisou de nome de arquivo. Isso não quer dizer que os cinco usem assinaturas fixas de bytes: PDF e RTF têm cabeçalhos reconhecíveis, DOCX é um contêiner baseado em ZIP, e HTML/XML são identificados pela marcação ou pelo conteúdo raiz. Nesses testes, a extensão mentirosa não venceu.

Depois vem o regime da família de texto. Markdown só resolveu como text/markdown quando a extensão .md estava presente e legível. Renomeie, remova a extensão ou envie como stream, e ele degradou para text/plain neste teste. O CSV se comportou do mesmo modo nesse grid pequeno e deliberadamente limitado: text/csv só apareceu via glob de .csv. Contando as condições únicas, Markdown e CSV resolveram como seu tipo específico em uma de quatro condições cada; texto simples já era text/plain, então não havia nada a partir do qual ele pudesse “colapsar”. As 48 execuções brutas ainda são úteis como registro de repetibilidade, mas não como denominador maior.

Um detalhe joga a favor do Tika aqui: a extensão mentirosa também não vence. Meu fixture de Markdown renomeado para .pdf voltou como text/plain, não como application/pdf. O Tika não acreditou na mentira; só não conseguiu confirmar a verdade. Degradar para o tipo pai é um resultado de falha muito melhor do que afirmar com confiança algo errado, e o fato de text/markdown ser um subtipo documentado de text/plain torna esse fallback algo principiado, não arbitrário.

Há uma ressalva específica sobre CSV. O Tika tem um detector estatístico de CSV e, no momento da análise — confirmado pelo TextAndCSVParser aparecendo na cadeia X-TIKA:Parsed-By — minha grade pequena de 2 colunas por 3 linhas resolveu como text/plain em vez de text/csv. Essa é uma única observação em um fixture propositalmente mínimo. Um CSV maior ou com aspas pode muito bem acionar o detector. Não estou dizendo que a detecção por conteúdo de CSV está quebrada; estou dizendo que, nesse grid, foi a extensão que produziu text/csv.

Por que isso importa em um pipeline real de upload

O cenário concreto é um roteador de uploads. Suponha que você aceite envios de usuários e os direcione por tipo: PDFs para o parser de notas fiscais, planilhas para o importador contábil, todo o resto para um índice de texto. Se você confiar na extensão, alguém enviando um PDF chamado notes.txt cai no ramo errado — e esse é o caso benigno; a versão hostil é um arquivo poliglota com extensão amigável.

Para os fixtures binários e de marcação testados aqui, o Tika roteou pelo conteúdo mesmo depois de o nome do arquivo desaparecer, o que é útil quando um blob store ou um manipulador de body HTTP o descartou. Esse resultado não cobre a longa cauda de formatos do Tika, arquivos ambíguos ou poliglotas. Os fixtures textuais testados se comportaram de maneira diferente: quando o pipeline removeu os nomes de arquivo, Markdown e CSV chegaram como text/plain, então regras baseadas em seus tipos de mídia específicos deixaram de disparar. Preserve o nome original como metadado auxiliar, em vez de esperar que a detecção por conteúdo o reconstrua.

O conteúdo inserido sobreviveu. --text achatou a estrutura.

Fidelidade é o segundo eixo, e aqui ele se divide claramente em dois. Renderizei um documento canônico (títulos, dois parágrafos de corpo, uma lista com marcadores, uma lista numerada e um parágrafo final) em HTML, Markdown, texto simples, DOCX, PDF, RTF, ODT e XML, além de um documento de tabela em HTML, Markdown, texto, DOCX, CSV e XML. Quatorze renderizações em formatos diferentes. Cada bloco carrega um token único — zztitle1, zzitem3, zztblcell_beta e assim por diante — então “sobreviveu” versus “foi perdido” é uma verificação exata de substring, não uma interpretação subjetiva.

O recall dos tokens-marcadores foi 1.000 em todas as quatorze renderizações. Nenhum token inserido sumiu: cada célula de tabela marcada, item de lista e título estava presente. Três repetições locais por formato, após o aquecimento, retornaram saída --text idêntica em bytes. Esse oráculo não diz nada sobre caracteres sem marcador, ordem, espaços em branco, normalização Unicode, conteúdo repetido, links, cabeçalhos, notas de rodapé ou objetos embutidos. É uma checagem de presença de blocos, não uma prova de fidelidade completa do documento.

A saída em texto plano abandona a maior parte da estrutura de origem.

Esta é a tabela de documento HTML saindo do --text:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

Linhas separadas por tabulação. A linha de cabeçalho não vem marcada como cabeçalho. Não há grade, nem limites de célula além do tab, nem jeito de saber que aquilo já foi um <table>. A tabela no DOCX é achatada da mesma maneira.

Listas são mais sutis e se dividem conforme o que o conteúdo de origem realmente continha:

O Tika nunca recria um marcador que não recebeu como texto. Mesmo conteúdo, saída com aparência diferente.

O caso Markdown deixa isso bem claro. Se você entregar ao Tika um arquivo .md com uma tabela em pipe, os pipes voltam literalmente, o que parece preservação de estrutura. Não é. O Tika tratou aquilo como texto e devolveu os bytes. Nada entendeu aquela tabela.

Então o contrato medido é mais estreito: todos os marcadores inseridos sobreviveram, mas --text não preservou elementos tipados nem uma grade de tabela reconstruível. Chamar isso de defeito do parser perderia o ponto principal. A extração em texto plano evita deliberadamente o problema de classificar elementos; ao mesmo tempo, ela não consegue satisfazer um consumidor downstream que precisa desses tipos de elemento. Se você precisa de blocos tipados ou de tabelas reconstruídas, --text é só um componente da pilha, não a pilha inteira. Outros handlers do Tika podem expor mais estrutura, mas ficaram fora desta execução.

O aviso padrão vale para todos os números de fidelidade aqui: eles vêm de fixtures sintéticos controlados em uma máquina, uma versão e um JDK. Eles mostram que os blocos marcados estavam presentes na saída. Não provam preservação caractere por caractere nem precisão em um corpus real bagunçado.

Metadados: normalizados e, felizmente, sem inventar coisas

Embebi valores conhecidos de autor, título e data de criação em cada formato que tem camada de metadados e depois verifiquei o que voltou.

Autor e título foram recuperados em 4 de 4 formatos com metadados, e — e esse é o ponto mais valioso — vêm normalizados. Um <meta name="author"> de HTML, uma propriedade central do DOCX, uma entrada /Author de PDF e um elemento dc:creator de ODT chegam sob a mesma chave dc:creator. Você escreve um consumidor, não quatro.

created é o ponto menos estável, de forma honesta. DOCX e ODT devolveram exatamente o timestamp de 2021 que eu embuti. O PDF devolveu uma data de criação, mas era a data carimbada pela biblioteca geradora no build, não o valor que eu pretendia embutir — então eu o considero presente, não recuperado. E os formatos sem camada de metadados não exibiram nada, que é a resposta correta. O Tika não inventa autor a partir do corpo do texto.

Quebrando de propósito e o truque de triagem que isso revela

Quatro entradas hostis. Um arquivo de zero bytes. Um PDF válido com o corpo cortado. Um ZIP de DOCX truncado. E um arquivo UTF-8 com caracteres multibyte, sem BOM e sem declaração de codificação. São formatos locais de fixture, não limites do Tika.

O harness subjacente, os fixtures gerados, o JSON bruto, o checksum do jar e o manifesto do ambiente não estão vinculados neste rascunho. Um leitor externo, portanto, ainda não consegue reproduzir de forma independente os denominadores exatos. Trate as tabelas como observações reportadas; a publicação deveria anexar um pacote estável antes que esses números sejam usados como evidência por terceiros.

A extração falha de forma explícita, e essas falhas compartilham a mesma forma externa. O arquivo de zero bytes, o PDF truncado e o DOCX truncado produziram exceção, exit code 1 e stdout vazio. A CLI não engole a falha para transformá-la em um resultado vazio bonito. É segura do ponto de vista do processo nesses casos — sem travamento, sem segfault — mas o chamador precisa checar o status de saída e o stderr, e não apenas olhar para uma string vazia.

A detecção é separada da análise. Nos dois binários truncados, --detect retornou exit code 0 com o tipo esperado a partir do conteúdo intacto do começo do arquivo; depois o parser falhou no corpo quebrado. Um pipeline pode, portanto, usar a detecção como um sinal de triagem separado antes ou depois de uma análise falhada. Se detectar primeiro é ou não o padrão ideal depende do modo de implantação: este teste não comparou detect-first com parse-only, e duas JVMs novas da CLI podem ser o trade errado em alto volume.

A detecção de charset funciona. O arquivo UTF-8 sem BOM e sem declaração foi decodificado como UTF-8, e 日本語テスト apareceu intacto. Uma pequena ressalva para quem lê os metadados: meus fixtures puramente ASCII reportam charset=ISO-8859-1, o que é indistinguível de UTF-8 quando os bytes são só ASCII. Isso não é erro; é empate.

Tika ao lado de unstructured: mesmos tipos de arquivo, trabalhos diferentes

Ambos foram exercitados na mesma sessão de pesquisa, mas isto é uma taxonomia de contratos de saída, não um benchmark simétrico. As ferramentas foram avaliadas por resultados diferentes.

Análise relacionada: análise do Unstructured.

Saída em texto plano preservando marcadores versus elementos tipados com erros observados de classificação. Escolha conforme o que o consumidor downstream precisa. Se for um índice de busca ou uma janela de contexto para LLM, texto plano pode bastar. Se ele depende de tipo de elemento, o caminho --text do Tika não consegue fornecer esse contrato.

Nenhum dos dois tem números de documentos escaneados.

Prós e contras

Prós

• A detecção de tipo de conteúdo ignorou nomes de arquivo mentirosos em 20/20 condições únicas nos cinco fixtures detectáveis por conteúdo; as execuções duplicadas de stream também concordaram.
• Todos os marcadores inseridos sobreviveram nas 14 renderizações de formato, incluindo as células de tabela e itens de lista marcados.
• Repetível em três novas execuções locais: cada formato retornou texto idêntico em bytes dentro deste ambiente.
• Metadados normalizados entre formatos — dc:creator / dc:title / dcterms:created independentemente do formato de origem, recuperados em 4/4 dos formatos com metadados.
• Genuinamente sem dependências para os formatos testados: camada textual de PDF, DOCX, ODT, RTF, HTML, tudo analisado a partir de um único jar, sem binários externos.
• Roda limpo em OpenJDK 26 — sem exigência de LTS.
• A detecção continua correta (exit 0) em binários truncados, fornecendo um sinal de triagem confiável quando a análise falha.
• Licença Apache-2.0, maduro, em manutenção ativa.

Contras

• A identidade de Markdown e CSV depende totalmente da extensão; 10 de 18 células sem assinatura colapsaram para text/plain assim que o nome do arquivo sumiu ou estava errado.
• --text não retorna tipos de elemento; grades de tabela viram linhas separadas por tab e marcadores estruturais de lista desaparecem.
• A extração lança exceção sem capturar em entradas vazias e corrompidas; os dois casos parecem iguais só olhando a chamada de extração.
• Jar de 67 MB mais um cold start de JVM por invocação no modo CLI.
• OCR e PDFs de imagem escaneada não foram testados aqui — tesseract e poppler estavam ausentes, então nenhuma afirmação é feita sobre esse caminho.
• Todo número aqui é ground truth sintético em uma máquina, uma versão. Precisão em corpus real, arquivos criptografados, documentos embutidos/recursivos e throughput em escala não foram medidos.

Quem deve usar e quem não deve

O Tika faz sentido quando sua entrada são arquivos que você já possui e sua saída precisa ser texto mais metadados que uma máquina possa indexar. Indexação de busca, e-discovery, processamento de arquivos, alimentação de um corpus para LLM, construção da camada de validação de tipo de conteúdo de um pipeline de upload. Ele é útil como uma primeira etapa de triagem e normalização à frente de algo mais inteligente: detectar os tipos testados, extrair texto plano e repassar com verificações explícitas para o conteúdo que seu pipeline não pode se dar ao luxo de perder.

Passe longe — ou melhor, não pare no --text — se você precisa de elementos tipados, tabelas reconstruídas ou layout de documento. Passe longe se seus documentos são escaneados, pelo menos até instalar tesseract e rodar seus próprios números, porque eu não tenho nenhum. Para trabalho em volume, faça benchmark do modo biblioteca ou servidor contra a CLI em documentos representativos. O custo de subir o processo apareceu neste harness de arquivos pequenos, mas throughput e uso de recursos não foram medidos.

O detalhe que pega muita gente: se sua camada de armazenamento remove nomes de arquivo e você lida com Markdown ou CSV, não confie no Tika para diferenciá-los de texto simples. Preserve o nome original.

Alternativas, e onde o Thunderbit entra

Primeiro, uma comparação justa, porque aqui o ponto honesto é sobre entradas, não sobre qualidade. O Tika é um kit de ferramentas gratuito, Apache-2.0 e auto-hospedado para analisar arquivos. Arquivos que você já tem no disco ou em um bucket. Ele não busca páginas, não executa JavaScript, não lida com anti-bot e não finge que faz isso.

Essa é a fronteira em que um serviço gerenciado de extração web, inclusive o nosso Thunderbit, pode entrar na arquitetura: ele busca páginas ao vivo, enquanto o Tika analisa arquivos que já estão em sua posse. Este artigo não comparou esses serviços com o Tika, e eles não são substitutos para a mesma entrada.

A divisão fica limpa: Tika para documentos que já estão sob sua posse, uma API gerenciada de extração para páginas web que você precisa buscar. Muitos pipelines usam ambos — crawl e extração no lado web, Tika nos anexos PDF e DOCX que retornam.

Se você estiver comparando com o universo open source mais amplo, escrevi o comparativo completo de scrapers open source, uma seleção dos projetos de scraping mais úteis no GitHub, uma análise prática do Crawl4AI cobrindo a abordagem Markdown com navegador, e um resumo mais amplo de ferramentas de scraping. Para o caminho sem código, também há um guia de como raspar um site usando IA.

Experimente o Thunderbit para extração de dados da web

Veredito

Vale a pena usar o Apache Tika? Sim, se sua tarefa é transformar arquivos heterogêneos em texto plano e metadados normalizados, e você valida os campos ou marcadores que seu pipeline não pode perder.

O detector foi a parte mais forte desta execução. Ele retornou o tipo esperado em 20 de 20 condições únicas para os cinco fixtures detectáveis por conteúdo, inclusive streams sem nome de arquivo. Todos os marcadores inseridos sobreviveram nas quatorze renderizações, e a saída se repetiu byte por byte em três novas execuções locais. Evidência útil. Ainda assim, evidência sintética. Fazer isso a partir de um único jar neste JDK, sem binários externos nos caminhos não-OCR testados, deixou a implantação agradavelmente sem drama.

Mas dimensione corretamente. Cada tabela que você envia volta como linhas separadas por tab. Todo marcador estrutural de lista desaparece. Markdown e CSV perdem sua identidade no instante em que o nome do arquivo some. Arquivos vazios e corrompidos lançam a mesma forma de falha, e você vai precisar da chamada separada de detect para diferenciá-los. E em OCR, a questão que muita gente que usa Tika mais quer saber, eu não tenho nada a oferecer: não consegui rodar, e não vou chutar.

Dentro desses limites, o Tika faz um trabalho pouco glamouroso com uma confiabilidade incomum. Ele lê os bytes, não o rótulo na caixa. Só não pergunte que forma esses bytes tinham.

Experimente o Thunderbit para extração de dados da web Get Started Free

FAQs

O Apache Tika detecta tipos de arquivo corretamente se a extensão estiver errada? Para os cinco fixtures detectáveis por conteúdo testados aqui, sim. PDF, DOCX, RTF, HTML e XML resolveram para seu tipo de mídia esperado em todas as 20 condições lógicas únicas (30 execuções brutas com streams duplicados), incluindo extensões enganosas, ausência de extensão e streams sem nome de arquivo. Um PDF chamado .txt ainda foi detectado como application/pdf. Markdown e o pequeno fixture de CSV dependeram de informação de nome de arquivo e degradaram para text/plain quando ela faltou ou estava errada.

O Tika preserva tabelas e estrutura de documento? Não no modo --text testado aqui. As grades de tabela voltaram como linhas separadas por tab, sem semântica de célula ou cabeçalho, e os marcadores estruturais de lista (um <li> em HTML, um estilo List Bullet no DOCX) desapareceram. Todos os marcadores inseridos sobreviveram nas 14 renderizações de formato, mas isso não prova fidelidade completa do conteúdo, e --text não fornece tipagem de elementos. Para elementos tipados ou tabelas reconstruídas, teste outro handler de saída do Tika ou use outra ferramenta junto com ele.

O Apache Tika faz OCR em PDFs escaneados? O Tika suporta OCR via Tesseract, mas eu não testei isso, e nenhum destes resultados é uma afirmação sobre esse caminho. Tesseract e poppler estavam ausentes no meu host de testes, então qualquer caminho de OCR e imagens escaneadas foi bloqueado antes de rodar. Não há números de OCR em lugar nenhum neste teste. Se OCR for o seu caso de uso, instale tesseract e faça seu próprio benchmark — trate essa parte do Tika como não verificada aqui.

O que o Tika faz com arquivos vazios ou corrompidos? Ele falha de forma explícita, não silenciosa. Um arquivo de 0 bytes lança ZeroByteFileException; um PDF truncado lança uma TikaException do PDFParser; um DOCX truncado lança um erro XML do POI. Os três encerram com exit 1 e stdout vazio, então vazio e corrompido são indistinguíveis olhando só a chamada de extração. A detecção, porém, continua robusta — --detect retornou exit 0 com o tipo correto nos dois binários truncados, o que o torna uma etapa de triagem confiável antes de gastar uma análise.

O que os testes do Tika não cobriram? Quatro coisas, de forma explícita. OCR e imagens escaneadas (bloqueados, não testados). Precisão em corpus real — todos os resultados são fixtures sintéticos controlados com tokens-marcadores inseridos, o que mede fidelidade contra rótulos conhecidos em vez de precisão em documentos reais e bagunçados. Custo de recursos, throughput e memória de pico, que não medi. E a longa cauda da promessa de “mil tipos de arquivo”: testei nove formatos representativos, sem dependências, não o catálogo inteiro. Tudo aqui é Tika 3.3.2 em OpenJDK 26.0.1, macOS arm64, uma única máquina.