Reseña de Apache Tika: lee los bytes, no el nombre del archivo... hasta que se topa con Markdown

Apache Tika es el kit de herramientas de análisis de documentos de la Apache Software Foundation: tú le pasas un archivo de casi cualquier formato y te devuelve texto plano junto con un diccionario de metadatos normalizado. El README del proyecto anuncia compatibilidad con más de mil tipos de archivo, y Tika lo logra integrando por su cuenta bibliotecas especializadas —PDFBox para PDF, Apache POI para documentos de Office, jsoup para HTML, un lector ODF para ODT—, de modo que todo se distribuye como un único JAR enorme sin necesidad de descargar nada en tiempo de análisis. En una canalización de datos, su papel no es vistoso, pero sí clave: suele ser el primer paso antes de un índice de búsqueda, un conjunto de revisión para e-discovery o un corpus para un LLM, convirtiendo un montón heterogéneo de archivos en algo uniforme. En el fondo son dos tareas: identificar qué es un flujo de bytes y luego extraer de él el texto y los metadatos.

Es la herramienta que menos exigencias me ha dado en mucho tiempo. Un solo JAR, java -jar tika-app-3.3.2.jar --text file.pdf, sin archivo de configuración, sin pesos de modelos, sin pasos posteriores a la instalación, y funcionó sin problemas sobre un JDK de última generación que dejó tiradas a otras herramientas Java en la misma máquina esa misma tarde. Sin embargo, la afirmación del catálogo no era lo que quería poner a prueba; la pregunta interesante es más concreta. Cuando la entrada te miente, ¿qué hace realmente Tika? Así que preparé un conjunto de pruebas controlado en el que cada bloque de contenido llevaba un token distintivo, rendericé el mismo documento lógico en nueve formatos contenedores y luego ataqué todo con extensiones incorrectas, extensiones faltantes, archivos sin nombre, archivos de cero bytes y binarios truncados.

La detección es donde aparece el comportamiento más interesante. Renombré un PDF a .txt y le pregunté a Tika qué era; respondió application/pdf. Luego eliminé por completo el nombre del archivo, pasé los bytes en bruto por stdin y obtuve la misma respuesta. En los cinco formatos detectables por contenido de mi conjunto, eso se cumplió en las 20 condiciones lógicas únicas: tres condiciones de nombre de archivo más una condición de flujo sin nombre por formato. El arnés ejecutó el caso de flujo tres veces con distintas etiquetas, produciendo 30 ejecuciones en bruto correctas, pero esos repetidos no son evidencia independiente. PDF y RTF exponen bytes reconocibles; DOCX expone su contenedor; HTML y XML pueden identificarse por el marcado o el contenido raíz. Mecanismos distintos, mismo resultado útil en este conjunto de pruebas: la extensión no se impuso al contenido. Luego está el régimen de la familia de texto, donde Markdown cae a text/plain en cuanto el nombre del archivo es incorrecto o desaparece. Aquí, su identidad dependía por completo de .md.

Dos límites para todo lo que sigue. Probé Apache Tika 3.3.2 —verificado el 27 de julio de 2026; seguía siendo la versión estable más reciente en ese momento—; la línea 4.0.0 existe solo como compilaciones alfa y beta en Maven Central. El proyecto rondaba las 3,9k estrellas en GitHub cuando lo comprobé el 27 de julio de 2026, y tiene licencia Apache-2.0, lo cual es tan poco problemático para uso comercial como puede ser una licencia. Y no probé OCR en absoluto. Ni una página escaneada, ni un PDF de solo imagen. Tesseract y poppler no están instalados en la máquina en la que ejecuté estas pruebas, así que cualquier ruta de OCR quedó bloqueada antes de empezar. Aquí no hay cifras de OCR porque no hay cifras de OCR, punto.

Qué es Tika, una vez que dejas de leer el marketing de la caja

La suposición habitual es que Apache Tika es un convertidor de documentos: le das un DOCX y te devuelve Markdown limpio, con encabezados y tablas intactos. No es eso, y cuanto antes quede claro, mejor se entiende la herramienta.

