Convertir CSV a Markdown en línea gratis

Convertir CSV a tabla Markdown: hacer legible para un modelo una exportación de hoja de cálculo

Un CSV en crudo es técnicamente legible para un modelo de lenguaje. También es una forma pésima de darle datos. Cada fila es una ristra de valores separados por comas sin ningún anclaje visual, el encabezado aparece una sola vez arriba del todo y, para cuando llega a la fila cuarenta, el modelo está contando comas para averiguar qué campo es cuál. Pregúntale «cuál fue el margen del tercer producto» y te dará una respuesta rotundamente equivocada sobre en qué columna vive el margen.

Una tabla Markdown de barras verticales arregla eso. Las columnas quedan alineadas, la fila de encabezado se marca explícitamente como tal gracias a la línea separadora de debajo, y cada celda ocupa una posición visualmente obvia. Los modelos manejan bien este formato: está por todas partes en sus datos de entrenamiento, en archivos README, en documentación y en issues de GitHub. Sube un .csv arriba y recuperas una tabla en segundos. Gratis, sin registro, no guardamos nada.

Qué te aporta una tabla de barras verticales

La diferencia estructural es pequeña sobre el papel y enorme en la práctica:

• El encabezado deja de ser ambiguo. La fila separadora |---|---| le dice a cualquier parser de Markdown —y a cualquier modelo que haya leído un millón de ellas— que la línea de arriba son nombres de columna y no datos.
• Razonar por columnas se vuelve más fácil. Preguntas del tipo «qué región va a la baja» o «encuentra el valor atípico en la columna de precios» exigen leer en vertical. Una tabla de barras verticales pone esa lectura vertical al alcance de forma estructural; una ristra de comas, no.
• Las celdas vacías siguen viéndose. En un CSV en crudo, a,,c es fácil de leer mal. Como | a | | c | el hueco es evidente, y eso importa cuando lo que preguntas es justamente por los datos que faltan.
• Sobrevive al copiar y pegar. Suelta la tabla en un chat, en un comentario de GitHub, en una página de Notion o en un sitio de documentación y se renderiza como una tabla de verdad en lugar de como una mancha de texto; además convive sin problema en un prompt junto a prosa y código, sin que el modelo confunda las tres cosas.

Delimitadores, comillas y por qué «CSV» es una mentira

No existe un único estándar CSV, solo un consenso aproximado del que la gente se desvía sin parar. El parseo tiene que lidiar con varias realidades:

El delimitador no siempre es una coma. Las exportaciones de sistemas configurados en alemán, francés, español u holandés suelen usar punto y coma, porque ahí la coma es el separador decimal. Los archivos separados por tabuladores se guardan con extensión .csv a todas horas. Los delimitados por barra vertical salen de exportaciones de bases de datos antiguas. La detección del delimitador funciona muestreando las primeras líneas y quedándose con el candidato que produce un número de campos consistente, algo fiable en el caso normal y que se puede engañar con un archivo cuyas primeras filas casualmente lleven muchos punto y coma dentro de texto libre.

Los campos entrecomillados contienen el delimitador. El caso clásico es una dirección: "Smith, John",42,"London, UK" son tres campos, no cinco. Todo lo que va envuelto en comillas dobles es un solo valor, dé igual lo que lleve dentro, saltos de línea incluidos: una columna de comentarios con texto multilínea es CSV perfectamente válido y ocupará varias líneas del archivo siendo una única celda. Una comilla dentro de un campo entrecomillado se escapa duplicándola: "She said ""no""". Todo esto se contempla, y por eso un script ingenuo que parte por comas falla con exportaciones reales y un parser en condiciones no.

Una consecuencia que conviene tener presente: si tus datos contienen barras verticales de verdad, hay que escaparlas en la salida Markdown o romperían la tabla. Se hace, pero significa que una celda que contiene a|b se ve un poco distinta en la salida que en el origen.

Encabezados, filas irregulares y archivos que no son del todo tablas

Un archivo CSV no tiene forma de declarar si su primera línea es un encabezado. Se infiere: si la primera fila es todo texto y las de debajo llevan números o fechas, casi con seguridad son nombres de columna. Si todas las filas se parecen, la primera se trata igualmente como encabezado, porque es el caso abrumadoramente habitual. Si tu archivo de verdad no tiene encabezado, verás tu primera fila de datos ascendida a esa posición. Fácil de detectar y fácil de arreglar añadiendo una línea de encabezado antes de convertir.

Las filas irregulares —con más o menos campos que el encabezado— son la otra arruga habitual. Vienen de archivos editados a mano, de una comilla suelta sin escapar más arriba que descuadra todo lo que sigue, o de exportaciones que añaden una línea de totales al final. Las tablas Markdown exigen un número fijo de columnas, así que las filas cortas se rellenan y la forma sigue siendo válida. Si ves una sección entera de tu tabla desplazada una columna, busca una comilla sin cerrar por encima: casi siempre es la culpable.

Las herramientas de BI suelen anteponer un título de informe y una fecha antes del encabezado real. Esas líneas se leen como parte de la tabla. Bórralas primero.

El CSV con sabor a Excel y sus manías

Buena parte de los CSV que hay en el mundo salieron de Excel, y Excel deja huellas:

