Kostenloser XML-zu-JSON-Konverter

Was ist XML?

XML (Extensible Markup Language) ist ein Format zum Speichern und Übertragen von Daten. Es verwendet benutzerdefinierte Tags zur Beschreibung der Datenstruktur, wodurch es für Menschen lesbar und weit verbreitet unterstützt ist. Im Gegensatz zu JSON kann XML Attribute auf Elementen enthalten.

Warum XML in JSON konvertieren?

• Geringere Dateigröße · JSON ist kompakter als XML.
• Web-APIs · Die meisten modernen Webdienste verwenden JSON statt XML.
• Einfacheres Parsen · JSON wird direkt JavaScript-Objekten zugeordnet.
• Integration von Legacy-Systemen · Konvertieren Sie alte XML-Daten in das moderne JSON-Format.

Häufig gestellte Fragen

Wie werden XML-Attribute behandelt?

XML-Attribute werden in JSON-Eigenschaften mit dem Präfix „@“ umgewandelt. Zum Beispiel wird Anna zu {"user": {"@id": "1", "#text": "Anna"}}. Dies bewahrt die Unterscheidung zwischen Attributen und Textinhalten.

Was ist mit Namensräumen?

XML-Namensraumpräfixe werden in JSON-Schlüsselnamen beibehalten. Namensraumdeklarationen (xmlns) erscheinen in der Ausgabe als reguläre Attribute, die mit „@xmlns“ beginnen.

Kann ich JSON wieder in XML konvertieren?

Dieses Tool konvertiert nur XML in JSON. Für die Rückkonvertierung verwenden Sie unseren JSON-zu-XML-Konverter, der den Prozess umkehrt und dieselbe Konvention für Attribute und Textknoten verwendet.

Zwei Formate, drei Jahrzehnte auseinander

XML 1.0 wurde am 10. Februar 1998 zur W3C-Empfehlung. Die ursprünglichen Herausgeber waren Tim Bray (Textuality / Netscape), Jean Paoli (Microsoft) und C. M. Sperberg-McQueen (University of Illinois at Chicago); den Vorsitz der Arbeitsgruppe hatte Jon Bosak von Sun Microsystems. Die Abstammung von XML reicht zurück bis SGML (ISO 8879:1986), dem Dokumentauszeichnungsstandard, der selbst in den 1970er-Jahren aus IBMs GML hervorging. SGML war mächtig, aber einschüchternd; der Entwurfsauftrag von XML lautete „eine ‚schlanke’ Version von SGML entwerfen“, wobei optionale Funktionen auf ein Profil reduziert wurden, das sich in wenigen tausend Codezeilen umsetzen ließ, während Unicode, Namensräume und attributreiche Dokumente erhalten blieben.

JSON (JavaScript Object Notation) wurde entdeckt, nicht entworfen. Douglas Crockford und Chip Morningstar sendeten die erste JSON-Nachricht im April 2001 bei State Software und leiteten das Format aus der Objektliteral-Syntax von JavaScript ab. Crockford registrierte 2002 json.org und stellte eine einseitige Spezifikation online. Das Format wurde erstmals im Juli 2006 als RFC 4627 formalisiert, 2014 als RFC 7159 neu herausgegeben und im Dezember 2017 als RFC 8259 / STD 90 stabilisiert, im selben Jahr, in dem ECMA-International ECMA-404 veröffentlichte. Die Entwurfsabsicht von JSON (laut Crockfords Rückblick): minimal, sprachunabhängig, leicht zu erzeugen und zu parsen, keine Versionsnummer („es gibt keine Versionsnummer“) und bewusst keine Kommentare („Ich habe Kommentare entfernt, weil ich sah, dass die Leute sie nutzten, um Parsing-Direktiven unterzubringen“).

JSON übernahm in den späten 2000er-Jahren die Web-APIs, als REST SOAP ablöste und XMLHttpRequest dem JSON-über-fetch wich. Bis 2015 war JSON das Standard-Antwortformat nahezu jeder öffentlichen API; XML überlebte in der Long-Tail-Unternehmens-SOA, in Dokumentformaten (Office Open XML, OpenDocument) und in normgebundenen Nischen.

Worin sich XML und JSON unterscheiden

	XML	JSON
Attribute	Erstklassig (<item id="5"/>)	Keine Attribute, alles ist ein Schlüssel/Wert-Paar
Namensräume	Nativ (xmlns:prefix="uri")	Flache Namen; Präfixkollisionen sind das Problem der Anwendung
Kommentare	<!-- … -->	Keine laut Spezifikation
Gemischter Inhalt	Nativ (<p>text <b>and</b> markup</p>)	Umständlich, erfordert Arrays oder Stringifizierung
Schema	DTD, XSD 1.0 (2001) / 1.1 (2012), RELAX NG, Schematron	JSON Schema (Community-Spezifikation, Entwurf 2020-12)
Reihenfolge	Die Elementreihenfolge ist laut Spezifikation bedeutsam	Die Reihenfolge der Objektschlüssel ist nicht garantiert (die meisten Parser bewahren in der Praxis die Einfügereihenfolge); Arrays sind geordnet
Zahlen	Strings, bis sie durch ein Schema typisiert werden	IEEE-754-Double; keine Unterscheidung zwischen Integer und Float auf Spezifikationsebene
Ausführlichkeit	Hoch (jeder Wert in Tags verpackt	Niedrig) nur Interpunktion