La ruta evaluada aquí tiene tres etapas relevantes: un detector de tipo de contenido, un despachador que envía los bytes al parser adecuado y el manejador de salida --text de la CLI, que emite texto plano junto con metadatos disponibles por separado. En ese contrato de salida no hay objetos Title, ni ListItem, ni una rejilla de tabla reconstruida. Tika también expone otros manejadores y APIs, incluida salida orientada a XHTML/SAX; no los probé. Por tanto, cualquier conclusión sobre estructura más abajo se refiere a tika-app --text, no a una afirmación de que el toolkit carezca de un flujo de eventos estructurado en cualquier contexto.

Eso suena a limitación, y en cierto sentido lo es. Pero también significa que Tika no tiene nada que clasificar mal, y precisamente ese es el intercambio que hacen sus equivalentes más ruidosos en la dirección contraria.

La detección sigue un orden documentado: primero bytes de firma, luego inspección de la raíz XML, después el comodín del nombre de archivo y, por último, cualquier tipo que hayas indicado tú mismo (la documentación de detección de Tika lo explica así). Solo cuando el tipo queda resuelto el despachador entrega los bytes al parser integrado correspondiente —PDFBox, POI, jsoup, TextAndCSVParser para la familia de texto.

Esa separación entre detectar y analizar no es una curiosidad interna. Es la razón por la que un archivo demasiado dañado para parsearse aún puede identificarse correctamente, y eso se convierte en el truco más práctico que ofrece Tika cuando las cosas empiezan a romperse.

Configuración: un JAR, un comando y una JVM que no se pone exquisita

La instalación es una descarga. tika-app-3.3.2.jar desde Maven Central pesa unos 67 MB —un JAR enorme que empaqueta todos los parsers—, y después solo queda java -jar tika-app-3.3.2.jar --text file.pdf. Sin archivo de configuración, sin pesos de modelos, sin pasos posteriores a la instalación, sin una cadena de brew install que recorrer.

La historia del JDK me sorprendió. Ejecuté todo sobre OpenJDK 26.0.1, una compilación no LTS de última generación, y --version, --text, --metadata y --detect devolvieron todos código de salida 0 sin quejas de compatibilidad. Vale la pena decirlo, porque el mismo día puse a prueba Apache Nutch en la misma máquina y su ciclo de rastreo no funcionó en absoluto sobre JDK 26: necesita una LTS de 21 o inferior, debido a la eliminación de SecurityManager en JDK recientes. Tika no se inmutó. Si has evitado herramientas JVM por ese tipo concreto de dolor, Tika no es donde te va a morder.

Dos conclusiones honestas sobre la configuración. La CLI arranca una JVM nueva en cada invocación, así que el arranque en frío es real: 131 invocaciones de mi arnés tardaron alrededor de un minuto, casi todo en calentamiento de la JVM. Si vas a procesar archivos a gran escala, te interesa la biblioteca o el modo servidor, no un bucle de shell sobre el JAR. Y la historia de “sin dependencias” tiene un matiz importante: la extracción de texto de la capa PDF no necesita nada externo, pero el OCR sí requiere tesseract y poppler. PDFs con capa de texto, DOCX, ODT, RTF, HTML, XML, TXT, Markdown y CSV se analizaron en una máquina sin ninguno de esos binarios. Los documentos escaneados no habrían funcionado, y no intenté fingir lo contrario.

Ese contraste se nota más frente a la biblioteca hermana que probé el mismo día, unstructured, cuya ruta para PDFs electrónicos quedó bloqueada por completo porque importar su módulo de PDF arrastra la pila de inferencia (torch y compañía) al cargar, antes del despacho por estrategia; así que incluso la estrategia “rápida” no llega a importarse sin eso. Tika, en cambio, analizó la capa de texto del mismo PDF con un simple java -jar.

La prueba de la extensión mentirosa: detección MIME que ignora cómo llamaste al archivo

