Konvertieren Sie XML in Markdown online kostenlos

XML in Markdown umwandeln: Tags raus, Hierarchie rein

XML hat eine Angewohnheit, die sonst kein Format teilt: Es schreibt den Namen jedes Elements zweimal hin. Einmal zum Öffnen, einmal zum Schließen. Nehmen Sie Namespace-Präfixe dazu, Attribute, die Einrückung, die das Ganze lesbar macht — und schon haben Sie routinemäßig eine Datei, in der die Tags mehr wiegen als der Inhalt, den sie umschließen. Ein Produktkatalog mit 200 Artikeln kann tausende Zeilen lang sein und trotzdem etwa anderthalb Seiten echte Information enthalten.

Eine Konvertierung von XML nach Markdown behält den Baum und wirft das Zeremoniell weg. Aus der Elementverschachtelung werden Überschriftenebenen, aus wiederholten Geschwisterelementen Listen oder Tabellen, und die spitzen Klammern verschwinden. Laden Sie oben eine .xml-Datei hoch und Sie bekommen sie in wenigen Sekunden zurück — kostenlos, ohne Anmeldung, 50 MB Obergrenze, nichts wird aufbewahrt.

Was aus dem Elementbaum wird

Die Konvertierung läuft durch das Dokument und übersetzt jedes Konstrukt einzeln:

• Container-Elemente werden zu Überschriften. Ein Element mit Kindelementen, aber ohne eigenen Text, ist ein Abschnitt. Seine Tiefe im Baum bestimmt die Überschriftenebene, sodass ein fünf Ebenen tiefes Unternehmensschema als sauber gegliedertes Dokument ankommt.
• Blattelemente werden zu beschrifteten Werten. <author>Ursula Le Guin</author> liest sich als author: Ursula Le Guin. Ein Name statt zwei, keine Klammern.
• Wiederholte Geschwisterelemente werden zu Listen oder Tabellen — dazu unten mehr, denn dort steckt der größte Teil des Nutzens.
• Gemischter Inhalt bleibt inline. Das ist der Fall, in dem Text und Kindelemente sich abwechseln, etwa bei <para>See the <ref>appendix</ref> for details</para>. Naive Konverter zerlegen das in Fragmente und der Satz ist weg. Richtig gemacht kommt es als eine lesbare Zeile durch, die Referenz intakt.
• Kommentare, Processing Instructions und die XML-Deklaration fliegen raus. Nichts davon ist Inhalt.

Attribute: der Teil, den man verliert, ohne es zu merken

XML legt Daten an zwei Stellen ab — zwischen den Tags und in den Tags. Elementtext ist offensichtlich. Attribute übersieht man leicht, und viele naive Extraktoren lassen sie klammheimlich fallen. Bei Metadaten wie id="4471" ist das kein Problem. Ist das Attribut die Nutzlast, ist es eine Katastrophe.

Und das kommt oft vor. <price currency="GBP">49.99</price> ist ohne die Währung bedeutungslos. Bei Konfigurationsformaten ist es noch schlimmer — Maven, Ant, Spring, Android-Manifeste und .NET-app.config-Dateien packen häufig fast alles in Attribute. Eine Extraktion, die nur Elementtext kennt, liefert für so eine Datei ein Dokument, das strukturell korrekt und fast völlig leer ist. Wenn Sie eine Konfigurationsdatei konvertieren und die Ausgabe verdächtig kurz aussieht, ist das der Grund.

In der Markdown-Ausgabe sollten Attribute neben dem Element stehen, zu dem sie gehören, statt zu verschwinden — als kurzer Zusatz neben dem Wert, oder als zusätzliche Spalten, wenn das Element Teil einer wiederkehrenden Menge ist. Vergleichen Sie den ersten Bildschirm Ausgabe mit der Quelle, bevor Sie ihr etwas Wichtiges anvertrauen. Zehn Sekunden Überfliegen sind besser als eine später völlig verdrehte Unterhaltung mit einem Modell.

Aus wiederholten Geschwisterelementen werden Tabellen

Der beste Fall für XML ist ein Elternelement mit vielen identischen Kindern: <item>-Elemente in einem RSS-Feed, <row>-Elemente in einem Datenbankexport, <employee>-Datensätze in einem HR-Dump. Jedes Kind hat dieselben Unterelemente in derselben Reihenfolge.

