Konvertieren Sie XML in Text online kostenlos

Q: Wie kann ich eine XML-Datei in Text umwandeln?

Ziehen Sie die .xml in den Konverter oben, und der Inhalt zwischen den Tags kommt als reiner Fließtext zurück — keine spitzen Klammern, keine Namespace-Präfixe, keine Attribute. Als .txt herunterladen. Kostenlos, ohne Anmeldung, 50 MB pro Datei, nichts wird aufbewahrt.

Q: Werden Entities wie &amp; und &lt; aufgelöst?

Ja, und das wiegt schwerer, als es klingt. XML verträgt kein nacktes kaufmännisches Und, deshalb wimmeln echte Dokumente von &amp;, &lt;, &quot; und numerischen Zeichenreferenzen. Eine naive Regex zum Tag-Entfernen lässt all das wörtlich in der Ausgabe stehen. Sauberes Parsen löst sie zurück in die Zeichen auf, für die sie stehen.

Q: Warum nicht einfach alles zwischen spitzen Klammern per Regex wegschneiden?

Weil CDATA-Abschnitte und Attributwerte beide Zeichen enthalten, die wie Markup aussehen und keines sind. Eine Regex frisst bereitwillig den Inhalt eines <![CDATA[...]]>-Blocks mit eingebettetem HTML, und sie kann ein echtes Tag nicht von einem < unterscheiden, das in einem Attributwert in Anführungszeichen steht. Ein Parser bekommt das richtig hin; Mustererkennung liegt daneben, ohne dass Sie es merken.

Q: Kommen Attributwerte mit durch?

Sie bekommen den Elementtext; Attribute sind Metadaten über das Element, nicht dessen Inhalt. Das ist meistens richtig so — Sie wollen das Abstract, nicht die Schema-Version. Weh tut es bei Formaten, die echten Inhalt in Attributen ablegen. Wirkt Ihre Ausgabe also dünn, öffnen Sie die Quelldatei und schauen Sie nach, ob die gesuchten Wörter in <tag attr="..."> stecken.

Konvertieren Sie XML-Dateien kostenlos online in Text. Datei hochladen und sofort eine saubere, für LLMs geeignete Ausgabe erhalten. Ohne Anmeldung, bis 50 MB, nichts wird gespeichert.

XML in Text umwandeln: den Inhalt zwischen den spitzen Klammern herausholen

Beim Aufbau eines Textkorpus taucht regelmäßig ein bestimmter Dateityp auf: ein XML-Export von etwas wirklich Interessantem — Abstracts aus Fachzeitschriften, Gerichtsprotokolle, ein digitalisiertes Archiv, zehn Jahre Blogbeiträge — bei dem der Fließtext, den Sie brauchen, unter einem Schema begraben liegt, das jemand 2006 entworfen hat. Die Wörter sind da drin. Sie stecken nur in drei Lagen Tags mit Namespace-Präfixen.

Diese Seite holt genau diesen Inhalt heraus und gibt Ihnen nichts als den Text zurück. Keine Überschriften, keine Tabellen, kein Markup irgendeiner Art. Genau das wollen Sie, wenn das Ziel ein Embedding-Modell, ein Suchindex, ein NLP-Skript oder irgendeine Pipeline ist, für die Satzzeichen Rauschen sind. Laden Sie oben eine .xml-Datei hoch — kostenlos, ohne Anmeldung, 50 MB Limit, nichts wird gespeichert.

Was am Ende herauskommt

Extraktion ist mehr, als alles zwischen < und > zu löschen. Ein paar Dinge müssen sauber behandelt werden, sonst ist das Ergebnis auf subtile Weise falsch:

Entity-Referenzen werden aufgelöst. XML verträgt kein nacktes kaufmännisches Und, deshalb sind echte Dokumente voll von &, <, " und numerischen Formen wie ’ für ein typografisches Apostroph. Bleiben die stehen, verfälschen sie jede Wortzählung und lassen Suchtreffer ins Leere laufen. Hier kommen sie als die Zeichen zurück, für die sie stehen.
CDATA-Abschnitte werden ausgepackt. <![CDATA[ ... ]]> ist der Weg, auf dem XML Inhalte mit Markup durchschmuggelt — HTML in einer RSS-Description, ein SQL-Schnipsel, ein JavaScript-Block. Die Hülle fliegt raus, der Inhalt bleibt.
Textknoten, die nur aus Leerraum bestehen, fallen weg. Eingerücktes XML hat zwischen jedem Tag-Paar einen Textknoten, der nichts enthält außer einem Zeilenumbruch und ein paar Leerzeichen. Behalten Sie die, besteht Ihre Ausgabe zu 60 % aus Leerzeilen.
Elementnamen verschwinden vollständig. Anders als in der Markdown-Variante bleiben Tag-Namen hier nicht als Beschriftung erhalten. Sie bekommen die Werte, nicht das Schema.
Kommentare, XML-Deklaration, DTDs und Processing Instructions fliegen raus. Nichts davon ist Inhalt.