Ocho formatos, cada uno presentado con una extensión correcta, una extensión incorrecta a propósito o sin extensión, además de un flujo de bytes sin nombre por stdin. Eso da 32 condiciones lógicas únicas. El arnés original también ejecutó los mismos bytes de flujo una vez bajo cada etiqueta de nombre de archivo, lo que produce 48 ejecuciones en bruto; esas tres filas de flujo se reducen a una sola condición porque stdin no lleva nombre de archivo.

(La columna de flujo colapsa las tres condiciones de extensión, porque sin nombre de archivo no hay nada que el comodín pueda leer.)

Los cinco formatos detectables por contenido —PDF, DOCX, RTF, HTML y XML— acertaron el tipo real en 20 de 20 condiciones lógicas únicas (y 30 de 30 ejecuciones en bruto del arnés, incluidas las repeticiones del flujo). Un PDF llamado report.txt siguió siendo PDF. Un DOCX llamado photo.jpg siguió siendo DOCX. Ninguno necesitó nombre de archivo. Esto no significa que los cinco usen firmas fijas de bytes: PDF y RTF tienen encabezados reconocibles, DOCX es un contenedor basado en ZIP, y HTML/XML se detectan por el marcado o por el contenido raíz. En estas pruebas, la extensión mentirosa no ganó.

Después viene el régimen de la familia de texto. Markdown solo se resolvió como text/markdown cuando la extensión .md estaba presente y era legible. Renómbralo, quita la extensión o envíalo como flujo, y en esta prueba cayó a text/plain. CSV se comportó igual en esta rejilla deliberadamente pequeña: text/csv solo apareció gracias al comodín de .csv. Contando condiciones únicas, Markdown y CSV resolvieron su tipo específico en una de cuatro condiciones cada uno; el texto plano ya era text/plain, así que no había nada desde lo que pudiera “colapsar”. El arnés de 48 ejecuciones en bruto sigue siendo útil como registro de repetibilidad, pero no como denominador más grande.

Un detalle juega a favor de Tika aquí: la extensión mentirosa tampoco gana. Mi fixture de Markdown renombrado a .pdf devolvió text/plain, no application/pdf. Tika no creyó la mentira; simplemente no pudo confirmar la verdad. Degradar al tipo padre es un fallo mucho mejor que afirmar con seguridad algo incorrecto, y que text/markdown sea un subtipo documentado de text/plain hace que esa salida sea principiada y no arbitraria.

Hay una salvedad específica con CSV. Tika tiene un detector estadístico de CSV y, en tiempo de análisis —confirmado por la aparición de TextAndCSVParser en la cadena X-TIKA:Parsed-By—, mi rejilla pequeña de 2 columnas por 3 filas se resolvió como text/plain y no como text/csv. Es una sola observación sobre un fixture deliberadamente mínimo. Un CSV más grande o con comillas quizá active el detector. No estoy diciendo que la detección por contenido de CSV esté rota; estoy diciendo que, en esta rejilla, la extensión fue lo que produjo text/csv.

Por qué esto importa en una canalización real de subidas

El escenario concreto es un enrutador de cargas. Supón que aceptas archivos subidos por usuarios y los encaminas por tipo: PDF al analizador de facturas, hojas de cálculo al importador contable, y todo lo demás a un índice de texto. Si confías en la extensión, un PDF llamado notes.txt irá a la rama equivocada —y ese es el caso benigno; la versión hostil es un archivo poliglota con una extensión amistosa.

Para los fixtures binarios y de marcado probados aquí, Tika enrutó por contenido incluso después de desaparecer el nombre del archivo, lo cual es útil cuando un almacén de blobs o un manejador de cuerpos HTTP lo ha eliminado. Ese resultado no cubre la larga cola de Tika, archivos ambiguos ni poliglotas. Los fixtures de la familia de texto se comportaron de otra manera: cuando la canalización eliminó los nombres de archivo, Markdown y CSV llegaron como text/plain, así que las reglas basadas en sus tipos MIME específicos dejaron de activarse. Conserva el nombre original como metadato auxiliar en lugar de esperar que la detección por contenido lo reconstruya.

El contenido sembrado sobrevivió. --text aplanó la estructura.