Das fällt zu einer einzigen Markdown-Pipe-Tabelle zusammen. Die Namen der Unterelemente werden zu Spaltenüberschriften, jeder Datensatz zu einer Zeile, und die Tag-Wiederholung — die in der Rohdatei bedeutete, jeden Feldnamen zweimal pro Datensatz hinzuschreiben — passiert genau einmal, in der Kopfzeile. Das ist die größte Einsparung, die Sie bei irgendeiner XML-Konvertierung sehen werden, und genau der Grund, für alles Datensatzförmige Markdown statt reinen Text zu nehmen.

Es bröckelt, wenn die Datensätze ausgefranst sind — optionale Elemente, die bei manchen Kindern da sind und bei anderen nicht, oder ein Kind mit einem verschachtelten Block, den die übrigen nicht haben. Dann bekommen Sie Lücken, oder der verschachtelte Teil rutscht unter die Tabelle. Sind Ihre Daten wirklich rechteckig, liefert ein Export nach CSV plus der CSV-zu-Markdown-Konverter sauberere Tabellen. Und wenn die Quelle eher JSON- als Tag-förmig ist, packt der JSON-zu-Markdown-Konverter dasselbe Problem von der anderen Seite an.

Namespaces, Envelopes und Enterprise-Ballast

XML aus der freien Wildbahn ist selten sauber. Drei Dinge blähen es weit über seinen Informationsgehalt hinaus auf:

• Namespaces. xmlns-Deklarationen und Präfixe wie soap:, xsi:, atom: oder dc: gibt es, um Namenskollisionen zwischen Vokabularen zu verhindern. Für einen Leser bedeuten sie nichts. Bei der Konvertierung fallen die Präfixe weg, sodass <dc:creator> als creator erscheint. Aufpassen müssen Sie nur, wenn zwei Namespaces tatsächlich denselben lokalen Namen für verschiedene Dinge verwenden — selten, aber prüfenswert, wenn Sie Vokabulare zusammenführen.
• SOAP-Envelopes. Eine Webservice-Antwort wickelt den Teil, den Sie brauchen, in Envelope und Body, oft dazu noch Header voller Security-Tokens und Routing-Daten. Nach der Konvertierung haben Sie ein Dokument, in dem die Nutzlast endlich sichtbar ist, statt vier Ebenen tief unter Boilerplate zu liegen, die Sie im Kopf überspringen müssen.
• Schema-Verweise. xsi:schemaLocation, DTD-Deklarationen und Validierungsattribute beschreiben, wie die Datei geprüft werden soll, nicht was sie sagt. Für jeden Zweck hier nur Rauschen.

RSS- und Atom-Feeds liegen am freundlichen Ende dieser Skala. Sie sind einheitlich, flach und konvertieren zu einer sauberen Liste datierter Einträge — ein vernünftiger Weg, einem Modell einen Monat Blogbeiträge zu geben. Beachten Sie: Feed-Beschreibungen enthalten meist HTML, das im XML maskiert ist und deshalb als Markup in Ihrer Ausgabe landet. Schicken Sie das durch den HTML-zu-Markdown-Konverter, wenn Sie es sauber wollen, oder nehmen Sie Web2Txt, um die Seiten ordentlich zu holen.

Wann Sie das rohe XML behalten sollten

Eine klare Antwort, weil viele Seiten, die Konverter anpreisen, sie Ihnen schuldig bleiben: Modelle lesen XML einwandfrei. Es ist geschwätzig, aber eindeutig und in Trainingsdaten extrem gut vertreten. Konvertieren ist eine Wahl, keine Pflicht.

Roh behalten, wenn Sie nach XPath-Ausdrücken, einem XSLT-Stylesheet, einem Parser oder einem Schema fragen — überall dort, wo das Modell exakte Elementnamen, Namespace-Präfixe und die Unterscheidung zwischen Attribut und Element reproduzieren muss. Markdown bügelt genau diese Details bewusst glatt. Fügen Sie stattdessen einen repräsentativen Ausschnitt der echten Datei ein.

Konvertieren, wenn ein Mensch es lesen muss, wenn Sie ein unbekanntes Schema schnell verstehen wollen, oder wenn die Rohdatei überwiegend aus Tags besteht und Ihr Kontextfenster knapp ist. Das sind echte Gewinne. Alles andere ist Geschmackssache.

Das XML, von dem Sie nicht wussten, dass es XML ist

Eine ganze Reihe von Formaten, die Sie für binär halten, sind unter der Haube gezipptes XML. Benennen Sie eine .docx in .zip um, entpacken Sie sie, und Sie finden document.xml plus einen Haufen Relationship-Dateien. Bei EPUB dasselbe Bild: XHTML-Inhaltsdokumente und ein XML-Package-Manifest in einem Zip. Bei .pptx ebenso, und bei .xlsx auch.

