Générateur de tableaux Markdown

Quatre formats en entrée, un seul en sortie

Un tableau Markdown est facile à écrire et pénible à maintenir. Ajoutez un mot dans une cellule et toutes les barres verticales en dessous se décalent ; et construire un tableau à partir de données que vous avez déjà — un résultat de requête, un export de tableur, une réponse d’API — revient à tout retaper à la main. Cet outil prend les données dans la forme où elles se trouvent et renvoie un tableau propre au format Markdown de GitHub.

Il lit quatre formats, et il vous dit lequel il a retenu au lieu de décider en silence :

• Un tableau Markdown : un tableau désaligné se recolle simplement tel quel et ressort redressé.
• Du CSV, analysé selon la RFC 4180 — un champ entre guillemets peut contenir des virgules, des guillemets et même des sauts de ligne, et tout survit.
• Du TSV, ce que l’on obtient en copiant une plage depuis un tableur ou un client de base de données.
• Un tableau JSON, d’objets (les clés deviennent les colonnes) ou de tableaux (la première ligne devient l’en-tête).

La détection cherche d’abord l’indice le plus net : un crochet ouvrant ne peut être que du JSON, une ligne de tirets ne peut être qu’une ligne de séparation Markdown, une tabulation dans la première ligne ne peut être que du TSV. La séparation par virgules est ce qui reste, elle est donc annoncée comme repli et non comme découverte : si l’outil a dû deviner, il le dit, et le sélecteur de format prime sur lui.

La sortie est du Markdown et rien d’autre. Reconvertir un tableau en CSV ou en JSON est un autre métier, et ce site a déjà des outils pour cela ; un second convertisseur généraliste ne ferait que leur faire concurrence et rendrait cette page plus difficile à expliquer.

Une cellule se complète selon sa largeur, pas selon sa longueur

Aligner les barres suppose de compléter chaque cellule d’une colonne jusqu’à la même largeur, ce qui suppose de savoir quelle largeur fait une cellule. La réponse évidente — compter les caractères — est fausse pour la plupart des systèmes d’écriture du monde, et elle est fausse dans les deux sens.

Une police à chasse fixe, ce n’est pas un caractère, une colonne. Un idéogramme chinois ou japonais, un kana, une syllabe hangul, une lettre latine pleine largeur et presque tous les emojis sont dessinés exactement deux fois plus larges qu’une lettre latine. Une marque combinante — un accent, un point-voyelle hébreu, une diacritique arabe — se dessine par-dessus la lettre précédente et n’occupe aucune largeur. Complétez au nombre de caractères et une colonne de japonais ressort trop courte tandis qu’une colonne de texte accentué ressort trop longue.

'日本語'.length          // 3  UTF-16 code units
[...'日本語'].length     // 3  code points
displayWidth('日本語')   // 6  columns in the editor

Le remplissage se mesure donc en colonnes d’affichage. Le texte est d’abord découpé en groupes graphémiques — ce qu’un lecteur compte pour un caractère, de sorte qu’un emoji formé de plusieurs points de code reste une seule unité — et chaque groupe est confronté à la propriété East_Asian_Width de la base de données des caractères Unicode. C’est la seule chose à laquelle un navigateur ne sait pas répondre seul : JavaScript expose la catégorie, l’écriture et la casse via les expressions régulières, mais pas celle-ci, si bien qu’une petite table des plages larges accompagne la page. Tout le reste vient du moteur.

Une catégorie est délibérément traitée comme étroite. Unicode marque un ensemble de caractères — filets de tableau, quelques lettres grecques et cyrilliques, plusieurs signes de ponctuation — comme « ambigus » : larges dans une police est-asiatique ancienne, étroits partout ailleurs. Un fichier Markdown se lit dans un éditeur dont la police par défaut est latine, ils comptent donc pour une colonne, ce que font justement les terminaux et les éditeurs dans lesquels vous ouvrirez le fichier.

Ce qu’un tableau Markdown ne peut pas contenir

Le format a deux limites dures, et les vraies données se heurtent aux deux. Une cellule ne peut pas contenir de barre verticale nue, puisque c’est ce qui sépare les cellules ; il faut l’échapper. Et une ligne de tableau tient sur une seule ligne, une cellule ne peut donc pas contenir de saut de ligne du tout — ce qu’un champ CSV a pourtant parfaitement le droit d’avoir.