La fidelidad es el segundo eje, y aquí se divide claramente en dos. Rendericé un documento canónico (encabezados, dos párrafos de cuerpo, una lista con viñetas, una lista numerada y un párrafo final) a HTML, Markdown, texto plano, DOCX, PDF, RTF, ODT y XML, además de un documento de tabla a HTML, Markdown, texto, DOCX, CSV y XML. Catorce renderizaciones contenedoras. Cada bloque lleva un token único —zztitle1, zzitem3, zztblcell_beta, etc.—, así que “sobrevivió” frente a “se perdió” es una comprobación exacta de subcadenas, no una apreciación subjetiva.

La recuperación de tokens marcadores fue 1.000 en las catorce renderizaciones. No se perdió ni un solo token sembrado: cada celda de tabla, elemento de lista y encabezado etiquetado estaba presente. Tres repeticiones locales por contenedor, tras el calentamiento, devolvieron una salida --text idéntica a nivel de bytes. Este oráculo no dice nada sobre caracteres sin etiqueta, orden, espacios en blanco, normalización Unicode, contenido repetido, enlaces, encabezados, notas al pie u objetos incrustados. Es una comprobación de presencia de bloques, no una prueba de fidelidad total del documento.

La salida de texto plano renuncia a la mayor parte de la estructura de origen.

Así sale por --text este documento de tabla en HTML:

	Tool	Throughput

	zztblcell_alpha	120

	zztblcell_beta	95

Líneas unidas por tabuladores. La fila de encabezado no se marca como encabezado. No hay cuadrícula, no hay límites de celda más allá de un tabulador, y no hay forma de saber que eso fue alguna vez un <table>. La tabla de DOCX se aplanó igual.

Las listas son más sutiles, y se dividen según lo que el origen contenía realmente:

Tika nunca vuelve a dibujar un marcador que no recibió como texto. El mismo contenido, dos salidas distintas.

El caso de Markdown lo deja claro. Si le das a Tika un archivo .md con una tabla de barras verticales, las barras vuelven literalmente, lo que parece preservación de estructura. No lo es. Tika lo analizó como texto y devolvió los bytes. Nada entendió esa tabla.

Así que el contrato medido es más estrecho: todos los marcadores sembrados sobrevivieron, pero --text no conservó elementos tipados ni una rejilla de tabla reconstruible. Llamar a eso un defecto del parser sería perder el punto. La extracción plana evita deliberadamente el problema de clasificar elementos; también es incapaz de satisfacer a un consumidor posterior que necesite esos tipos de elemento. Si necesitas bloques tipados o tablas reconstruidas, --text es un componente de la pila, no la pila completa. Otros manejadores de Tika pueden exponer más estructura, pero quedaron fuera de esta ejecución.

La advertencia estándar para cada cifra de fidelidad aquí: proceden de fixtures sintéticos controlados, en una sola máquina, con una sola versión y un solo JDK. Muestran que los bloques etiquetados estaban presentes en la salida. No demuestran preservación carácter por carácter ni precisión sobre un corpus real y desordenado.

Metadatos: normalizados y, de forma muy refrescante, sin inventarse cosas

Incorporé valores conocidos de autor, título y fecha de creación en cada contenedor que tiene una capa de metadatos, y luego comprobé qué regresaba.

El autor y el título se recuperaron en 4 de 4 contenedores con metadatos, y —esta es la parte valiosa— se normalizan. Un <meta name="author"> de HTML, una propiedad principal de DOCX, una entrada /Author de PDF y un elemento dc:creator de ODT llegan todos bajo la misma clave dc:creator. Escribes un único consumidor, no cuatro.

created es la única oscilación honesta. DOCX y ODT devolvieron mi timestamp exacto de 2021 incrustado. El PDF devolvió una fecha de creación, pero era la que estampó mi biblioteca generadora en tiempo de compilación, no el valor que quería incrustar; por eso la califico como presente, no recuperada. Y los formatos sin capa de metadatos no mostraron nada, que es la respuesta correcta. Tika no adivina un autor a partir del cuerpo del texto.

Romperlo a propósito y el truco de triaje que sale de ahí