Warum XML→JSON grundsätzlich verlustbehaftet ist

Es gibt keine vom W3C abgesegnete kanonische Abbildung von XML auf JSON. Jeder Konverter muss Antworten auf Fragen erfinden, die XML auszudrücken erlaubt, für die JSON aber kein natives Vokabular besitzt. Die wiederkehrenden Entscheidungen:

• Attribute vs. Kindelemente: XML erlaubt es, dieselben Daten auf beide Arten auszudrücken. JSON hat nur einen Begriff (Schlüssel auf einem Objekt), daher muss der Konverter einen Marker erfinden. Die gängigen Konventionen: BadgerFish verwendet @ für Attribute und $ für Text; Parker verwirft Attribute vollständig (verlustbehaftet, aber einfach); JsonML stellt Elemente als Arrays mit Typ-Tags dar (bewahrt Reihenfolge und Struktur); GData / Newtonsoft / xml2js verwenden bei Bedarf ein @attributes-Unterobjekt plus einen #text-Schlüssel. Dieser Konverter folgt der Konvention im GData-Stil: Attribute unter @attributes, Text aus gemischtem Inhalt unter #text, wiederholte Kindelemente werden zu Arrays.
• Wiederholte Kindelemente: Wenn der Konverter blind einen Schlüssel pro Kind erstellt, überschreibt das zweite Kind das erste. Standardlösung: Wiederholungen erkennen und ein Array ausgeben. Das bedeutet aber, dass die JSON-Form von den Daten abhängt, ein <book> erzeugt einen String, zwei erzeugen ein Array von Strings. Manche Konsumenten wünschen die Array-Form auch für ein einzelnes Element; manche Konverter bieten einen „Immer-Array“-Schalter für bestimmte Elementnamen.
• Gemischter Inhalt: <p>Hello <b>world</b>!</p> vermischt Text und Elemente in bedeutsamer Reihenfolge. JSON kann diese Verschachtelung nicht nativ ausdrücken, ohne ein Array aus gemischten Typen oder einen #text-Sentinel-Schlüssel. Viele Konverter verwerfen den Fließtext zwischen Elementen; die konservativeren teilen ihn in mehrere Textknoten-Einträge auf.
• Namensräume: <soap:Envelope xmlns:soap="…"> hat sowohl ein Präfix als auch eine Binding-URI. Die meisten Konverter bewahren das Präfix als Teil des JSON-Schlüssels (soap:Envelope) und verwerfen das Binding, was in Ordnung ist, solange der Konsument den Namensraum nicht auflösen muss.
• Kommentare und Verarbeitungsanweisungen: werden in der Regel stillschweigend verworfen, da JSON keine Kommentarsyntax besitzt.
• CDATA-Abschnitte: werden zu einfachen Strings verflacht; der <![CDATA[…]]>-Wrapper geht verloren.
• Leerraum: XML hat xml:space="preserve" für bedeutsamen Leerraum; JSON hat kein Äquivalent. Die meisten Konverter entfernen reine Leerraum-Textknoten zwischen Elementen.

Wann Sie dazu greifen

• Konsum von Legacy-SOAP-Diensten aus einem modernen JS-Frontend. SOAP-Antworten sind XML; eine einmalige Konvertierung an der Grenze lässt den Rest der Anwendung in JSON arbeiten.
• Verarbeitung von RSS-/Atom-Feeds: beide sind XML-Formate; moderne Nachrichtenleser und Aggregatoren wünschen meist JSON.
• XML-Sitemaps (sitemap.xml), die Konvertierung in JSON macht sie leichter prüfbar und programmatisch verarbeitbar.
• OpenStreetMap-OSM-Daten: als XML veröffentlicht, häufig als JSON für clientseitiges Mapping benötigt.
• Google-Earth-KML-/GPX-Dateien: geografische Datenformate, die in XML vorliegen.
• Interna von Office Open XML: .docx, .xlsx und .pptx sind gezippte XML-Dateien; wenn Sie eine davon entpackt haben und ihre Struktur als JSON untersuchen möchten, ist dies der Konvertierungsschritt.
• SVG-Manipulation: SVG ist XML. Die Konvertierung in JSON macht es einfacher, den Baum in JavaScript zu durchlaufen und zu verändern, bevor er neu serialisiert wird.
• Maven-POM, Ant-Build-Dateien, Spring-Konfiguration, Android-Ressourcen, Apple-Plists, XBRL-Finanzdaten, HL7-Krankenakten, MusicXML, NMX-Rechtsdokumente: Long-Tail-XML-Formate, die oft JSON für nachgelagerte Werkzeuge benötigen.

