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 parsing de documentos da Apache Software Foundation: você passa um arquivo de praticamente qualquer tipo e ele devolve texto puro, além de um dicionário de metadados normalizado. O README do projeto anuncia 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 Office, jsoup para HTML, um leitor ODF para ODT — então tudo é distribuído como um único fat jar, sem precisar baixar nada no momento da extração. Em um pipeline de dados, ele é a primeira etapa discreta, mas essencial: o componente que fica na frente de um índice de busca, de um conjunto de revisão para e-discovery ou de um corpus para LLM, transformando uma pilha heterogênea de arquivos em algo uniforme. No fim das contas, ele executa duas tarefas: descobrir o que um fluxo de bytes é e então extrair dele texto e metadados.

É uma das ferramentas menos exigentes que 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 funcionou sem problemas em um JDK de ponta, que no mesmo dia travou outras ferramentas Java na mesma máquina. Mas a alegação do catálogo não era o que eu queria testar; a pergunta verificável era mais específica. Quando a entrada mente para você, o que o Tika realmente faz? Então montei um conjunto de testes controlado em que cada bloco de conteúdo carregava um token marcador único, renderizei o mesmo documento lógico em nove formatos diferentes e depois ataquei tudo com extensões erradas, extensões ausentes, nenhum nome de arquivo, arquivos de zero bytes e binários pela metade.

A detecção é onde o comportamento interessante aparece. Renomeei um PDF para .txt e perguntei ao Tika o que era; ele respondeu application/pdf. Depois apaguei o nome do arquivo completamente, mandei 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 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 são evidência independente. PDF e RTF expõem bytes reconhecíveis; DOCX expõe seu contêiner; HTML e XML podem ser identificados pela marcação ou pelo conteúdo da raiz. Mecanismos diferentes, mesmo resultado útil neste conjunto de testes: a extensão não se sobrepôs ao conteúdo. Já no regime de família de texto, o Markdown cai para text/plain no instante em que o nome do arquivo está errado ou desaparece. Aqui, sua identidade dependia inteiramente de .md.

Dois limites para todos os números que seguem. 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 estava em cerca de 3,9 mil estrelas no GitHub quando consultei em 27 de julho de 2026, e é licenciado sob Apache-2.0, o que é praticamente o cenário mais amigável possível para uso comercial. E eu não testei OCR de forma 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 todos os caminhos de OCR estavam bloqueados antes mesmo 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 caixa

A suposição mais comum é que o Apache Tika seja um conversor de documentos — você alimenta 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 fluxo 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 grade de tabela reconstruída. O Tika também expõe outros handlers e APIs, incluindo saídas orientadas a XHTML/SAX; eu não testei essas opções. Portanto, toda conclusão estrutural abaixo diz respeito a tika-app --text, e não à afirmação de que o toolkit não tenha nenhum fluxo de eventos estruturado em outro lugar.

Isso soa como limitação, e em um aspecto é mesmo. Mas também significa que o Tika não tem como classificar errado algo que não tenta reinventar, e é exatamente essa a troca que seus primos mais barulhentos fazem na direção oposta.

A própria detecção segue uma ordem documentada: primeiro bytes de assinatura, depois inspeção da raiz XML, depois o padrão do nome do arquivo e, por fim, qualquer tipo fornecido por você (a documentação de detecção do Tika descreve isso). Só depois de resolver o tipo o dispatcher passa os bytes para o parser correspondente incluído no pacote — PDFBox, POI, jsoup, TextAndCSVParser para a família de texto.

Essa separação entre detectar e então fazer parse não é um detalhe interno. É por isso que um arquivo quebrado demais para ser parseado ainda pode ser corretamente tipado, o que 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 que não é exigente

A instalação é um download. O tika-app-3.3.2.jar do Maven Central tem cerca de 67 MB — um fat jar que inclui todos os parsers — e depois disso basta 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, um build não-LTS de ponta, e --version, --text, --metadata e --detect todos retornaram exit 0, sem reclamações de compatibilidade. Vale registrar isso porque, no mesmo host e na mesma sessão, eu também testei o Apache Nutch e o ciclo de crawl dele simplesmente não rodou no JDK 26 — ele precisa de um LTS na versão 21 ou inferior, por causa da remoção do SecurityManager em JDKs mais novos. O Tika não se importou. Se você tem evitado tooling em JVM por esse tipo específico de dor, o Tika não é onde isso pega.

