Dieser Markdown-zu-HTML-Konverter wandelt gewöhnliches Markdown schon während der Eingabe in sauberes, sofort verwendbares HTML um. Ein kleiner Markdown-Parser läuft direkt in Ihrem Browser; es werden keine Daten an einen Server gesendet.
Geben Sie links ein oder fügen Sie es ein. Die Ausgabe erscheint rechts, entweder als Roh-HTML oder als gerenderte Vorschau. Kein Warten, kein Absenden-Button, kein Neuladen der Seite.
Was es konvertiert:
- Überschriften, Absätze, fett, kursiv, durchgestrichen, Links, Bilder, Blockzitate und horizontale Linien
- Sortierte, ungeordnete und verschachtelte Listen sowie Aufgabenlisten im GitHub-Stil mit Kontrollkästchen
- Pipe-Tabellen, einschließlich Spaltenausrichtung aus der Zeile
:---: - Umzäunte Codeblöcke, hervorgehoben in der Vorschau mit highlight.js (EN)
- Fußnoten (
[^1]) und Definitionslisten - YAML-Titelthema, das vom oberen Rand des Dokuments entfernt wird
- Rohes Inline-HTML, das unverändert durch
Baut für echte Arbeitsabläufe. Der Editor hat Zeilennummern, eine Formatierungs-Symbolleiste und richtige Undo / Redo. Tab fügt zwei Leerzeichen ein. Gepaarte Zeichen wie **, _ und Backticks werden automatisch um den ausgewählten Text geschlossen. Ihr Entwurf wird im Browser gespeichert und beim erneuten Laden wiederhergestellt.
Das Ausgabefenster bietet Ihnen Optionen: Roh-HTML kopieren, ein vollständiges eigenständiges HTML-Dokument mit eingebetteten Stilen kopieren, einfachen Text kopieren, den ursprünglichen Markdown kopieren oder das Ergebnis als .html-Datei herunterladen.
Der Dunkelmodus ist enthalten. Die Paneele sind veränderbar. Die Bildlaufposition wird zwischen Editor und Vorschau synchronisiert. Dokumente über 20.000 Zeichen werden immer noch konvertiert, mit einer kurzen Verzögerung und einem Warnhinweis.
So verwenden Sie diesen Markdown zu HTML Konverter
- Fügen Sie Ihr Markdown in das linke Bedienfeld ein oder klicken Sie auf Beispiel, um ein Dokument zu laden, das alle unterstützten Funktionen ausübt.
- Verwenden Sie die Symbolleiste, um eine Auswahl fett, kursiv oder in Code umzuwandeln oder um Überschriften, Listen, Zitate, Links, Bilder, Codeblöcke und Fußnoten einzufügen.
- Wechseln Sie zwischen der Registerkarte HTML, auf der das generierte Markup angezeigt wird, und der Registerkarte Vorschau, auf der es gerendert wird.
- Klicken Sie auf HTML kopieren für ein Fragment, das Sie in ein CMS einfügen können, oder auf Vollständig kopieren für eine komplette Seite mit einem kleinen eingebetteten Stylesheet.
- Klicken Sie auf Download, um die Ausgabe als
converted.htmlzu speichern.
Ein kurzes GFM-Dokument wie dieses:
## Release notes
- [x] Tables with **alignment**
- [ ] ~~Autolinks~~
| Feature | Status |
|:--------|-------:|
| Footnotes[^1] | Done |
[^1]: Rendered at the bottom of the document.kommt heraus als:
<h2 id="release-notes">Release notes</h2>
<ul>
<li><input type="checkbox" disabled checked> Tables with <strong>alignment</strong></li>
<li><input type="checkbox" disabled> <del>Autolinks</del></li>
</ul>
<table>
<thead>
<tr><th style="text-align:left">Feature</th><th style="text-align:right">Status</th></tr>
</thead>
<tbody>
<tr><td style="text-align:left">Footnotes<sup><a href="#mdconv-fn-1" id="mdconv-fnref-1">[1]</a></sup></td><td style="text-align:right">Done</td></tr>
</tbody>
</table>
<div class="mdconv-footnotes">
<ol>
<li id="mdconv-fn-1">Rendered at the bottom of the document. <a href="#mdconv-fnref-1">↩</a></li>
</ol>
</div>Überschriften erhalten eine id, die aus ihrem Text generiert wird, sodass Ankerlinks sofort funktionieren.
Was das Tool nicht macht
- Bare URLs werden nicht in Links umgewandelt. Schreiben Sie sie als
[text](url). - Der HTML-Tab zeigt dein Markup genau so an, wie es generiert wurde, einschließlich des von dir eingegebenen Roh-HTML. Nur der Vorschau-Bereich läuft durch einen Zulassungslisten-Bereiniger, der Skripts, Event-Handler und unsichere URLs vor dem Rendern löscht.
- Die Syntaxhervorhebung wird nur in der Vorschau angewendet. Das kopierte HTML enthält einfache
<pre><code class="language-js">-Blöcke, die Sie selbst gestalten können. - Wenn Sie nur die Wörter benötigen, entfernt der HTML-zu-Text-Konverter die Tags wieder.
Was ist ein Markdown zu HTML Konverter?
Ein Markdown-zu-HTML-Konverter ist ein Parser-Tool, das in Markdown-Syntax geschriebenen Klartext nimmt und gültiges HTML-Markup ausgibt.
Es ist kein Texteditor, und es zeigt nicht nur formatierten Text auf einem Bildschirm an. Es erzeugt die tatsächlichen HTML (EN)-Tags, die ein Browser oder ein Content-System rendern kann.
Das Werkzeug befindet sich zwischen zwei Zuständen desselben Dokuments. Einer ist lesbar für einen Menschen, der andere ist lesbar für eine Maschine.
- Markdown-Quelle: Klartext, der von Hand geschrieben oder in einem Editor generiert wurde
- Parsing-Phase: liest die Syntax und erstellt daraus eine Struktur
- Rendering-Phase: schreibt das endgültige HTML-Markup aus
John Gruber veröffentlichte Markdown im Jahr 2004 (EN), aufgebaut um eine einfache Idee: Schreiben sollte als Klartext lesbar bleiben und trotzdem sauber in strukturiertes Markup umgewandelt werden.
Der Begriff erscheint jetzt überall in Entwickler-Tools. Readme-Dateien, statische Website-Builder, Notiz-Apps und Dokumentationsplattformen stützen sich alle auf eine Version dieses gleichen Konvertierungsschritts.
Was ist CommonMark und wie definiert es die Markdown-zu-HTML-Konvertierung?
CommonMark (EN) ist eine formale Spezifikation für Markdown-Syntax, die Beispiel für Beispiel genau definiert, welche Ausgabe ein Konverter für eine gegebene Eingabe erzeugen muss.
Original Markdown hatte diese Garantie nie. Zwei Konverter könnten dieselbe Datei lesen und zwei unterschiedliche Ergebnisse zurückgeben, was das gesamte Problem ist, das CommonMark beheben wollte.
CommonMark-Spezifikation
Jede Regel in der Spezifikation wird mit einem funktionierenden Beispiel geliefert. Überschriften, Listen, Hervorhebung und Link-Syntax erhalten jeweils eine präzise, testbare Definition anstelle einer losen Beschreibung.
- Verschachtelte Strukturen, wie eine Liste innerhalb eines Blockzitats, werden ausgeschrieben, anstatt zu vermuten
- Parser können direkt gegen die Spezifikation geprüft werden, ein Prozess, den die Community Konformitätsprüfung nennt.
- Tools wie Babelmark (EN) ermöglichen es Entwicklern zu vergleichen, wie verschiedene Parser dieselbe Eingabe nebeneinander rendern
Die meisten aktiv gepflegten Bibliotheken, einschließlich markdown-it (EN) und cmark (EN), bauen nach dieser Spezifikation anstatt der ursprünglichen 2004 Syntax.
GitHub rendert jede Ausgabe, Pull-Anfrage und Readme-Datei über seine eigene Implementierung der Spezifikation, cmark-gfm (EN). Das Ziel ist es, die Formatierung über die gesamte Plattform hinweg konsistent zu halten.
GitHub Flavored Markdown-Erweiterungen
GitHub Flavored Markdown (EN), abgekürzt GFM, ist eine strenge Übermenge von CommonMark. Alles, was CommonMark unterstützt, funktioniert weiterhin, GFM fügt nur eine Handvoll Erweiterungen hinzu, die GitHub benötigt.
| Extension | Was es hinzufügt |
|---|---|
| Tabellen | Pipe-getrennte Tabellensyntax |
| Aufgabenlisten | Checkbox-Elemente in einer Liste |
| Durchgestrichen | Doppeltilde-Textstil |
| Autolinks | Bare URLs automatisch in anklickbare Links umgewandelt |
GitLab hat seinen eigenen vergleichbaren Dialekt entwickelt, GitLab Flavored Markdown (EN), größtenteils aus dem gleichen Grund, aus dem GitHub GFM entwickelt hat: Die plattformspezifische Syntax erfordert ein eigenes getestetes Regelwerk.
Wie analysiert und rendert ein Markdown-zu-HTML-Konverter Text?
Ein Markdown-zu-HTML-Konverter arbeitet in zwei Stufen. Es analysiert den Quelltext in eine strukturierte Darstellung und rendert dann diese Struktur in HTML-Tags.
Welche Methode die erste Stufe behandelt, entscheidet über fast alles andere: Geschwindigkeit, Genauigkeit und wie gut das Tool mit unordentlicher oder tief verschachtelter Syntax umgeht.
Regex-basiertes Parsing
Regex-basierte Parser scannen Text zeileweise und passen Muster wie # für eine Überschrift oder * für Hervorhebung an.
- Schnell bei kurzen, gut formatierten Dokumenten
- Schwierigkeiten mit verschachtelten Strukturen, wie z. B. eine Liste innerhalb eines Blockzitats
- War der dominante Ansatz, bevor CommonMark existierte
Showdown (EN) und das ursprüngliche Markdown.pl verwenden beide diese Methode, und es zeigt sich, wie sie sich gelegentlich in Randfällen unterscheiden.
AST- und Tokenizer-basiertes Parsing
Tokenizer-basierte Parser brechen die Eingabe zuerst in Token auf und erstellen dann einen abstrakten Syntaxbaum, bevor irgendetwas gerendert wird.
Das ist ein wirklich anderer Ansatz. Der Parser versteht die gesamte Struktur des Dokuments, bevor er ein einzelnes HTML-Tag schreibt.
| Approach | Griffe zum Verschachteln | Typische Geschwindigkeit | Beispiel |
|---|---|---|---|
| Regex-basiert | Schwach bei tiefem Nesting | Sehr schnell auf einfachen Text | Showdown |
| AST-basiert | Handles Nesting nativ | Schnell, etwas mehr Overhead | markdown-it |
VS Code (EN)'s integrierte Vorschaufenster läuft auf Markdown-it intern. Es stützt sich auf diese Tokenizer-Architektur für die konsistente Handhabung von verschachtelten Listen innerhalb von Blockquotes.
Was macht einen Markdown-zu-HTML-Konverter schnell oder genau?
Die Geschwindigkeit hängt davon ab, wie wenig Arbeit der Parser pro Zeichen leistet. Die Genauigkeit hängt davon ab, wie genau die Ausgabe den Konformitätstests der CommonMark-Spezifikation entspricht.
Diese beiden Ziele ziehen häufiger in unterschiedliche Richtungen, als die Leute erwarten. Ein reduzierter Regex-Parser kann einen vollständigen Tokenizer auf einfachem Text überflügeln und dann auseinanderfallen, sobald die Eingabe chaotisch wird.
Kennzahlen:
- Die aktuelle Version von CommonMark ist Version 0.31.2 (EN), veröffentlicht im Januar 2024
- Die Spezifikation enthält 652 eingebettete Konformitätsbeispiele, die jeweils eine Markdown-Eingabe mit der exakten HTML-Ausgabe verbinden, die ein konformer Parser generieren muss.
- Die GFM-Spezifikation (EN) ist in der Version 0.29-gfm, zuletzt offiziell veröffentlicht im Jahr 2019, und funktioniert immer noch als GitHub-Referenz für GFM-Rendering
Ein Parser, der gegenüber diesen Konformitätsbeispielen gut abschneidet, ist per Definition genauer. Einer, der die Spezifikation komplett überspringt, wie der ursprüngliche Showdown, hat keinen solchen Benchmark, mit dem er verglichen werden kann.
Die Entscheidung von GitLab, eine eigene Spezifikation zu veröffentlichen, folgte der gleichen Logik, die GitHub für GFM verwendet hat: Ein dokumentiertes, testbares Regelwerk übertrifft jedes Mal, wenn ein Parser aktualisiert wird, ein informelles.
Wie gehen Markdown-zu-HTML-Konverter mit Sicherheit und Sanierung um?
Markdown erlaubt rohes HTML innerhalb eines Dokuments, und dieses rohe HTML wird direkt durch die meisten Konverter übergeben, es sei denn, etwas zieht es heraus.
Das ist genau die Öffnung, die ein Angreifer braucht. Ein Kommentarfeld, eine Wiki-Seite oder eine Readme, die Markdown von einer nicht vertrauenswürdigen Quelle akzeptiert, kann ein Skript-Tag direkt in die gerenderte Seite übertragen.
Werkzeuge und Bibliotheken für die Desinfektion
Die Desinfektion ist normalerweise ein separater Schritt von der Konvertierung, nicht etwas, das in den Parser selbst eingebaut ist.
- Tag allowlisting strips Scripts, Event-Handler-Attribute und alles außerhalb eines genehmigten Tag-Sets
- DOMPurify (EN), gepflegt von der Sicherheitsforschungsgruppe Cure53, ist die Bibliothek, auf die die meisten JavaScript-Projekte nach der Konvertierung zurückgreifen
- Einige Konverter, wie Showdown, bieten eine eingebaute Desinfektionsoption, obwohl sie weit weniger gründlich ist als eine dedizierte Bibliothek.
Dieser Schritt wird üblicherweise im Backend (EN) ausgeführt, kurz bevor das konvertierte HTML gespeichert oder ausgeliefert wird, anstatt dem Browser zu vertrauen, dass er etwas Gefährliches erkennt.
Die OWASP Top 10 für 2021 (EN) platziert Injektionsschwächen, die Kategorie, die sich beim Cross-Site-Scripting zusammenfaltet, insgesamt auf Platz drei. Es protokollierte 274.228 Vorfälle in den getesteten Anwendungen.
Die markdown-js (EN)-Bibliothek trägt nun einen Hinweis "unmaintained" in ihrem Repository, und ihr npm-Paket hat einen veröffentlichten regular expression denial of service advisory (EN). Das ist eine direkte Folge seines regex-basierten Designs.
Welcher Markdown zu HTML Konverter passt zu Ihrer Plattform?
Der richtige Konverter hängt in der Regel von der Sprache ab, die Ihr Stack bereits ausführt, und nicht von einer universellen besten Wahl.
| Werkzeug | Platform | Parsingmethode | Unterstützung durch GFM |
|---|---|---|---|
| Marked.js (EN) | JavaScript | Tokenizer-basiert | Eingebaut in |
| Python-Markdown (EN) | Python | Regex mit Erweiterungshaken | Über Erweiterungen |
| Kramdown (EN) | Ruby | Rekursiv-absteigender Parser | Partial |
| Pandoc (EN) | Cross-Language | AST-basiert | Über Reader-Optionen |
JavaScript-Konverter
Marked.js und Showdown laufen beide im Frontend (EN) und konvertieren Markdown direkt im Browser in HTML, ohne einen Server-Hin- und Rückweg.
- Marked.js konzentriert sich auf Geschwindigkeit und engere CommonMark-Konformität
- Showdown ist älter als CommonMark und bietet ein integriertes sanitize-Flag
- Beide werden über npm installiert und in einen existierenden JavaScript (EN) Build mit fast keiner Konfiguration eingefügt
Python-Konverter
Python-Markdown ist die Standardwahl innerhalb von Python-Projekten und wird als pip-Paket anstatt als eigenständige Binärdatei geliefert.
Erweiterungsbasierte Architektur: Die Kernsyntax-Bearbeitung bleibt minimal, und Funktionen wie Tabellen oder Fußnoten werden als separate Erweiterungsmodule hinzugefügt.
Dokumentationsgeneratoren wie MkDocs (EN) bauen direkt darauf auf, anstatt einen eigenen Parser zu schreiben.
Ruby Converters
Kramdown und Redcarpet (EN) decken beide Ruby-Projekte ab, obwohl sie sich auf unterschiedliche interne Architekturen stützen.
Kramdown liest näher an eine Übermenge von Markdown heran und unterstützt Definitionslisten und Inline-Attributlisten, die CommonMark nicht definiert.
Redcarpet tauscht einen Teil dieser Flexibilität gegen die reine Parsing-Geschwindigkeit ein, weshalb es immer noch in älteren Rails-Dokumentationspipelines angezeigt wird.
Sollten Sie einen Online Converter, eine Bibliothek, eine API oder ein Plugin verwenden?
Die Zugriffsmethode ist ebenso wichtig wie der Parser selbst, da sie darüber entscheidet, wo die Konvertierung tatsächlich stattfindet und wer sie pflegen muss.
Online-Konverter
Tools wie Dillinger (EN) und HackMD laufen komplett in einem Browser-Tab, keine Installation erforderlich.
- Pros: Null Setup, gut für ein einmaliges Dokument, keine Abhängigkeiten zu verfolgen
- Nachteile: Nicht geeignet für automatisierte Pipelines, das Einfügen sensibler Inhalte in eine Website eines Drittanbieters ist ein echtes Problem
Andere Single-Purpose-Browser-Tools folgen dem gleichen Modell für verschiedene Formate. Ein Word-zu-HTML-Konverter verwandelt Dokumente in Markup und ein HTML-Tabellengenerator erstellt Tabellen ohne Markdown.
Bibliotheken und APIs
Durch die Installation einer Bibliothek (Marked.js, Python-Markdown, Kramdown) wird die Konvertierung direkt in einen Build-Prozess oder eine Serveranforderung integriert.
Eine gehostete API (EN) erledigt die gleiche Aufgabe, ohne eine zu verwaltende Abhängigkeit hinzuzufügen, auf Kosten eines Netzwerkaufrufs und normalerweise eines Nutzungslimits.
- Pros: Skaliert mit der App, kein manueller Schritt, funktioniert in automatisierten Pipelines
- Nachteile: eine Bibliothek benötigt immer noch Versionsaktualisierungen, eine API braucht immer noch ein Fallback für Ausfallzeiten
CMS-Plugins für WordPress
Ein Plugin umschließt einen Konverter in einer bestehenden Content-Plattform, sodass Redakteure in Markdown schreiben können, ohne die bereits verwendete Oberfläche zu verlassen.
Vorteile: kein separater Build-Schritt für Inhaltsautoren, vertraute Bearbeitungserfahrung.
Nachteile: das Plugin ist nur so aktuell wie sein Betreuer es hält. Verlassene Plugins sind eine häufige Ursache für die zuvor behandelten Lücken bei der Desinfektion.
Wie konvertieren Sie Markdown in HTML in Code, Schritt für Schritt?
Die Konvertierung von Markdown in HTML mit einer Bibliothek folgt in fast jedem Tool ungefähr derselben Reihenfolge, unabhängig davon, ob es in einer Browser-Registerkarte oder in einer Build-Pipeline ausgeführt wird.
Das Überspringen eines Schritts, insbesondere der Desinfektion, ist die Ursache für die meisten Konvertierungsfehler in der Praxis.
- Installieren oder laden Sie den Konverter. Fügen Sie die Bibliothek über npm, pip oder einen Gem hinzu, oder öffnen Sie ein browserbasiertes Werkzeug, wenn kein Build-Schritt existiert.
- Übergeben Sie die Markdown-Quelle an den Parser. Dies ist normalerweise ein einzelner Funktionsaufruf, etwa
marked.parse(text)odermarkdown.markdown(text). - Legen Sie vor dem Rendern die Variante und die Erweiterungen fest. Entscheiden Sie, ob GFM-Tabellen, Fußnoten oder Aufgabenlisten für dieses Dokument aktiv sein sollen.
- Die Ausgabe desinfizieren. Führen Sie das Roh-HTML durch einen dedizierten Desinfizierer, bevor es eine Vorlage oder eine Datenbank erreicht.
- Fügen Sie den fertigen HTML-Code ein. Fügen Sie ihn in eine Vorlage, ein Inhaltsfeld oder direkt auf die Seite ein.
Das Überspringen von Schritt vier ist der häufigste Fehler in dieser Reihenfolge. Es ist auch der Schritt, den die meisten Schnellstart-Tutorials komplett weglassen.
Die meisten Konverter bündeln Parsing und Rendering in einem Funktionsaufruf, wodurch die Tatsache verschleiert wird, dass darunter zwei separate Phasen stattfinden.
Wie integrieren Sie einen Markdown-zu-HTML-Konverter in eine Website oder ein CMS?
Integration bedeutet normalerweise, dass der Konvertierungsschritt in einen Build-Prozess verschwindet, sodass niemand einen Konverter von Hand ausführt.
Wo sich dieser Schritt tatsächlich befindet und wann er ausgelöst wird, ändert sich je nach Plattform darunter.
Statische Site-Generatoren
Statische Website-Generatoren führen den Konverter einmalig zum Zeitpunkt der Erstellung aus und speichern das resultierende HTML im Cache, anstatt es bei jeder Seitenanforderung zu konvertieren.
- Hugo verwendet standardmäßig Goldmark (EN), einen vollständig CommonMark-kompatiblen Parser
- Jekyll ist standardmäßig auf Kramdown eingestellt (EN) und verwendet den GitHub Flavored Markdown Eingabemodus.
- Beide zwischenspeichern die konvertierte Ausgabe, so dass eine Seite nur dann erneut konvertiert wird, wenn sich die Quelldatei tatsächlich ändert
Kubernetes (EN)' eigene Dokumentationsseite läuft auf Hugo und konvertiert seine Markdown-Quelldateien in das statische HTML, das auf kubernetes.io bereitgestellt wird.
Die Konvertierung zur Build-Zeit erhöht die Geschwindigkeit zur Anforderungszeit. Der Kompromiss ist ein Neubauschritt jedes Mal, wenn sich der Quellinhalt ändert.
Plattformen für Dokumentation
Docusaurus (EN) nimmt einen anderen Weg. Es läuft Markdown und MDX (EN) durch eine remark (EN) und rehype Pipeline, bevor React jemals eine Seite rendert.
MDX ermöglicht es einem Dokument, einfaches Markdown mit eingebetteten React-Komponenten zu mischen, etwas, das keiner der Ruby- oder Python-Konverter bisher versucht hat.
| Platform | Standard-Parser | Raw-HTML-Handling |
|---|---|---|
| Hugo | Goldmark | Entfernt, es sei denn, der unsichere Modus ist aktiviert |
| Jekyll | Kramdown (GFM-Modus) | Standardmäßig übergeben |
| Docusaurus | Bemerkung und MDX-Pipeline | Wird als JSX behandelt, nicht als reines HTML |
MkDocs, das auf der Python-Markdown-Bibliothek aufbaut, die zuvor behandelt wurde, folgt dem einfachen statischen Generator-Modell anstelle des MDX-Modells.
Wann schlägt ein Markdown-zu-HTML-Konverter fehl oder erzeugt Fehler?
Ein Markdown-zu-HTML-Konverter bricht an vorhersehbaren Grenzen zusammen: verschachtelte Syntax, nicht übereinstimmende Varianten und rohes HTML, das ohne Vorwarnung entfernt wird.
Nichts davon bedeutet, dass das Werkzeug selbst kaputt ist. Es bedeutet, dass die Eingabe eine Funktion annahm, für die der Parser nie konfiguriert war.
Häufige Konvertierungsfehler
Verschachtelte Syntax erzeugt die sichtbarsten Fehler. Eine Liste innerhalb eines Blockzitats kann in einen einzelnen flachen Absatz zusammenfallen, anstatt verschachtelt zu bleiben.
- Eine Tabelle, die in GFM-Syntax geschrieben ist, wird als einfacher, nicht stilisierter Absatz in einem strengen CommonMark-only-Parser dargestellt, da Tabellen nicht Teil der Basisspezifikation sind.
- Fußnoten verschwinden lautlos auf jedem Parser, der diese Erweiterung nie hinzugefügt hat
- Eine lose Liste, eine mit leeren Zeilen zwischen den Elementen, umfasst jedes Element in einem eigenen Absatz-Tag, wodurch sich der Abstand unerwartet ändert
Selbst GitHubs eigenes Tooling ist nicht immun gegen Drift. Das cmark-gfm-Projekt hatte offene Probleme, bei denen die veröffentlichte HTML-Version seiner Spezifikation nicht mit der zugrunde liegenden Spezifikationsdatei synchron war. Das brach die nummerierten Beispiellinks, auf die sich die Leute als Referenz verlassen haben.
Strukturelle und Geschmackseinschränkungen
Flavour-Fehlanpassungen verursachen mehr stille Fehler als offene Fehler. Der Konverter gibt keine Warnung aus, er rendert nur etwas leicht falsch.
Jekylls eigene Dokumentation stellt klar, dass CommonMark sich vom ursprünglichen Markdown unterscheidet und nicht jedes Merkmal unterstützt, das nur in Kramdown vorkommt, einschließlich Block-Inline-Attributlisten.
- Rohe HTML-Blöcke: von Hugos Goldmark-Parser entfernt, es sei denn, der "unsicher" Modus ist aktiviert
- Nur Kramdown-Syntax: wird von einem strengen CommonMark-Parser vollständig ignoriert
- Typografische Ersetzungen: Smart Quotes und Bindestriche werden inkonsistent über Konverter angewendet, die nicht denselben Erweiterungssatz teilen
Einige Dokumente müssen überall identisch dargestellt werden, von einer Readme-Datei über eine Dokumentationsseite bis hin zu einem E-Mail-Digest. Für diese ist es wichtiger, eine Variante auszuwählen und direkt gegen sie zu testen, als den schnellsten Parser auszuwählen.
Häufige Fragen: Markdown in HTML umwandeln
Wie unterscheidet sich Markdown als Format von HTML?
Markdown ist eine leichte Klartext-Syntax, während HTML die vollständige Auszeichnungssprache ist, die Browser tatsächlich lesen.
Ein einzelnes Markdown-Symbol, wie ein Sternchen, erweitert sich während der Konvertierung in mehrere HTML-Tags. Markdown bleibt ungerendert lesbar, Roh-HTML selten.
Wer hat Markdown entwickelt und warum ist es wichtig für Konvertierungstools?
John Gruber veröffentlichte Markdown im Jahr 2004, mit dem Ziel, dass Texte auch vor der Konvertierung lesbar bleiben.
Jeder moderne Markdown-zu-HTML-Konverter ehrt immer noch dieses ursprüngliche Ziel: lesbare Quelle, saubere Ausgabe. CommonMark formalisierte später seine Syntax in eine testbare Spezifikation.
Ist die Markdown-zu-HTML-Konvertierung kostenlos und spielt Open Source eine Rolle?
Die meisten Markdown-zu-HTML-Konverter, einschließlich Marked.js, Python-Markdown und Kramdown, sind frei und Open Source.
Open Source ist hier wichtig, da sich die Genauigkeit durch öffentliche Konformitätstests gegen CommonMark verbessert. Kostenpflichtige Optionen existieren hauptsächlich als gehostete APIs mit Nutzungsbeschränkungen.
Wie überprüfen oder testen Sie, ob die HTML-Ausgabe korrekt ist?
Führen Sie die Ausgabe des Konverters mit der Konformitätstest-Suite von CommonMark (EN) aus oder vergleichen Sie die Ergebnisse über Parser hinweg mit Babelmark (EN).
Überprüfen Sie bei benutzerdefinierten Pipelines zunächst visuell verschachtelte Listen, Tabellen und rohe HTML-Blöcke, da dort die Ausgabe am häufigsten unterbrochen wird.
Was sollten Sie zuerst beheben, wenn ein Markdown-zu-HTML-Konverter kaputt geht?
Ein Markdown-zu-HTML-Konverter bricht am deutlichsten an den Lücken bei der Bereinigung, daher hat die Behebung der Sicherheitsschicht Vorrang vor Geschmackskonflikten oder Macken bei der verschachtelten Syntax. Ein nicht bereinigtes Skript-Tag, das eine Live-Seite erreicht, birgt weitaus größere Risiken als eine einzelne falsch gerenderte Tabelle.
- Rohe HTML-Ausgabe vor allem anderen desinfizieren
- Bestätigen Sie, dass die Markdown-Variante mit den Quelldokumenten übereinstimmt
- Testen Sie verschachtelte Syntax-Edge-Cases zuletzt
Wer zur Behebung von Unterschieden zwischen Markdown-Varianten ausschließlich striktes CommonMark zulässt, verliert die Erweiterungen von GitHub Flavored Markdown, etwa Tabellen und Aufgabenlisten, sofern ein Plugin sie nicht anschließend wieder ergänzt.
Sobald das konvertierte Markup stabil ist, leiten Teams diese Ausgabe normalerweise durch einen HTML Beautifier (EN), um den Einzug vor der Bereitstellung zu normalisieren.