Generador de tablas Markdown
Genera una tabla Markdown desde CSV, TSV o JSON, o realinea una que ya tengas, con alineación por columna y relleno consciente del CJK. En tu navegador.
Leído como CSV. Nada identificó la entrada, así que esta es la opción por defecto: elige un formato arriba si no es correcta.
Alineación de columnas
| city | country | population |
| --------- | ------- | ---------- |
| 東京 | Japan | 37400068 |
| Delhi | India | 28514000 |
| São Paulo | Brazil | 21650000 |Columnas: 3 · filas: 3
Cuatro entradas, una salida
Una tabla Markdown es fácil de escribir y penosa de mantener. Añadir una palabra a una celda descoloca todas las barras verticales que hay debajo, y montar una tabla con datos que ya tienes — el resultado de una consulta, una exportación de una hoja de cálculo, la respuesta de una API — significa teclearla otra vez a mano. Esta herramienta toma los datos con la forma que tengan y devuelve una tabla limpia en el Markdown de GitHub.
Lee cuatro formatos, y te dice por cuál se ha decidido en lugar de decidirlo en silencio:
- Una tabla Markdown, de modo que una tabla que ha perdido la alineación se pega tal cual y queda enderezada.
- CSV, analizado según RFC 4180: un campo entrecomillado puede contener comas, comillas e incluso saltos de línea, y todos sobreviven.
- TSV, que es lo que sale al copiar un rango de una hoja de cálculo o de un cliente de base de datos.
- Un array JSON, ya sea de objetos (las claves se convierten en columnas) o de arrays (la primera fila pasa a ser la cabecera).
La detección busca primero la prueba más inequívoca: un corchete inicial solo puede ser JSON, una fila de guiones solo puede ser la fila separadora de Markdown, y un tabulador en la primera línea solo puede ser TSV. La separación por comas es lo que queda, así que se anuncia como opción por defecto y no como hallazgo: si la herramienta ha tenido que adivinar, lo dice, y el selector de formato manda sobre ella.
La salida es Markdown y solo Markdown. Convertir una tabla de vuelta a CSV o JSON es otro trabajo, y este sitio ya tiene herramientas que lo hacen; un segundo conversor de propósito general solo competiría con ellas y haría esta página más difícil de explicar.
Una celda se rellena por anchura, no por longitud
Alinear las barras significa rellenar cada celda de una columna hasta la misma anchura, lo que exige saber cuánto ocupa una celda. La respuesta evidente — contar los caracteres — es incorrecta para la mayoría de los sistemas de escritura del mundo, y lo es en los dos sentidos.
Una fuente monoespaciada no es un carácter, una columna. Un ideograma chino o japonés, un kana, una sílaba hangul, una letra latina de ancho completo y casi cualquier emoji se dibujan exactamente al doble de anchura que una letra latina. Una marca combinante — un acento, un punto vocálico hebreo, un signo diacrítico árabe — se dibuja sobre la letra anterior y no ocupa anchura alguna. Rellena contando caracteres y una columna de japonés sale corta mientras que una de texto acentuado sale larga.
'日本語'.length // 3 UTF-16 code units
[...'日本語'].length // 3 code points
displayWidth('日本語') // 6 columns in the editorPor eso el relleno se mide en columnas de visualización. El texto se divide primero en grupos grafémicos — lo que un lector cuenta como un carácter, de modo que un emoji formado por varios puntos de código unidos sigue siendo una unidad — y cada grupo se compara con la propiedad East_Asian_Width de la base de datos de caracteres Unicode. Esa propiedad es lo único que un navegador no puede responder por sí mismo: JavaScript expone categoría, escritura y caso mediante expresiones regulares, pero esta no, así que con la página viaja una pequeña tabla de los rangos anchos. Todo lo demás viene del motor.
Hay una categoría que se trata como estrecha a propósito. Unicode marca un conjunto de caracteres — dibujo de recuadros, algunas letras griegas y cirílicas, varios signos de puntuación — como «ambiguos»: anchos en una fuente antigua de Asia Oriental, estrechos en cualquier otro sitio. Un archivo Markdown se lee en un editor con una fuente latina por defecto, así que cuentan como una columna, que es lo que hacen las terminales y los editores en los que vas a abrir el archivo.
Lo que una tabla Markdown no puede contener
El formato tiene dos límites duros, y los datos reales chocan con ambos. Una celda no puede contener una barra vertical desnuda, porque es lo que separa las celdas; hay que escribirla escapada. Y una fila de tabla es una sola línea, así que una celda no puede contener un salto de línea en absoluto, algo a lo que un campo CSV tiene todo el derecho.
Ambas cosas se reescriben, y cada reescritura se informa con el número de celdas afectadas y la posición de la primera. De eso se trata: una herramienta que convierte en silencio tu dirección de dos líneas en una sola ha dañado tus datos sin decírtelo. Un salto de línea se convierte por defecto en una etiqueta de salto, que es lo que GitHub, GitLab y la mayoría de los renderizadores muestran como línea nueva dentro de la celda; si el tuyo elimina el HTML, cámbialo por un espacio.
Una fila más larga que la cabecera es el tercer caso. El Markdown de GitHub sencillamente descarta las celdas sobrantes, lo que pierde datos en silencio. Aquí la tabla se ensancha en su lugar, con celdas de cabecera vacías, y el desajuste se informa: una cabecera de aspecto raro que puedes arreglar es mejor que una columna de la que nunca te enteras. Una fila más corta que la cabecera se rellena con celdas vacías y se informa igual.
Las barras invertidas se tratan con algo más de cuidado que en la mayoría de las herramientas. Una barra invertida solo se duplica donde podría tragarse la barra vertical que la sigue: delante de una barra en el texto, o justo al final de una celda, donde viene el separador. En cualquier otro sitio se deja tal cual, así que una ruta de Windows dentro de una celda sigue siendo legible en vez de convertirse en una hilera de barras dobles.
La alineación vive en la fila separadora
La fila de guiones bajo la cabecera hace dos trabajos. Es lo que convierte el bloque en una tabla, y sus dos puntos fijan la alineación de cada columna: dos puntos a la izquierda alinea a la izquierda, a la derecha alinea a la derecha, y a ambos lados centra. Sin dos puntos el renderizador usa su propio valor por defecto, que es la izquierda en todas las implementaciones, pero no es lo mismo que pedir izquierda.
Aquí cada columna tiene su propio control, porque así es como se usa la alineación en la práctica: el texto a la izquierda, los números a la derecha, una columna de estado centrada. Y cuando pegas una tabla que ya trae alineación, se lee de la fila separadora y se muestra en esos controles, de modo que reformatear una tabla existente nunca descarta en silencio el trabajo que alguien hizo en ella.
El relleno también sigue a la alineación. Una columna alineada a la derecha se rellena por la izquierda, así que el código fuente se ve igual que se verá la tabla renderizada. Markdown ignora por completo ese espacio en blanco, y precisamente por eso se puede gastar gratis en hacer legible el fuente.
Rellenada o compacta, y por qué el texto de derecha a izquierda es distinto
El relleno merece la pena en un documento que una persona edita y cuesta algo en un repositorio. Cada celda que crece vuelve a rellenar toda su columna, así que un cambio de una palabra aparece en el diff como un cambio en todas las filas de la tabla. La forma compacta escribe la tabla legal más estrecha — sin relleno, tres guiones por columna — y deja el diff reducido a las filas que de verdad han cambiado. Las dos se renderizan igual. Las barras al principio y al final de cada fila son opcionales en el Markdown de GitHub pero obligatorias en algunos renderizadores antiguos, así que son un interruptor y no una decisión.
El relleno no puede funcionar en absoluto en una tabla con hebreo o árabe, y la herramienta lo dice en lugar de fingir. Los espacios se cuentan correctamente, pero un editor dispone una línea mixta según el algoritmo bidireccional: el tramo de derecha a izquierda se reordena, y las barras que lo rodean se mueven con él. Los caracteres están en su sitio y aun así las barras no parecen alineadas, porque en esa línea la posición visual y la lógica no son lo mismo. Eso no tiene arreglo, así que cuando hay texto de derecha a izquierda en una celda la herramienta lo informa y sugiere la forma compacta, donde no hay alineación que pueda decepcionar.
Por la misma razón la salida Markdown de esta página se muestra siempre de izquierda a derecha, incluso cuando lees el sitio en hebreo o en árabe. Es código fuente, y el código fuente tiene una dirección propia.
Dónde se ejecuta
Todo ocurre en tu navegador. La tabla se analiza, se mide y se reconstruye en tu propia máquina, y nada de lo que pegas se sube, se guarda ni se registra, lo que importa porque las tablas que la gente necesita reformatear suelen ser resultados de consultas y exportaciones antes que datos públicos.
Preguntas frecuentes
- ¿Se envían mis datos a un servidor?
- No. El análisis, la medida de la anchura y la salida se calculan en tu navegador, y nada de lo que pegas se sube ni se registra.
- ¿Cómo convierto un CSV en una tabla Markdown?
- Pégalo. La herramienta reconoce el texto separado por comas, toma la primera fila como cabecera y devuelve una tabla Markdown alineada. Los campos entrecomillados con comas, comillas o saltos de línea se tratan correctamente, y se informa de todo lo que ha habido que reescribir para que quepa en el formato.
- ¿Por qué mi tabla con texto japonés o chino sigue sin alinearse?
- Revisa la fuente. El relleno da por hecho una fuente monoespaciada en la que un ideograma mide exactamente el doble que una letra latina, que es lo que usan las terminales y los editores de código. En una fuente proporcional, o en una cuyos glifos CJK no midan exactamente el doble, ningún relleno alineará las columnas: ahí usa la forma compacta.
- ¿Qué pasa con un salto de línea dentro de una celda?
- Se convierte en una etiqueta de salto por defecto, porque una fila de tabla Markdown es una sola línea y no puede contener uno real. Cámbialo por un espacio si tu renderizador elimina el HTML. En cualquier caso la herramienta informa de qué celdas ha cambiado.
- ¿Por qué mi fila con celdas de más añade una columna vacía?
- Porque la alternativa es perder esas celdas. El Markdown de GitHub descarta todo lo que pase de la anchura de la cabecera, así que en su lugar la tabla se ensancha con celdas de cabecera vacías y el desajuste se informa. Borra la columna o ponle nombre una vez hayas visto lo que había dentro.
- ¿Debo usar la forma rellenada o la compacta?
- La rellenada para un documento que la gente lee y edita a mano — un README, una nota de diseño — porque el fuente queda legible. La compacta para cualquier cosa bajo control de versiones cuya tabla cambie a menudo: con relleno, una celda editada vuelve a rellenar toda la columna y aparece en el diff como si hubieran cambiado todas las filas.
- ¿Necesito las barras al principio y al final de cada fila?
- El Markdown de GitHub no las exige, ni tampoco la mayoría de los renderizadores modernos. Algunos analizadores antiguos sí, y hacen más legible una tabla editada a mano, así que están activadas por defecto y se pueden desactivar.
- ¿Por qué la herramienta no puede alinear una tabla con hebreo o árabe?
- Porque el editor reordena la línea. La disposición bidireccional coloca el tramo de derecha a izquierda en orden visual, y las barras que lo rodean se mueven con él, así que el relleno es aritméticamente correcto y visualmente inútil. La herramienta lo informa y sugiere la forma compacta en vez de producir una tabla que parece rota.