Extraer tablas de un PDF a Markdown
Pregunta a cualquiera que convierta PDF con regularidad qué es lo que más se rompe, y la respuesta casi siempre es la misma: las tablas. Los encabezados, los párrafos y las listas se convierten de forma fiable; las tablas son la parte que hay que revisar a ojo cada vez.
Este artículo explica por qué las tablas son estructuralmente difíciles en el formato PDF, cómo los conversores modernos las reconstruyen en pipe tables de Markdown, qué características de las tablas Markdown no puede expresar en absoluto y cómo verificar una tabla convertida en lugar de confiar ciegamente.
El PDF no tiene tablas: ese es todo el problema
Los documentos de Word, las páginas HTML y las hojas de cálculo tienen un objeto de tabla real: filas, columnas, celdas, combinaciones. El formato PDF no tiene nada de eso. Lo que parece una tabla en un PDF es un conjunto de fragmentos de texto colocados en coordenadas, más, opcionalmente, algunas líneas y rectángulos dibujados cerca.
Eso significa que extraer una tabla no es recuperarla, es inferirla. El conversor debe decidir qué fragmentos pertenecen a la misma fila, a qué columna pertenece cada uno, si una línea cercana es un borde de celda o una decoración de página, y dónde termina la tabla y comienza el siguiente párrafo.
Esto también explica por qué la misma tabla se convierte a la perfección en un PDF y mal en otro. La diferencia no está en la complejidad de la tabla, sino en cuánta evidencia aporta el documento: líneas explícitas y una alineación consistente le dan al detector algo con lo que trabajar, y su ausencia obliga a adivinar.
Tablas con líneas frente a tablas de espacios en blanco
Las tablas con líneas, las que tienen líneas visibles entre celdas, son el caso sencillo. Las líneas dividen la página en regiones, cada región contiene el texto de una celda, y el problema de reconocimiento de estructura se reduce al orden de lectura dentro de una cuadrícula conocida. La mayoría de los conversores, incluido el de este sitio, las manejan bien.
Las tablas sin bordes, alineadas por espacios, son lo contrario. Sin líneas por las que segmentar, el detector agrupa los fragmentos de texto por sus coordenadas: los fragmentos cuyas líneas de base se alinean forman una fila; los que se agrupan en posiciones x, una columna. Una alineación incluso ligeramente inconsistente —una celda desplazada dos puntos de su columna— puede derivar en valores mal asignados.
Los estados financieros exportados desde software de informes suelen llevar líneas y se convierten limpiamente. Las tablas pegadas desde presentaciones, las compuestas solo con espaciado y las partidas entre páginas con encabezados repetidos son los casos sin bordes y fragmentados en los que la inspección no es negociable.
Cómo el reconocimiento de estructura reconstruye la cuadrícula
El motor PDF detrás del conversor de este sitio realiza el reconocimiento de estructura de tablas como parte de la extracción: detecta las regiones de tabla en la página, las segmenta en filas y columnas, asigna cada fragmento de texto a una celda y emite el resultado como una pipe table de Markdown con estilo GitHub.
Esa salida es el denominador común honesto, con pérdidas pero útil. Una pipe table conserva la semántica esencial —qué valor pertenece a qué encabezado de fila y columna— mientras descarta detalles visuales como anchos de columna, sombreado de celdas y alineación, que Markdown no tiene forma de registrar.
La calidad del reconocimiento en los benchmarks públicos de extracción de tablas ha mejorado enormemente en los últimos años, y motores como este puntúan muy por encima del enfoque ingenuo de copiar un PDF y pegarlo. Pero una puntuación de benchmark es un promedio, y tu tabla puede estar por debajo. A continuación hay consejos de verificación, y existen por una razón.
Lo que llega a tu Markdown
Una conversión limpia se ve exactamente como lo que escribiría una persona: una fila de encabezado, una línea separadora y una fila de pipes por fila de datos. Las celdas vacías permanecen vacías, las columnas numéricas conservan sus valores y la tabla se renderiza como una tabla de verdad en GitHub, en Obsidian y en cualquier renderizador de Markdown convencional.
El contexto que la rodea también sobrevive. El párrafo sobre la tabla, el título de la tabla si estaba compuesto como texto normal y las notas al pie debajo se convierten como contenido normal, de modo que la tabla conserva su contexto en lugar de quedar flotando sin explicación.
Lo que no sobrevive es cualquier estructura bidimensional más allá de filas y columnas. Los grupos de columnas, las filas de resumen que abarcan todo el ancho y los subencabezados anidados se aplastan en filas adicionales o se funden en el texto de las celdas. Los datos siguen ahí; la forma que tenían en el original, no.
Celdas combinadas y otros límites de GFM
Las pipe tables de Markdown con estilo GitHub son deliberadamente mínimas. Tienen exactamente una fila de encabezado, sin combinación de celdas, sin combinación de filas y sin alineación más allá de izquierda/centro/derecha por columna. Cualquier cosa más rica en el PDF de origen debe aplanarse para encajar.
Una celda combinada en tres columnas se convierte en texto en la primera celda y celdas vacías después, o en texto repetido en cada una. Un encabezado de dos niveles se convierte en una sola fila de encabezado donde los niveles se unen, a veces con un separador. Si ese aplanamiento es aceptable depende por completo de lo que hagas después: legible en un documento, con pérdidas en una importación a hoja de cálculo.
Si el destino realmente necesita la estructura combinada, la tabla ha superado a Markdown, no al conversor. Exportar CSV desde la fuente original, o la propia importación de PDF de una herramienta de hojas de cálculo, es el mejor camino para esa tabla: no se debe obligar a un conversor a fingir que la semántica sobrevivió.
Haz comprobaciones puntuales de los números
Los modos de fallo de la conversión de tablas son silenciosos por naturaleza. Una columna desplazada se renderiza como una tabla perfectamente normal con un valor en el lugar equivocado. Una fila partida por un salto de página puede convertirse en dos filas. Un signo menos leído como un guion convierte un negativo en positivo sin cambiar el aspecto de la tabla.
Así que verifica en proporción a las consecuencias. Para una tabla en una entrada de blog, échale un vistazo renderizada. Para una tabla financiera o científica que alimenta un informe, compara el recuento de filas, las sumas de columnas y una muestra aleatoria de celdas con el original. Para cualquier cosa que alimente un modelo o una base de datos, esta comprobación forma parte del pipeline, no es un paso opcional.
El conversor ayuda donde puede: las páginas cuyas tablas parecen necesitar revisión se marcan en las advertencias de conversión en lugar de pasarse por alto en silencio. Trata esas marcas como señales hacia exactamente las filas que conviene comprobar primero.
Enviar las tablas más lejos con Pandoc
Una vez que una tabla es una pipe table de Markdown, es ciudadana de primera clase del motor Pandoc que impulsa los demás formatos de salida de este sitio. Elige la salida HTML y la tabla se convierte en marcado <table> real; elige LaTeX y se convierte en un tabular; elige RST y se convierte en sintaxis grid.
Esa segunda etapa no tiene pérdidas en el sentido de que Pandoc analiza la pipe table en un modelo de documento antes de escribir, de modo que la alineación de columnas y la estructura del encabezado se conservan en cada formato. Lo que se perdió en el paso de PDF a Markdown no vuelve, pero tampoco se pierde nada más.
En la mayoría de los flujos de trabajo la cadena se detiene en Markdown porque es lo que habla el destino. Cuando no lo es —un artículo en LaTeX, un sitio en Sphinx—, la ruta de conversión ya está ahí, a un desplegable de distancia, ejecutándose en el mismo pipeline local y privado.