Sie könnten so ein Archiv entpacken und das XML von Hand konvertieren. Lassen Sie es — das innere Markup steckt voller Formatierungs-Runs, Änderungsverfolgung und Layout-Anweisungen, die den Text überschwemmen. Nehmen Sie Word zu Markdown oder EPUB zu Markdown, die wissen, welche Teile dieses XML Inhalt sind und welche Formatierungsanweisungen. Diese Seite ist für XML gedacht, das Ihnen als XML übergeben wurde: Feeds, Exporte, API-Antworten, Konfiguration, Datenaustausch.

Häufige Fragen

Wie wandle ich XML in Markdown um?

Laden Sie die .xml oben hoch, und die Dokumentstruktur wird auf Markdown abgebildet — aus der Elementhierarchie werden Überschriftenebenen, aus wiederholten Geschwisterelementen Listen oder Tabellen. Kostenlos, 50 MB pro Datei, ohne Anmeldung. Die Form des Dokuments bleibt erhalten, und genau das ist der Unterschied dazu, es zu reinem Text plattzumachen.

Werden aus der Elementhierarchie Überschriftenebenen?

Ja, so ist die Abbildung — ein tiefer verschachteltes Element wird zu einer tieferen Überschrift. Für dokumentförmiges XML wie DocBook, TEI oder einen Artikelexport funktioniert das gut, weil die Verschachtelung dort wirklich Abschnitte in Abschnitten abbildet. Schlecht funktioniert es bei datenförmigem XML, wo die Verschachtelung ein Datenbankschema abbildet und Sie zwölf Überschriftenebenen für einen einzigen Datensatz bekommen.

Was passiert mit Namespace-Präfixen?

Sie fallen aus der Ausgabe heraus. Eine Überschrift dc:title oder tei:head sagt einem Menschen nichts und einem Modell noch weniger, deshalb werden die Präfixe entfernt und der lokale Elementname verwendet. Definieren zwei Namespaces im selben Dokument denselben lokalen Namen, fallen sie zusammen — selten, aber einen Blick wert, wenn Überschriften doppelt wirken.

Taugt das, um DocBook oder DITA zu konvertieren?

Für einen ersten Durchgang ja. Fließtext, Abschnitte, Listen und Inline-Auszeichnungen kommen gut mit, weil diese Formate sie explizit markieren. Conditional Profiling, Content References, Entity-Includes und die Auflösung von Querverweisen überleben nicht — das sind genau die Teile, wegen derer sich das Format gelohnt hat, und kein generischer Konverter kann sie auflösen.

Was nehme ich für ein großes XML-Korpus?

Meistens Text. Wenn Sie Embeddings über tausende Datensätze bauen, ist Überschriftensyntax nur Overhead, der sich in jedem Chunk wiederholt, ohne dem Retrieval zu helfen. Markdown verdient sich seinen Platz, wenn ein Mensch oder ein Modell ein einzelnes Dokument lesen soll und wissen muss, wo die Abschnitte liegen.

Lieber reiner Text — und der Rest des Werkzeugkastens

Wenn Sie überhaupt keine Struktur wollen — Text für Embeddings, einen Suchindex oder die niedrigstmögliche Tokenzahl — nehmen Sie XML zu reinem Text, das den Inhalt zwischen den Tags herausholt und sonst nichts übrig lässt. Der Format-Umschalter oben auf dieser Seite wechselt zwischen beiden und behält Ihre Datei geladen, sodass ein Vergleich beider Ausgaben einen Klick kostet. Der Token-Zähler unter der Ausgabe sagt Ihnen, was jede davon kostet.

Ist das XML eine Datei unter vielen in einem Projekt — eine Konfiguration, ein Build-Deskriptor, ein Fixture — dann gibt eine Einzelkonvertierung dem Modell die Daten ohne den Code drumherum. Mit dem GitHub-Repository-zu-Text-Konverter und dem Konverter für lokale Verzeichnisse nehmen Sie das XML und seine Verwender zusammen, und das ist meist die nützlichere Einheit. File2Txt deckt alle unterstützten Formate an einer Stelle ab, und der Leitfaden zur Aufbereitung von Dateien für LLMs behandelt die allgemeinen Prinzipien.

Repo2Txt wird entwickelt und gepflegt von v12hero, einem unabhängigen Entwickler, der native und Web-Apps mit Fokus auf Datenschutz baut.