Duas deduções honestas na parte de configuração. A CLI cria uma JVM nova a cada invocação, então o cold start é real — executar 131 invocações para meu harness levou cerca de um minuto, em grande parte de aquecimento do JVM. Se você vai processar arquivos em volume, quer a biblioteca ou o modo servidor, não um loop de shell em cima do jar. E a história de “sem dependências” tem um limite claro: a extração do texto da camada textual de PDFs não precisa de nada externo, mas OCR precisa de tesseract e poppler. PDFs com camada textual, DOCX, ODT, RTF, HTML, XML, TXT, Markdown e CSV foram parseados em uma máquina sem nenhum desses binários instalados. Documentos escaneados não teriam sido, e eu não tentei fingir o contrário.

Esse contraste fica ainda mais forte quando comparado à biblioteca irmã que testei no mesmo dia, unstructured, cujo caminho para PDFs eletrônicos foi bloqueado por completo porque importar o módulo de PDF puxa a stack de inferência (torch e similares) no carregamento — antes da escolha de estratégia, então até a estratégia "rápida" não importa sem isso. O Tika extraiu 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 do arquivo

Oito formatos, cada um apresentado com uma extensão correta, uma extensão errada de propósito, ou sem extensão, além de um fluxo de bytes sem nome via stdin. Isso resulta em 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, totalizando 48 execuções brutas; essas três linhas de stream se reduzem a uma única condição porque stdin não carrega nome de arquivo.

(A coluna de stream engloba 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 — acertaram o tipo real em 20 de 20 condições lógicas únicas (e 30 de 30 execuções brutas do harness, incluindo as repetições do stream). 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 significa que os cinco usem apenas assinaturas fixas: 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 da raiz. Em estes testes, a extensão mentirosa não venceu.

Depois vem o regime da família de texto. O Markdown só foi resolvido como text/markdown quando a extensão .md estava presente e legível. Renomeie, remova a extensão ou envie como stream, e ele caiu para text/plain neste teste. O CSV se comportou da mesma forma nessa grade intencionalmente pequena: text/csv só apareceu por causa do glob .csv. Contando condições únicas, Markdown e CSV cada um foi resolvido como seu tipo específico em uma de quatro condições; o texto simples já era text/plain, então não havia nada de que ele pudesse “cair”. O harness bruto de 48 execuções ainda é útil 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 text/plain, não application/pdf. O Tika não acreditou na mentira; apenas não conseguiu confirmar a verdade. Degradar para o tipo pai é uma 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 do parse — confirmado pela presença de TextAndCSVParser na cadeia X-TIKA:Parsed-By — minha grade pequena de 2 colunas por 3 linhas foi resolvida como text/plain em vez de text/csv. Isso é uma observação isolada em um fixture deliberadamente 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, nessa grade, 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 faturas, 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 uma extensão amigável.

Para os fixtures binários e de marcação testados aqui, o Tika roteou pelo conteúdo mesmo depois que o nome do arquivo desapareceu, o que é útil quando um blob store ou um handler de corpo HTTP descartou esse nome. Esse resultado não cobre a cauda longa do Tika, arquivos ambíguos ou poliglotos. Os fixtures da família de texto testados se comportaram de forma diferente: quando o pipeline retirou os nomes de arquivo, Markdown e CSV chegaram como text/plain, então regras baseadas nesses tipos de mídia específicos pararam de disparar. Preserve o nome original como metadado lateral, 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 ele se divide limpidamente 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 de encerramento) em HTML, Markdown, texto simples, DOCX, PDF, RTF, ODT e XML, além de um documento com tabela em HTML, Markdown, texto, DOCX, CSV e XML. Quatorze renderizações de carrier. Cada bloco carrega um token único — zztitle1, zzitem3, zztblcell_beta e assim por diante — então “sobreviveu” versus “sumiu” é uma verificação exata de substring, não uma avaliação subjetiva.

A lembrança dos tokens marcadores voltou 1.000 em todas as quatorze renderizações. Nenhum token inserido sumiu: todas as células de tabela, itens de lista e títulos marcados estavam presentes. Três repetições locais por carrier, após aquecimento, devolveram saída --text idêntica em bytes. Esse oráculo não diz nada sobre caracteres não marcados, ordem, espaçamento, 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.

Este é o documento de tabela HTML saindo de --text:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

Linhas separadas por tabulação. A linha do cabeçalho não é marcada como cabeçalho. Não há grade, nem limites de célula além de uma tabulação, nem como saber que aquilo já foi um <table>. A tabela em DOCX se achata do mesmo jeito.

As listas são mais sutis e se dividem conforme o que o texto original realmente continha:

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