Moderne Alternativen

• Native JSON-APIs. Wenn der vorgelagerte Dienst eine JSON-Variante anbietet, nutzen Sie sie. SOAP-Dienste tun das in der Regel nicht, die meisten modernen Entsprechungen aber schon.
• GraphQL. Eine Abfragesprache, mit der der Client aus einem typisierten Schema genau die JSON-Form anfordern kann, die er benötigt.
• Protocol Buffers (Protobuf), MessagePack, CBOR, Avro. Binäre Serialisierungsformate mit Schemata und deutlich kleineren Übertragungsgrößen als XML oder JSON. Verbreitet in Microservice-Meshes; an der Browser-Grenze selten genutzt, weil sie explizite Dekodierungsbibliotheken benötigen.
• Bei XML bleiben. Wenn die Daten wirklich dokumentorientiert sind (gemischter Inhalt, tiefe typisierte Struktur, relevante Schemavalidierung), ist XML die bessere Wahl. Die Stärke von JSON sind API-förmige Daten; Dokumenttreue ist nicht ihre Spezialität.

Weitere Fragen

Warum erzeugt dasselbe XML in verschiedenen Werkzeugen eine andere JSON-Form?

Weil es keine kanonische XML→JSON-Abbildung gibt. Jeder Konverter wählt eine Konvention (BadgerFish, Parker, JsonML, GData-Stil), und die resultierenden JSON-Formen unterscheiden sich darin, wie Attribute markiert, wie gemischter Inhalt bewahrt und wie wiederholte Kindelemente in Arrays gefasst werden. Ein Hin- und Zurückkonvertieren von XML durch verschiedene Konverter erzeugt unterschiedliches JSON; ein Hin- und Zurückkonvertieren von JSON zu XML durch verschiedene Konverter kann die Attributplatzierung und sogar die Elementreihenfolge verändern. Dokumentieren Sie für die Interoperabilität die von Ihnen verwendete Konvention und bleiben Sie dabei.

Was ist mit CDATA, Kommentaren und Verarbeitungsanweisungen?

CDATA-Abschnitte (<![CDATA[…]]>) werden zu einfachem String-Inhalt verflacht, der Wrapper ist weg, aber der Text darin bleibt wortgetreu erhalten. XML-Kommentare (<!-- … -->) und Verarbeitungsanweisungen (<?xml-stylesheet …?>) werden verworfen, da JSON für beide keine Syntax hat. Wenn Sie eine Hin-und-zurück-Treue benötigen, die Kommentare bewahrt, ist ein reiner XML-Rundlauf der richtige Ansatz.

Übersteht mein XML-Schema (XSD) die Konvertierung?

Nein. XSD beschreibt die XML-Struktur und -Typen; JSON Schema ist der analoge (separate) Standard für JSON. Manche fortgeschrittenen Werkzeuge können XSD in JSON Schema übersetzen, aber das ist eine verlustbehaftete Operation, XSD hat Funktionen (gemischter Inhalt, Substitutionsgruppen, abgeleitete Typen), die kein sauberes JSON-Schema-Äquivalent haben. Für eine relevante Dokumentvalidierung führen Sie XSD gegen das ursprüngliche XML aus, nicht gegen die JSON-Konvertierung.

Warum hat sich JSON für Web-APIs durchgesetzt?

Einige Gründe. JSON bildet sich direkt auf JavaScript-Objekte ab, sodass das Parsen auf Browser-Seite nur einen JSON.parse()-Aufruf entfernt ist. Das Format ist viel kleiner, keine schließenden Tags, keine Namensraumdeklarationen, kein Schema-Ballast. REST löste in den späten 2000er-Jahren bei den meisten öffentlichen APIs SOAP ab, und JSON war die natürliche Nutzlast für REST. Die Stärken von XML (strenge Schemata, Namensräume, gemischter Inhalt) zählen für Dokumente und alte Unternehmenssysteme, aber selten für „gib mir das Nutzerobjekt“. Das Web optimierte für den einfacheren Fall.

Werden Daten an einen Server gesendet?

Nein. Das XML wird vom nativen DOMParser des Browsers geparst und dann in JavaScript rekursiv durchlaufen, um die JSON-Ausgabe zu erzeugen. Eingefügtes XML verlässt niemals die Seite. Das Werkzeug funktioniert offline, sobald es geladen ist, was wichtig ist, wenn das Quell-XML interne API-Endpunkte, Kundendaten oder proprietäre Schemata enthält, die Sie lieber nirgendwo hochladen möchten.

Verwandte Tools