Aller au contenu principal
ToolsByUs

JSON vers tableau Markdown

Ce convertisseur affiche un tableau d’objets JSON sous forme de tableau Markdown au style GitHub dans votre navigateur. Les colonnes sont l’union des premières occurrences de chaque clé des objets, les pipes sont échappés en \|, les sauts de ligne deviennent <br>, et la ligne de séparation correspond à votre en-tête — le résultat s’insère directement dans n’importe quel rendu Markdown.

100 % local

JSON vers tableau Markdown en clair

La documentation s’appuie sur les tableaux Markdown — listes de fonctionnalités des README, entrées de journal des modifications, sections de comparaison dans une demande de pull request — et les données qui les sous-tendent commencent souvent en JSON : une réponse d’API, un rapport de tests, une exportation. Saisir le tableau à la main est une source d’erreurs, car les tableaux Markdown ont des règles faciles à mal appliquer : une ligne par ligne, les cellules séparées par des pipes, et une ligne de séparation qui détermine si les colonnes existent vraiment.

Ce convertisseur effectue la saisie pour vous, selon les règles du Markdown au style GitHub. La ligne d’en-tête est l’union ordonnée des clés de chaque objet, dans l’ordre de première occurrence, ainsi une clé apparaissant à partir du deuxième enregistrement obtient toujours sa colonne. Un pipe à l’intérieur d’une valeur est échappé en \| pour ne pas diviser la cellule, un saut de ligne à l’intérieur d’une valeur devient <br> pour ne pas diviser la ligne, et les objets ou tableaux imbriqués dans un enregistrement sont rendus sous forme de texte JSON compact pour ne rien perdre.

Comme partout sur ce site, la conversion se fait entièrement dans votre navigateur. Le JSON est parsé avec JSON.parse natif du navigateur, le Markdown est construit dans l’onglet, et rien n’est envoyé nulle part — le panneau Réseau de DevTools reste silencieux à chaque conversion, et la Content-Security-Policy de la page bloque les requêtes sortantes.

Le passage est utile dans les deux sens — un tableau maintenu dans un wiki peut redevenir des données — et la Convertisseur Markdown vers JSON page analyse la syntaxe de tableau GitHub pour la retransformer en enregistrements.

Si la destination est un tableur plutôt que de la documentation, le Convertisseur JSON vers CSV produit des lignes conformes à RFC 4180 à partir des mêmes enregistrements.

Comment la conversion fonctionne réellement

Le moteur analyse votre JSON avec JSON.parse et exige que le niveau supérieur soit un tableau d’objets — la seule forme qui signifie des lignes. Il parcourt ensuite les enregistrements une fois, collectant les clés en une union ordonnée : les clés du premier enregistrement ouvrent le tableau, et une clé vue pour la première fois dans un enregistrement ultérieur est ajoutée à droite plutôt que de déplacer l’ordre des colonnes déjà existant. Les enregistrements qui n’ont pas une clé laissent simplement la cellule vide. Rien dans le résultat ne dépend d’outils que vous n’avez pas : le tableau est du texte brut, il survive au copier-coller, à la révision de code et aux builds de site statique. Le tableau est ensuite écrit, une règle par risque :

  • En-tête : une ligne avec les clés de l’union, puis une ligne de séparation avec trois tirets par colonne — la ligne qui transforme le bloc en tableau dans tout rendu Markdown au style GitHub.
  • Pipes : un | à l’intérieur d’une valeur est émis en \|, l’échappement que définit GFM, pour qu’une valeur comme a|b reste dans une seule cellule.
  • Sauts de ligne : un \n à l’intérieur d’une valeur devient <br>, car un saut de ligne réel terminerait la ligne et corromprait tout ce qui suit.
  • Valeurs imbriquées : un objet ou tableau dans un enregistrement est rendu comme texte JSON compact dans sa cellule, pour que les données imbriquées soient visibles et non pas supprimées.

À quoi ressemble le résultat

L’exci ci-dessous est la paire exacte que produit le bouton Charger l’exemple du convertisseur : deux personnes, où la valeur notes du premier enregistrement contient un pipe et celle du second un saut de ligne. Le pipe échappé s’affiche comme un | littéral dans sa cellule, le saut de ligne s’affiche comme un saut de ligne sous <br>, et les deux lignes conservent leurs trois colonnes. Les lignes sont entourées de pipes au début et à la fin, la forme que lisent le plus fiablement tous les rendus et outils de diff.