Les deux sont réécrits, et chaque réécriture est signalée avec le nombre de cellules concernées et la position de la première. C’est bien là l’enjeu : un outil qui transforme silencieusement votre adresse sur deux lignes en une seule a abîmé vos données sans le dire. Un saut de ligne devient par défaut une balise de saut, ce que GitHub, GitLab et la plupart des moteurs de rendu affichent comme une nouvelle ligne dans la cellule ; si le vôtre supprime le HTML, choisissez plutôt une espace.

Une ligne plus longue que l’en-tête est le troisième cas. Le Markdown de GitHub se contente de jeter les cellules en trop, ce qui perd des données en silence. Ici le tableau est élargi à la place, avec des cellules d’en-tête vides, et l’écart est signalé — un en-tête bizarre que vous pouvez corriger vaut mieux qu’une colonne dont vous n’entendrez jamais parler. Une ligne plus courte que l’en-tête est complétée par des cellules vides et signalée de la même façon.

Les barres obliques inverses sont traitées avec un peu plus de soin que dans la plupart des outils. Une barre n’est doublée que là où elle pourrait avaler la barre verticale qui la suit : devant une barre verticale dans le texte, ou tout à la fin d’une cellule, là où arrive le séparateur. Partout ailleurs elle est laissée telle quelle, si bien qu’un chemin Windows dans une cellule reste lisible au lieu de se transformer en enfilade de doubles barres.

L’alignement vit dans la ligne de séparation

La ligne de tirets sous l’en-tête remplit deux rôles. C’est elle qui fait du bloc un tableau, et ses deux-points fixent l’alignement de chaque colonne : deux-points à gauche pour aligner à gauche, à droite pour aligner à droite, des deux côtés pour centrer. Sans deux-points, le moteur de rendu applique sa propre valeur par défaut, qui est la gauche dans toutes les implémentations, mais ce n’est pas la même chose que demander la gauche.

Chaque colonne dispose ici de son propre réglage, parce que c’est ainsi que l’alignement sert vraiment : le texte à gauche, les nombres à droite, une colonne d’état centrée. Et quand vous collez un tableau qui porte déjà un alignement, il est lu dans la ligne de séparation et affiché dans ces réglages, si bien que reformater un tableau existant ne jette jamais discrètement le travail de quelqu’un.

Le remplissage suit lui aussi l’alignement. Une colonne alignée à droite est complétée à gauche, donc la source se présente comme se présentera le tableau rendu. Markdown ignore complètement ces espaces, et c’est précisément pour cela qu’on peut les dépenser sans frais pour rendre la source lisible.

Complété ou compact, et pourquoi le texte de droite à gauche est différent

Le remplissage vaut la peine dans un document qu’une personne édite et coûte quelque chose dans un dépôt. Chaque cellule qui s’allonge fait recompléter toute sa colonne, si bien qu’une modification d’un mot apparaît dans le diff comme une modification de toutes les lignes du tableau. La forme compacte écrit le tableau licite le plus étroit — aucun remplissage, trois tirets par colonne — et réduit le diff aux lignes qui ont réellement changé. Les deux se rendent à l’identique. Les barres en début et en fin de ligne sont facultatives dans le Markdown de GitHub mais exigées par certains moteurs anciens : c’est donc un interrupteur et non une décision.

Le remplissage ne peut pas fonctionner du tout dans un tableau contenant de l’hébreu ou de l’arabe, et l’outil le dit plutôt que de faire semblant. Les espaces sont comptées correctement, mais un éditeur dispose une ligne mixte selon l’algorithme bidirectionnel : le passage de droite à gauche est réordonné, et les barres qui l’entourent se déplacent avec lui. Les caractères sont aux bons endroits et les barres ne paraissent pourtant pas alignées, parce que dans une telle ligne la position visuelle et la position logique ne sont pas la même chose. Rien ne peut corriger cela : lorsqu’une cellule contient du texte de droite à gauche, l’outil le signale et suggère la forme compacte, où il n’y a pas d’alignement qui puisse décevoir.

Pour la même raison, la sortie Markdown de cette page est toujours affichée de gauche à droite, même si vous lisez le site en hébreu ou en arabe. C’est du code source, et le code source a une direction propre.

Où cela s’exécute

Tout se passe dans votre navigateur. Le tableau est analysé, mesuré et reconstruit sur votre machine, et rien de ce que vous collez n’est envoyé, stocké ni journalisé — ce qui compte, car les tableaux que l’on a besoin de reformater sont le plus souvent des résultats de requêtes et des exports plutôt que des données publiques.