• Un BOM al principio. Excel escribe una marca de orden de bytes en las exportaciones UTF-8, que aparece como basura invisible pegada al primer nombre de columna en las herramientas que no la quitan. Aquí se quita.
• Números convertidos en notación científica. Los identificadores largos acaban guardados como 1.23457E+14 porque Excel decidió que eran números. Ese daño ocurre en la hoja de cálculo, antes de que el CSV exista: ningún conversor puede deshacerlo. Formatea la columna como texto en el origen antes de exportar.
• Ceros iniciales perdidos. Los códigos postales y los códigos de producto los pierden por la misma vía.
• Fechas reformateadas a la configuración regional de la máquina, que es como 03/04 se vuelve ambiguo para siempre.
• Exportaciones en Latin-1. El «Guardar como CSV» de algunas versiones de Windows escribe Windows-1252, no UTF-8. Si los caracteres acentuados o las comillas tipográficas salen como é o “, eso es mojibake de una codificación mal declarada: vuelve a exportar como CSV UTF-8 y desaparece.

Si todavía conservas el libro en lugar de la exportación, convertirlo directamente con Excel a Markdown te ahorra casi todo esto: en XLSX se conservan los tipos de celda, y obtienes todas las hojas y no solo la que estuviera activa cuando alguien pulsó guardar.

Cuándo convertir CSV a tabla Markdown es mala idea

Las tablas de barras verticales tienen un techo de tamaño, y está más bajo de lo que la gente supone. Cada fila paga sus barras y su relleno, así que una tabla cuesta bastantes más tokens que los mismos datos como valores pelados. En un archivo de 200 filas eso da igual. En una exportación de 50.000 filas es la diferencia entre caber en el contexto o no caber.

El ancho es el otro límite. Una tabla de cuarenta columnas se parte en una sopa ilegible en la mayoría de los visores, y la ventaja de alineación que justificaba el formato desaparece. Alrededor de una docena de columnas el equilibrio empieza a inclinarse hacia el otro lado.

Para esos casos usa CSV a texto plano, que te da los valores sin el andamiaje de la tabla: mejor para archivos grandes, para embeddings y para cualquier cosa que vaya a pasar por un script. El selector de formato de arriba alterna entre los dos y conserva el archivo que ya elegiste, y el contador de tokens debajo de la salida te dice al instante si la versión en tabla cabe en tu presupuesto.

Dónde se gana el sueldo

• Análisis puntual en una ventana de chat. Exporta el resultado de una consulta, convierte, pega y pregunta. Para unos cientos de filas esto le gana a escribir código de análisis.
• Documentación. Un generador de tablas Markdown a partir de CSV es el camino más corto entre una hoja de configuración y una tabla en un README o en una página de documentación.
• Revisión de datos. Las columnas alineadas hacen visibles las anomalías para una persona, no solo para un modelo: detectar la única fila con dos campos intercambiados es mucho más fácil en una tabla. Por lo mismo, unos datos de ejemplo se leen mejor como tabla que como bloque de código CSV en crudo dentro de un issue de GitHub.
• Combinar datos y código. Convierte el CSV, luego convierte tu proyecto con el conversor de GitHub a texto, y pídele a un modelo que compruebe si tu lógica de parseo aguanta de verdad lo que hay en el archivo.

Preguntas frecuentes

¿Cómo puedo convertir un CSV a tabla Markdown?

Sube el .csv de arriba y vuelve convertido en una tabla de barras verticales, lista para pegar en un README, en un issue, en una página de documentación o en un prompt. Gratis, 50 MB por archivo, sin registro. La primera fila se trata como encabezado, que es lo que produce prácticamente cualquier exportación CSV.

¿Y si mi CSV no tiene fila de encabezado?

La primera fila de datos asciende al encabezado y la pierdes del cuerpo. Lo más sencillo es añadir una línea de encabezado al archivo de origen antes de subirlo; sirven incluso nombres de relleno como col1,col2,col3, porque la sintaxis de las tablas Markdown exige una fila de encabezado y algo tiene que ocuparla.

¿Hasta qué tamaño de CSV compensa pasarlo a Markdown?

En la práctica, unos cientos de filas. Las tablas Markdown no tienen paginación, ni ordenación, ni desplazamiento: una tabla de diez mil filas es un muro de barras verticales que no ayuda a nadie y quema una cantidad enorme de contexto si la pegas en un modelo. Filtra primero en la hoja de cálculo las filas que necesitas y convierte solo ese subconjunto.

¿Escapa las barras verticales que haya dentro de mis datos?

Tiene que hacerlo, porque un | sin escapar dentro de una celda se leería como límite de columna y desplazaría en silencio todos los valores posteriores. Si trabajas con datos que contienen barras verticales —líneas de log, algunas URLs, ejemplos de comandos—, revisa a mano en la salida una fila que lleve una, en lugar de darlo por hecho.

¿Se verá bien la tabla en GitHub?

Sí. Lo que sale son tablas de barras verticales de GitHub Flavored Markdown, así que se renderizan sin tocar nada en archivos README, issues, descripciones de pull request y comentarios de discusiones. La misma sintaxis funciona en GitLab, Obsidian, las importaciones de Notion y la mayoría de generadores de sitios estáticos.

Conversores relacionados

File2Txt acepta cualquier archivo compatible si prefieres usar una sola página para todo. Para otros formatos estructurados, JSON a Markdown y XML a Markdown se ocupan de los datos anidados que no encajan en una rejilla plana, y HTML a Markdown saca las tablas de páginas web guardadas. Los documentos pasan por PDF a Markdown.

En el lado del código están el conversor de GitLab y un conversor de carpetas locales, además de Web2Txt para rastrear páginas en vivo. La guía del conversor de archivos a texto cubre el flujo de trabajo completo.

Repo2Txt está creado y mantenido por v12hero, un desarrollador independiente que crea aplicaciones nativas y web centradas en la privacidad.