Collez le résultat dans n’importe quel rendu Markdown au style GitHub et l’aperçu que vous voyez est ce que les lecteurs obtiennent. Le tableau est aussi stable sous diff pour une raison simple : l’ordre des colonnes dépend de l’ordre du document plutôt que d’un tri, donc un enregistrement qui gagne une clé ajoute une colonne au lieu de réorganiser celles que vos lecteurs connaissent déjà.

Les règles de cellule en résumé

Chaque risque qu’une cellule peut contenir, et sa forme émise :

Contenu de la celluleÉmis commePourquoi
a|ba\|bUn pipe brut diviserait la cellule
ligne un\nligne deuxligne un<br>ligne deuxUn saut de ligne brut terminerait la ligne
{"x": 1}Texte JSON compactLes valeurs imbriquées sont affichées, pas supprimées
truetrueLes booléens s’affichent sans modification
(clé manquante)(cellule vide)Les enregistrements incomplets restent alignés

Les entrées que ce convertisseur refuse

Deux formes n’ont pas de tableau fiable et sont refusées avec un message spécifique plutôt que forcées :

  • Un niveau supérieur qui n’est pas un tableau — un seul objet est une ligne sans tableau à joindre, et l’envelopper dans un tableau synthétique inventerait une structure que vous n’avez pas écrite.
  • Un tableau dont les éléments ne sont pas tous des objets — une liste de scalaires n’a pas de clés, donc rien ne peut devenir des en-têtes de colonne ; le convertisseur nomme l’index problématique.

Questions fréquentes

Des données sont-elles envoyées à un serveur lorsque je convertis du JSON en Markdown ?

Non. Le parsing et le rendu s’exécutent tous deux dans cet onglet avec du JavaScript local à la page. Il n’y a pas de point de terminaison pour l’envoi, et la Content-Security-Policy interdit les connexions sortantes. Vous pouvez vérifier les deux dans DevTools : ouvrez le panneau Réseau, convertissez un document, et observez qu’aucune requête n’est effectuée à aucun moment.

Pour quel dialecte Markdown le résultat est-il écrit ?

Pour le Markdown au style GitHub, la syntaxe de tableau utilisée par GitHub, GitLab et la plupart des outils de documentation. La signature est la ligne de séparation de tirets sous l’en-tête — ce convertisseur émet trois tirets par colonne sans deux-points d’alignement, donc les cellules sont alignées à gauche par défaut — et les lignes comportent des pipes au début et à la fin pour une compatibilité maximale avec les rendus.

Pourquoi un pipe à l’intérieur de ma valeur a-t-il besoin d’être échappé ?

Parce que le pipe est le délimiteur de cellule : un | brut serait lu comme la fin d’une cellule et le début d’une autre, décalant silencieusement toutes les cellules suivantes. L’échappement de GFM est la paire barre oblique inverse-pipe \|, qui s’affiche comme un pipe littéral dans la cellule. Le convertisseur l’applique à chaque valeur, donc un exemple de code comme a|b arrive dans le tableau tel qu’il était.

Pourquoi les sauts de ligne dans les valeurs deviennent-ils <br> et pas de vrais sauts de ligne ?

Une ligne de tableau Markdown est par définition une seule ligne — un saut de ligne brut dans une cellule termine la ligne, et le rendu traite le reste comme un nouveau paragraphe, corrompant le tableau. La balise HTML <br> s’affiche comme un saut de ligne dans la cellule, ce qui est la convention que GitHub documente lui-même pour le contenu multi-ligne des cellules.

Comment l’ordre des colonnes est-il décidé ?

Par l’union des clés de chaque enregistrement dans l’ordre de première occurrence : les clés du premier enregistrement définissent les colonnes initiales, et toute clé apparaissant plus tard est ajoutée à droite. Les enregistrements sans clé laissent la cellule vide. L’ordre est stable — l’ordre du document, pas alphabétique — car un convertisseur qui trierait vos colonnes rendrait chaque diff ultérieur du résultat bruyant.

Que devient les objets et tableaux imbriqués dans un enregistrement ?

Ils sont rendus comme du texte JSON compact dans leur cellule, pour que l’information reste visible au lieu d’être supprimée ou aplatie au point d’être méconnaissable. Si la structure imbriquée a de l’importance en aval — filtrage, tri, graphiques — aplatissez-la d’abord avec le convertisseur JSON vers CSV, qui transforme les chemins imbriqués en colonnes ; pour la lecture et la révision, la cellule au format texte JSON est généralement suffisante.

Équipe ToolsByUs · Comment nous vérifions nos outils