O caso do Markdown deixa isso claro. Se você entregar ao Tika um arquivo .md com uma tabela em pipe, os pipes voltam literalmente, o que parece preservação da estrutura. Não é. O Tika o leu 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. A extração plana evita de propósito o problema da classificação de elementos; também não consegue satisfazer um consumidor downstream que precise desses tipos de elemento. Se você precisa de blocos tipados ou tabelas reconstruídas, --text é apenas um componente da pilha, não a pilha inteira. Outros handlers do Tika podem expor mais estrutura, mas ficaram fora desta rodada.

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

Metadados: normalizados e, felizmente, sem inventar nada

Incorporei valores conhecidos de autor, título e data de criação em todos os carriers que têm uma camada de metadados e depois verifiquei o que voltou.

Autor e título foram recuperados em 4 de 4 carriers com metadados, e — essa é a parte importante — eles são normalizados. Um <meta name="author"> de HTML, uma propriedade central de DOCX, uma entrada /Author de PDF e um elemento dc:creator de ODT chegam todos sob a mesma chave dc:creator. Você escreve um consumidor, não quatro.

created é a oscilação honesta. DOCX e ODT devolveram exatamente meu timestamp 2021 embutido. O PDF devolveu uma data de criação, mas era a data que a biblioteca geradora carimbou no build, não o valor que eu queria embutir — então eu o pontuo como presente, não recuperado. E os formatos sem camada de metadados não mostraram nada, o que é a resposta correta. O Tika não adivinha autor a partir do corpo do texto.

Quebrando de propósito, e o truque de triagem que sai disso

Quatro entradas hostis. Um arquivo de zero bytes. Um cabeçalho de 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 encoding. Essas são formas locais de fixture, não limites do Tika.

O harness subjacente, os fixtures gerados, o JSON bruto, o checksum do jar e o manifesto de ambiente não estão vinculados publicamente aqui, então um leitor externo não consegue reproduzir independentemente os denominadores exatos. Trate as tabelas como observações relatadas, e não como evidência verificável por terceiros.

A extração falha alto, e essas falhas têm o mesmo formato externo. O arquivo de zero bytes, o PDF truncado e o DOCX truncado produziram uma exceção, exit 1 e stdout vazio. A CLI não engole a falha e devolve um resultado vazio bonitinho. Seguro para o processo nesses casos — sem travar, sem segfault — mas o chamador precisa verificar o status de saída e o stderr, e não apenas procurar uma string vazia.

Detecção é desacoplada do parse. Nos dois binários truncados, --detect devolveu exit 0 com o tipo esperado a partir do conteúdo inicial intacto; depois o parser falhou no corpo quebrado. Um pipeline pode, portanto, usar a detecção como sinal de triagem separado, antes ou depois de um parse que falhou. Se detectar primeiro é um bom padrão por padrão 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 volume.

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

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

Ambos foram usados 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 em resultados diferentes.

Revisão relacionada: Revisão do Unstructured.

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

Nenhum de nós 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 lógicas ú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 dos carriers, inclusive as células de tabela e itens de lista marcados.
• Repetível em três novas execuções locais: cada carrier devolveu texto idêntico em bytes neste ambiente.
• Metadados normalizados entre formatos — dc:creator / dc:title / dcterms:created independentemente do formato de origem, recuperados em 4/4 carriers com metadados.
• Realmente sem dependências para os formatos que testei: camada textual de PDF, DOCX, ODT, RTF e HTML são parseados a partir de um único jar, sem binários externos.
• Roda limpo no OpenJDK 26 — sem limitação de apenas LTS.
• A detecção permanece correta (exit 0) em binários truncados, oferecendo um sinal confiável de triagem quando o parse falha.
• Apache-2.0, maduro e mantido ativamente.

Contras

• A identidade de Markdown e CSV depende inteiramente da extensão do arquivo; 10 de 18 células sem assinatura caíram para text/plain quando o nome do arquivo estava ausente ou errado.
• --text não retorna tipos de elemento; as grades das tabelas viraram linhas separadas por tabulação e os marcadores estruturais de lista desapareceram.
• A extração lança exceção sem tratar em entradas vazias e corrompidas; os dois casos parecem idênticos a partir da chamada de extração sozinha.
• 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 é verdade sintética 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.

Para quem serve, e para quem não serve

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 corpus para um LLM, construção da camada de validação de tipo de conteúdo em um pipeline de upload. Ele é útil como primeira etapa de triagem e normalização na frente de algo mais inteligente: detectar os tipos testados, extrair texto plano e encaminhar tudo com verificações explícitas para o conteúdo que seu pipeline não pode perder.

