Pourquoi deux analyseurs ne sont pas d'accord sur votre document
Markdown a été publié en 2004 sous la forme d'un script Perl et d'une page de prose, sans grammaire formelle. C'est cette informalité qui l'a fait se répandre, et aussi la raison pour laquelle le même document est rendu différemment selon les outils. L'implémentation d'origine a laissé des dizaines de cas indéfinis : ce qu'un marqueur de liste fait lorsqu'il est indenté de trois espaces, comment l'emphase s'imbrique dans un mot, si un titre a besoin d'une ligne vide avant lui. Chaque implémenteur a comblé ces manques en devinant, et ils ont deviné différemment.
CommonMark existe pour combler cet écart. C'est une spécification précise avec plusieurs centaines de tests de conformité couvrant exactement les cas ambigus que l'original a laissés ouverts. Ce convertisseur utilise markdown-it, qui passe la suite CommonMark complète, si bien que la sortie correspond à ce que produisent GitHub, Reddit, Discourse et la plupart des outils modernes. Si un document est rendu ici, il le sera de la même façon là-bas.
GitHub Flavored Markdown est un sur-ensemble superposé : tableaux, barré, listes de tâches et URL à liaison automatique. Les tableaux et les listes de tâches fonctionnent dans cet outil, voilà pourquoi le document d'exemple les inclut tous les deux. La distinction compte lorsque vous écrivez pour une cible que vous ne contrôlez pas, car un tableau ne fait pas partie du CommonMark proprement dit et un analyseur strict le fera passer en texte brut.
Ce que changent réellement les quatre bascules
La liaison automatique transforme une URL nue en ancre. C'est pratique pour les notes de version et les notes, mais c'est un écart par rapport au CommonMark, qui exige des crochets autour d'un lien nu. Désactivez-la si la sortie doit être portable vers un analyseur strict.
La typographie intelligente réécrit les guillemets droits en guillemets courbes et convertit -- en tiret demi-cadratin. C'est approprié pour la prose et inapproprié pour tout ce qui contient des fragments de code hors d'un bloc de code, car elle s'attaquera volontiers à un drapeau de ligne de commande. Les spans de code et les blocs clôturés sont toujours laissés intacts.
Les sauts de ligne durs changent le sens d'un saut de ligne unique. Par défaut, Markdown joint les lignes consécutives en un seul paragraphe, ce que suppose la plupart des documents. Une saisie de style discussion où l'on appuie sur Entrée pour une nouvelle ligne a besoin de cette option, sinon sa mise en forme s'effondre.
Le passage du HTML brut est celui qui a des conséquences pour la sécurité. Désactivé, un <img onerror=...> de la source est échappé et affiché comme du texte. Activé, il est émis comme balisage vivant. Laissez-le désactivé pour tout ce qui est soumis par un utilisateur.
L'assainissement est un travail distinct
L'erreur la plus courante avec tout pipeline Markdown est de supposer que le convertisseur vous protège. Il ne le fait pas, et il n'est pas censé le faire. Même avec le HTML brut désactivé, une cible de lien reste contrôlée par l'attaquant, si bien que [click](javascript:alert(1)) produit une ancre qu'un navigateur peut honorer. La syntaxe Markdown à elle seule suffit à construire une attaque fonctionnelle.
Le bon modèle est convertir, puis assainir, puis insérer. Faites passer le HTML par un assainisseur dédié comme DOMPurify avec une liste autorisée de balises et d'attributs, et seulement alors placez-le dans la page. Faites-le sur le serveur si le contenu doit être montré à quelqu'un d'autre que son auteur, car un assainissement côté client peut être contourné par quiconque peut parler directement à votre API. Cet outil rend son aperçu localement dans votre propre navigateur avec votre propre saisie, ce qui est un modèle de menace différent de la publication du Markdown de quelqu'un d'autre.