Cuatro entradas hostiles. Un archivo de cero bytes. Un encabezado PDF válido con el cuerpo cortado. Un ZIP de DOCX truncado. Y un archivo UTF-8 con caracteres multibyte, sin BOM y sin declaración de codificación. Son formas locales de fixture, no umbrales de Tika.

El arnés subyacente, los fixtures generados, el JSON bruto, la suma de comprobación del JAR y el manifiesto del entorno no están enlazados en este borrador. Por tanto, un lector externo no puede reproducir de forma independiente los denominadores exactos todavía. Trate las tablas como observaciones reportadas; la publicación debería adjuntar un paquete estable antes de usar estas cifras como evidencia ante terceros.

La extracción falla en voz alta, y estos fallos comparten la misma forma externa. El archivo de 0 bytes, el PDF truncado y el DOCX truncado produjeron cada uno una excepción, exit 1 y stdout vacío. La CLI no disfraza el fallo como un resultado vacío ordenado. Son casos seguros para el proceso —sin cuelgues ni segfaults—, pero el llamador debe comprobar el estado de salida y stderr, no solo buscar una cadena vacía.

La detección está desacoplada del análisis. En ambos binarios truncados, --detect devolvió exit 0 con el tipo esperado a partir del contenido inicial intacto; después el parser falló sobre el cuerpo roto. Por tanto, una canalización puede usar la detección como señal de triaje separada, antes o después de un análisis fallido. Que detectar primero sea el mejor valor por defecto depende del modo de despliegue: esta prueba no comparó detect-first frente a parse-only, y dos JVM nuevas por invocación quizá sean el precio equivocado a gran escala.

La detección de codificación funciona. El archivo UTF-8 sin BOM ni declaración se decodificó como UTF-8 y 日本語テスト salió intacto. Un pequeño matiz para quien lea los diccionarios de metadatos: mis fixtures puramente ASCII reportan charset=ISO-8859-1, algo indistinguible de UTF-8 sobre bytes ASCII. Eso no es un fallo, es un empate.

Tika frente a unstructured: mismos tipos de archivo, trabajos distintos

A ambos se les ejercitó en la misma sesión de investigación, pero esto es una taxonomía de contratos de salida, no un benchmark simétrico. Las herramientas se puntuaron sobre resultados distintos.

Reseña relacionada: Reseña de Unstructured.

Salida plana que preserva marcadores frente a elementos tipados con errores observados de clasificación. Elige según lo que necesite el consumidor final. Si es un índice de búsqueda o una ventana de contexto para un LLM, quizá el texto plano baste. Si depende del tipo de elemento, la ruta --text de Tika no puede ofrecer ese contrato.

Ninguno de los dos tiene números de documentos escaneados.

Pros y contras

Pros

• La detección de tipo de contenido ignoró nombres de archivo mentirosos en 20/20 condiciones lógicas únicas de los cinco fixtures detectables por contenido; las ejecuciones de flujo duplicadas también coincidieron.
• Todos los marcadores sembrados sobrevivieron en las 14 renderizaciones de contenedor, incluidas las celdas de tabla y elementos de lista etiquetados.
• Repetible en tres repeticiones locales: cada contenedor devolvió texto idéntico a nivel de bytes dentro de este entorno.
• Metadatos normalizados entre formatos —dc:creator / dc:title / dcterms:created independientemente del formato de origen, recuperados en 4/4 contenedores con metadatos.
• Realmente sin dependencias para los formatos que probé: la capa de texto de PDF, DOCX, ODT, RTF y HTML se analiza con un solo JAR sin binarios externos.
• Funciona sin problemas sobre OpenJDK 26, sin exigir LTS.
• La detección sigue siendo correcta (exit 0) en binarios truncados, lo que te da una señal de triaje fiable cuando falla el análisis.
• Apache-2.0, maduro y mantenido activamente.

Contras