Evite-o — ou melhor, não pare em --text — se você precisa de elementos tipados, tabelas reconstruídas ou layout do documento. Evite-o 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 volume, compare a biblioteca ou o modo servidor com a CLI em documentos representativos. O tempo de inicialização do processo ficou visível neste harness de arquivos pequenos, mas throughput e custo de recursos não foram medidos.

O ponto 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 distingui-los de texto simples. Preserve o nome original.

Alternativas, e onde o Thunderbit se encaixa

Primeiro, um enquadramento justo, porque a comparação honesta aqui é sobre entradas, não sobre qualidade. O Tika é um toolkit gratuito, Apache-2.0 e auto-hospedado para fazer parsing de arquivos. Arquivos que você já tem em disco ou em um bucket. Ele não busca páginas, não executa JavaScript, não lida com anti-bot e nem finge fazer isso.

Esse é o limite em que um serviço gerenciado de extração web, incluindo o nosso Thunderbit, pode entrar na arquitetura: ele busca páginas ao vivo, enquanto o Tika faz parse de 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 limpa: Tika para documentos que você já possui, uma API de extração gerenciada para páginas web que você precisa buscar. Muitos pipelines usam os dois — rastreamento e extração no lado da web, Tika nos PDFs e DOCX que chegam depois como anexos.

Se você estiver comparando com o panorama mais amplo de open source, eu escrevi o comparativo completo de scrapers open source, uma análise dos projetos de scraping mais úteis no GitHub, uma revisão prática do Crawl4AI cobrindo a abordagem de Markdown com base em navegador, e um resumo mais amplo de ferramentas de scraping. Para o caminho sem código, há também um passo a passo sobre 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 se você valida os campos ou marcadores que seu próprio pipeline não pode perder.

O detector foi a parte mais forte deste teste. Ele retornou o tipo esperado em 20 de 20 condições lógicas únicas para os cinco fixtures detectáveis por conteúdo, incluindo streams sem nome de arquivo. Todos os marcadores inseridos sobreviveram nas quatorze renderizações, e a saída repetiu byte a 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 para os caminhos não-OCR testados, manteve a implantação agradavelmente sem drama.

Mas dimensione corretamente. Toda tabela enviada a ele volta como linhas separadas por tabulação. Todo marcador estrutural de lista desaparece. Markdown e CSV perdem sua identidade no momento em que o nome do arquivo some. Arquivos vazios e corrompidos disparam o mesmo tipo de falha, e você vai precisar da chamada separada detect para diferenciá-los. E quanto a OCR, a questão que muitos usuários do Tika mais se importam, eu não tenho nada a oferecer: não consegui executar e não vou estimar.

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 peça para ele dizer qual era a forma daqueles bytes.

Experimente o Thunderbit para Extração de Dados da Web Get Started Free

FAQs

O Apache Tika detecta corretamente tipos de arquivo quando a extensão está errada? Para os cinco fixtures detectáveis por conteúdo testados aqui, sim. PDF, DOCX, RTF, HTML e XML foram resolvidos para seus respectivos tipos de mídia 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 CSV dependeram de informação do nome do arquivo e caíram para text/plain quando ela estava ausente ou errada.

O Tika preserva tabelas e a estrutura do documento? Não no modo --text testado aqui. As grades de tabela voltaram como linhas separadas por tabulação, sem semântica de célula ou cabeçalho, e os marcadores estruturais de lista (<li> em HTML, estilo List Bullet em DOCX) desapareceram. Todos os marcadores inseridos sobreviveram nas 14 renderizações dos carriers, 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.

O Apache Tika faz OCR em PDFs escaneados? O Tika oferece OCR por meio do Tesseract, mas eu não testei isso, e nenhum destes resultados é uma afirmação sobre esse caminho. Tesseract e poppler não estavam presentes no meu host de teste, então todos os caminhos de OCR e de imagem escaneada foram bloqueados antes de rodar. Não há números de OCR em nenhum ponto deste teste. Se OCR é o seu caso de uso, instale o 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 TikaException vindo do PDFParser; um DOCX truncado lança um erro XML do POI. Os três retornam exit 1 com stdout vazio, então arquivo vazio e corrompido são indistinguíveis pela chamada de extração sozinha. 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 confiável de triagem antes de gastar processamento com o parse.

O que os testes do Tika não cobriram? Quatro coisas, explicitamente. 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 em relação a rótulos conhecidos, e não precisão em documentos reais bagunçados. Custo de recursos, throughput e pico de memória, que eu não medi. E a cauda longa da alegação de “mil tipos de arquivo”: testei nove formatos representativos e sem dependências externas, não o catálogo completo. Tudo aqui é Tika 3.3.2 no OpenJDK 26.0.1, macOS arm64, em uma única máquina.