Der Wörter-Verkleben-Bug und warum er zählt

Jetzt der Fehlerfall, in den fast jedes naive Tag-Stripping tappt, inklusive vieler schneller Regex-Lösungen, die Leute aus Foren kopieren. Nehmen Sie gemischten Inhalt — Text und Kindelemente wechseln sich im selben Elternelement ab:

<p>See the <ref>appendix</ref> for details</p>

Entfernen Sie die Tags unbedacht, steht am Ende „See theappendixfor details“ da, denn das gelöschte Tag hat die Arbeit einer Wortgrenze erledigt. Gehen Sie in die andere Richtung und setzen an jedem Tag einen Zeilenumbruch, zerfällt ein Satz in drei Fragmente auf drei Zeilen. Beides ist unbrauchbar: das erste zerschießt die Tokenisierung, das zweite die Satzsegmentierung, und beides beschädigt klammheimlich alles, was weiter hinten in der Pipeline davon ausgeht, Fließtext zu lesen.

Korrekt gemacht bleiben Inline-Elemente inline, und umbrochen wird nur an echten Blockgrenzen. Wenn Sie mit einem anderen Werkzeug Text aus einer XML-Datei extrahieren, sollten Sie genau das zuerst testen — suchen Sie einen Absatz mit einem Inline-Tag in der Mitte und prüfen Sie, ob der Satz überlebt hat.

Das Problem mit Konfigurationsdateien

Jetzt die ehrliche Einschränkung, die Ihnen fünf verwirrte Minuten erspart. XML speichert Daten an zwei Stellen: zwischen den Tags und in Attributen innerhalb der Tags. Textextraktion holt definitionsgemäß die erste Sorte. Bei einigen sehr verbreiteten XML-Dokumenten gibt es davon so gut wie nichts.

Android-Manifeste, .NET-app.config, Ant-Build-Dateien, Spring-Bean-Definitionen, viele SVGs — die packen praktisch alles in Attribute. Schicken Sie so eine Datei durch einen Textextraktor, bekommen Sie eine Handvoll versprengter Wörter oder eine leere Datei zurück, und es sieht aus, als hätte das Werkzeug versagt. Hat es nicht; es gab schlicht keinen Elementtext.

Für solche Dateien nehmen Sie stattdessen den XML-zu-Markdown-Konverter, der Attribute an den Elementen belässt, die sie beschreiben. Der Format-Umschalter oben auf dieser Seite wechselt hinüber und nimmt Ihre Datei mit — ein Klick statt eines zweiten Uploads. Faustregel: Fließtext steckt in Elementen, Einstellungen stecken in Attributen. Textextraktion ist für die erste Sorte gemacht.

Wo reiner Text eindeutig die richtige Wahl ist

XML ist das Hausformat einer enormen Menge gut gepflegter Texte, vor allem weil Institutionen sich darauf festgelegt haben, bevor es JSON überhaupt gab. Genau in diesem Erbe verdient sich dieser Konverter seinen Platz:

Korpusaufbau. Abstract-Dumps aus der Wissenschaft, TEI-kodierte literarische Texte, Parlaments- und Rechtsdokumente, Museums- und Bibliothekskataloge. Alles reicher Fließtext, alles in schwere Schemata eingewickelt. Sie wollen den Fließtext.
Embeddings und Vektorsuche. Betten Sie einen rohen XML-Chunk ein, beschreibt ein gehöriger Teil des entstehenden Vektors das Markup statt der Bedeutung — zwei Dokumente über völlig unterschiedliche Themen landen nah beieinander, nur weil sie sich ein Schema teilen. Ohne Tags bekommen Sie Embeddings, die vom Inhalt handeln.
Chunking. Chunker mit fester Größe schneiden rohes XML mitten im Element durch und produzieren Fragmente mit verwaisten Tags. Reiner Text bricht an Satz- und Absatzgrenzen, und genau dafür wurde der Chunker gebaut.
Suchindizierung und Textanalyse. Termfrequenzen, Sentiment-Auswertung, Topic Modeling, Entitätenerkennung — alles verzerrt durch Struktur-Tokens, die sich in jedem Datensatz wiederholen.
Token-Haushalt. XML ist selbst unter strukturierten Formaten ungewöhnlich geschwätzig, weil jeder Elementname zweimal dasteht. Die Tags aus einem tief verschachtelten Export zu entfernen streicht eine Menge Tokens, die nie Information getragen haben. Der Zähler unter der Ausgabe zeigt Ihnen genau, wie viel.

Wann Tag-Entfernen der falsche Zug ist

Modelle kommen mit rohem XML problemlos zurecht — es ist geschwätzig, aber eindeutig, und es steckt reichlich davon in den Trainingsdaten. Zu konvertieren ist eine Entscheidung, die Sie aus einem Grund treffen, keine Regel.

Sie schreiben Code gegen das Dokument. XPath-Abfragen, ein XSLT-Stylesheet, ein SAX- oder DOM-Parser, ein Schema. Dafür brauchen Sie exakte Elementnamen, Namespace-Präfixe und die Unterscheidung zwischen Attribut und Element. Textextraktion entfernt genau das. Fügen Sie lieber ein Stück der echten Datei ein.
Die Hierarchie ist die Antwort. Wenn die Frage lautet, unter welchem Elternelement etwas hängt — zu welcher Umgebung eine Einstellung gehört, in welchem Abschnitt eine Klausel steht — zerstört das Plattmachen genau diese Information. Das ist ein Fall für Markdown.
Attributlastige Dokumente, wie oben beschrieben.

Häufige Fragen

Wie kann ich eine XML-Datei in Text umwandeln?

Ziehen Sie die .xml in den Konverter oben, und der Inhalt zwischen den Tags kommt als reiner Fließtext zurück — keine spitzen Klammern, keine Namespace-Präfixe, keine Attribute. Als .txt herunterladen. Kostenlos, ohne Anmeldung, 50 MB pro Datei, nichts wird aufbewahrt.

Werden Entities wie & und < aufgelöst?

Ja, und das wiegt schwerer, als es klingt. XML verträgt kein nacktes kaufmännisches Und, deshalb wimmeln echte Dokumente von &, <, " und numerischen Zeichenreferenzen. Eine naive Regex zum Tag-Entfernen lässt all das wörtlich in der Ausgabe stehen. Sauberes Parsen löst sie zurück in die Zeichen auf, für die sie stehen.

Warum nicht einfach alles zwischen spitzen Klammern per Regex wegschneiden?

Weil CDATA-Abschnitte und Attributwerte beide Zeichen enthalten, die wie Markup aussehen und keines sind. Eine Regex frisst bereitwillig den Inhalt eines <![CDATA[...]]>-Blocks mit eingebettetem HTML, und sie kann ein echtes Tag nicht von einem < unterscheiden, das in einem Attributwert in Anführungszeichen steht. Ein Parser bekommt das richtig hin; Mustererkennung liegt daneben, ohne dass Sie es merken.

Kommen Attributwerte mit durch?

Sie bekommen den Elementtext; Attribute sind Metadaten über das Element, nicht dessen Inhalt. Das ist meistens richtig so — Sie wollen das Abstract, nicht die Schema-Version. Weh tut es bei Formaten, die echten Inhalt in Attributen ablegen. Wirkt Ihre Ausgabe also dünn, öffnen Sie die Quelldatei und schauen Sie nach, ob die gesuchten Wörter in <tag attr="..."> stecken.

Funktioniert das mit RSS-Feeds und Sitemaps?

Ja — beides ist XML und beides lässt sich konvertieren. Aus einem RSS-Feed bekommen Sie Titel, Beschreibungen und Datumsangaben als lesbaren Text, was ein schneller Weg ist, aus einem Blog-Archiv ein Korpus zu bauen. Eine Sitemap liefert eine Liste von URLs, mit der man weiter hinten in einer Pipeline mehr anfangen kann als beim Lesen.