• La identidad de Markdown y CSV depende por completo de la extensión del archivo; 10 de 18 celdas sin firma colapsaron a text/plain cuando el nombre faltaba o era incorrecto.
• --text no devuelve tipos de elemento; las cuadrículas de tabla se aplanan a líneas unidas por tabuladores y desaparecen los marcadores estructurales de lista.
• La extracción lanza excepciones no capturadas en entradas vacías y corruptas; los dos casos parecen idénticos si solo miras la llamada de extracción.
• JAR de 67 MB más arranque en frío de una JVM por invocación en modo CLI.
• OCR y PDFs escaneados no se probaron en absoluto aquí —faltaban tesseract y poppler, así que no se hace ninguna afirmación sobre esa ruta.
• Cada cifra aquí procede de ground truth sintético en una sola máquina y una sola versión. No se midieron precisión sobre corpus real, archivos cifrados, documentos incrustados/recursivos ni rendimiento a escala.

Quién debería usarlo y quién no

Tika encaja cuando tu entrada son archivos que ya tienes y tu salida necesita ser texto más metadatos que una máquina pueda indexar. Indexación de búsqueda, e-discovery, procesamiento de archivos, alimentar un corpus a un LLM, construir la capa de validación de tipos de contenido en una canalización de subidas. Es útil como primera etapa de triaje y normalización delante de algo más inteligente: detecta los tipos probados, extrae texto plano y lo entrega con comprobaciones explícitas sobre el contenido que tu canalización no puede permitirse perder.

Sáltatelo —o, mejor dicho, no te quedes en --text— si necesitas elementos tipados, tablas reconstruidas o diseño de documento. Sáltatelo si tus documentos son escaneos, al menos hasta que instales tesseract y hagas tus propios números, porque yo no tengo ninguno. Para trabajo a volumen, compara la biblioteca o el modo servidor frente a la CLI con documentos representativos. En este arnés de archivos pequeños se notó el arranque del proceso, pero no se midieron rendimiento ni coste de recursos.

La trampa habitual: si tu capa de almacenamiento elimina los nombres de archivo y trabajas con Markdown o CSV, no confíes en que Tika los distinga del texto plano. Conserva el nombre original.

Alternativas y dónde encaja Thunderbit

Primero, el encuadre honesto: la comparación aquí va de entradas, no de calidad. Tika es un toolkit gratuito, Apache-2.0 y autogestionado para analizar archivos. Archivos que ya tienes en disco o en un bucket. No recupera páginas web, no ejecuta JavaScript, no se ocupa del anti-bot y no pretende hacerlo.

Ese es el límite en el que puede entrar un servicio gestionado de extracción web, incluido nuestro propio Thunderbit: recupera páginas en vivo, mientras Tika analiza archivos que ya están en tu poder. Este artículo no comparó esos servicios con Tika y no son sustitutos para la misma entrada.

La división limpia: Tika para documentos que ya tienes, una API gestionada de extracción para páginas web que necesitas ir a buscar. Muchísimas canalizaciones usan ambos —rastreo y extracción en la parte web, Tika para los adjuntos PDF y DOCX que regresan.

Si comparas el panorama open source más amplio, he publicado la comparación completa de scrapers open source, una revisión de los proyectos de scraping más útiles en GitHub, una reseña práctica de Crawl4AI que cubre el enfoque Markdown apoyado en navegador, y un resumen más amplio de herramientas de scraping. Para la ruta sin código, también hay una guía sobre cómo extraer un sitio con IA.

Prueba Thunderbit para extraer datos web

Veredicto

¿Deberías usar Apache Tika? Sí, si tu trabajo consiste en convertir archivos heterogéneos en texto plano y metadatos normalizados, y validas los campos o marcadores que tu propia canalización no puede permitirse perder.

El detector fue la mejor parte de esta prueba. Devolvió el tipo esperado en 20 de 20 condiciones lógicas únicas para los cinco fixtures detectables por contenido, incluidos los flujos sin nombre de archivo. Todos los marcadores sembrados sobrevivieron en las catorce renderizaciones, y la salida se repitió byte a byte en tres repeticiones locales. Evidencia útil. Sigue siendo evidencia sintética. Hacerlo desde un solo JAR en este JDK, sin binarios externos para las rutas no OCR probadas, mantuvo el despliegue agradablemente aburrido.

Eso sí, hay que dimensionarlo bien. Cada tabla que le pasas vuelve como líneas unidas por tabuladores. Desaparece todo marcador estructural de lista. Markdown y CSV pierden su identidad en cuanto el nombre del archivo desaparece. Los archivos vacíos y corruptos lanzan el mismo tipo de fallo, y necesitarás la llamada separada a detect para distinguirlos. Y sobre OCR, la pregunta que más interesa a muchos usuarios de Tika, no tengo nada que aportar: no pude ejecutarlo y no voy a estimarlo.

Dentro de esos límites, Tika hace un trabajo poco glamuroso con una fiabilidad poco común. Lee los bytes, no la etiqueta de la caja. Solo no le preguntes qué forma tenían esos bytes.

Prueba Thunderbit para extraer datos web Get Started Free

Preguntas frecuentes

¿Apache Tika detecta correctamente los tipos de archivo si la extensión es incorrecta? Para los cinco fixtures detectables por contenido probados aquí, sí. PDF, DOCX, RTF, HTML y XML resolvieron al tipo de medio esperado en las 20 condiciones lógicas únicas (30 ejecuciones en bruto con flujos duplicados), incluidas extensiones engañosas, ausencia de extensión y flujos sin nombre de archivo. Un PDF llamado .txt siguió detectándose como application/pdf. Markdown y el pequeño fixture de CSV dependieron de la información del nombre de archivo y cayeron a text/plain cuando faltaba o era incorrecta.

¿Tika preserva las tablas y la estructura del documento? No en el modo --text que se probó aquí. Las cuadrículas de tabla volvieron como líneas unidas por tabuladores, sin semántica de celda ni de encabezado, y los marcadores estructurales de lista (un <li> de HTML, un estilo List Bullet de DOCX) desaparecieron. Todos los marcadores sembrados sobrevivieron en las 14 renderizaciones de contenedor, pero eso no demuestra fidelidad completa del contenido, y --text no ofrece tipado de elementos. Para elementos tipados o tablas reconstruidas, prueba otro manejador de salida de Tika o usa otra herramienta junto a ella.

¿Puede Apache Tika hacer OCR en PDFs escaneados? Tika admite OCR mediante Tesseract, pero no lo probé y ninguno de estos resultados es una afirmación sobre ello. Tesseract y poppler no estaban presentes en mi host de pruebas, así que todas las rutas de OCR y de imágenes escaneadas quedaron bloqueadas antes de ejecutarse. No hay cifras de OCR en ninguna parte de esta prueba. Si tu caso de uso es OCR, instala tesseract y haz tus propios benchmarks; considera esa parte de Tika como no verificada aquí.

¿Qué hace Tika con archivos vacíos o corruptos? Falla de forma explícita en lugar de hacerlo en silencio. Un archivo de 0 bytes lanza ZeroByteFileException; un PDF truncado lanza una TikaException desde PDFParser; un DOCX truncado lanza un error XML de POI. Los tres devuelven exit 1 con stdout vacío, así que vacío y corrupto son indistinguibles solo desde la llamada de extracción. La detección, en cambio, se mantiene robusta: --detect devolvió exit 0 con el tipo correcto en ambos binarios truncados, lo que lo convierte en un paso de triaje fiable antes de gastar un parse.

¿Qué no cubrieron las pruebas de Tika? Cuatro cosas, de forma explícita. OCR e imágenes escaneadas (bloqueadas, no probadas). La precisión sobre corpus real: todos los resultados son fixtures sintéticos controlados con tokens marcadores sembrados, lo que mide fidelidad respecto a etiquetas conocidas y no precisión sobre documentos reales desordenados. Coste de recursos, rendimiento y memoria pico, que no medí. Y la larga cola de la afirmación de los “mil tipos de archivo”: probé nueve formatos representativos y sin dependencias, no el catálogo completo. Todo lo que hay aquí corresponde a Tika 3.3.2 sobre OpenJDK 26.0.1, macOS arm64, en una sola máquina.