ToolPal
Code on a screen showing data structure

JSON zu XML Konverter — Wann und wie man Datenformate umwandelt

📷 Photo by Pixabay / Pexels

JSON zu XML Konverter — Wann und wie man Datenformate umwandelt

Erfahren Sie, wann Sie JSON zu XML konvertieren mussen, wie die Transformation intern funktioniert und welche Sonderfalle Entwickler ins Stolpern bringen.

DVon Daniel Park20. April 20265 Min. Lesezeit

Wenn Sie lange genug in der Softwareentwicklung arbeiten, werden Sie auf ein System stoßen, das nur XML versteht. Vielleicht ist es eine SOAP-API einer Bank. Vielleicht eine Enterprise-ERP-Integration. Vielleicht ein staatlicher Datenfeed, der 2003 gebaut wurde und seitdem unverändert geblieben ist. In jedem Fall haben Sie Daten im JSON-Format — weil das alle modernen Systeme produzieren — und Sie brauchen sie in XML.

Dafür ist der JSON-zu-XML-Konverter gedacht. Fügen Sie Ihr JSON ein, erhalten Sie sauberes XML auf der anderen Seite. Aber zu verstehen, was bei der Konvertierung tatsächlich passiert und wo es schiefgehen kann, spart Ihnen Debug-Zeit, wenn die Ausgabe nicht stimmt.

Warum JSON und XML noch koexistieren

XML (eXtensible Markup Language) wurde 1998 als Standard für strukturierte Daten eingeführt. Durch die späten 1990er und 2000er Jahre wurde es zur Lingua franca der Enterprise-Software: SOAP-Webdienste, Konfigurationsdateien, Dokumentenformate (Office XML, SVG, XHTML) und Datenaustausch zwischen großen Systemen nutzten alle XML.

JSON (JavaScript Object Notation) entstand als einfachere Alternative, 2001 formal von Douglas Crockford spezifiziert. Es war nativ für JavaScript, deutlich weniger ausschweifend als XML und viel einfacher von Hand zu lesen und zu schreiben. Als REST-APIs zur Norm wurden und JavaScript das Web übernahm, wurde JSON zum Standard für API-Antworten.

Aber die auf XML aufgebauten Systeme verschwanden nicht. Mainframes laufen noch. SAP und Oracle ERP-Systeme verwenden noch XML. SOAP-Webdienste leben noch im Banken-, Versicherungs-, Gesundheits- und Behördenwesen. XSLT, SVG und RSS sind XML-basiert und bleiben.

Echte Szenarien, in denen Sie JSON zu XML brauchen

SOAP-API-Integrationen: Der klassische Fall. SOAP erfordert XML-formatierte Request-Bodies. Wenn Ihre Anwendung Daten von einer REST-API im JSON-Format empfängt, müssen Sie diese vor dem Senden an einen SOAP-Endpunkt in XML konvertieren.

Enterprise-ERP- und CRM-Systeme: SAP, Oracle und ältere Salesforce-Integrationen stellen häufig XML-basierte APIs bereit oder erwarten XML-formatierte Datendateien.

Maven- und Ant-Build-Konfigurationen: Java-Build-Tools verwenden XML (pom.xml für Maven, build.xml für Ant). Wenn Sie diese Konfigurationen programmatisch aus JSON-Daten generieren oder ändern, ist Konvertierung notwendig.

RSS und Atom Feeds: Wenn Sie einen Feed aus einer JSON-API oder Datenbank erstellen, müssen Sie XML ausgeben, das der RSS- oder Atom-Spezifikation entspricht.

Behördliche und regulatorische Datenübermittlungen: Steuerbehörden, statistische Ämter und Regulierungsbehörden in vielen Ländern fordern noch XML-formatierte Datenübermittlungen.

Wie die Konvertierung tatsächlich funktioniert

Das Grundkonzept ist einfach: JSON-Schlüssel-Wert-Paare werden auf XML-Elemente abgebildet, JSON-Objekte werden zu Eltern-Elementen mit Kind-Elementen, und Werte werden zu Textinhalt.

Einfache Objekte

Ein einfaches JSON-Objekt wie:

{
  "name": "Alice",
  "email": "alice@example.com",
  "age": 30
}

Wird zu XML wie:

<root>
  <name>Alice</name>
  <email>alice@example.com</email>
  <age>30</age>
</root>

Die JSON-Schlüssel werden zu XML-Elementnamen. Die Werte werden zum Textinhalt innerhalb dieser Elemente. Ein Wrapper-Root-Element wird hinzugefügt, weil XML genau einen Root-Knoten benötigt.

Geschachtelte Objekte

Schachtelung funktioniert natürlich. Ein in einem anderen Objekt verschachteltes JSON-Objekt wird zu einem Eltern-XML-Element mit eigenen Kindern:

{
  "user": {
    "name": "Bob",
    "address": {
      "city": "Portland",
      "country": "US"
    }
  }
}

Wird zu:

<root>
  <user>
    <name>Bob</name>
    <address>
      <city>Portland</city>
      <country>US</country>
    </address>
  </user>
</root>

Datentypen

JSON hat explizite Datentypen (String, Zahl, Boolean, null, Array, Objekt). XML ist nur Text — alles ist in XML ein String. Das bedeutet:

  • "active": true wird zu <active>true</active>
  • "count": 42 wird zu <count>42</count>
  • "score": 3.14 wird zu <score>3.14</score>

Der knifflige Teil: Arrays

Arrays sind der Punkt, an dem JSON-zu-XML-Konvertierung kompliziert wird, weil XML kein natives Array-Konzept hat. Der häufigste Ansatz verwendet einen generischen Wrapper:

{
  "colors": ["red", "green", "blue"]
}

Kann werden zu:

<root>
  <colors>
    <item>red</item>
    <item>green</item>
    <item>blue</item>
  </colors>
</root>

Ein anderer Ansatz verwendet den Eltern-Schlüsselnamen für jedes Element. Es gibt keine universell "richtige" Antwort — es hängt davon ab, was das empfangende System erwartet.

Häufige Fallstricke und Randfälle

Ungültige XML-Tag-Namen

XML-Elementnamen haben strenge Regeln: Sie müssen mit einem Buchstaben oder Unterstrich beginnen, dürfen keine Leerzeichen enthalten und dürfen nicht mit "xml" beginnen. JSON-Schlüssel können dagegen fast alles sein.

Probleme entstehen, wenn JSON-Schlüssel:

  • Zahlen sind oder mit Zahlen beginnen: "1stItem" ist ein ungültiger XML-Tag. Häufige Abhilfe: Unterstrich als Präfix
  • Leerzeichen enthalten: "first name" kann nicht zu <first name> werden
  • Sonderzeichen enthalten: müssen entfernt oder ersetzt werden

JSON null-Werte

null in JSON hat kein direktes XML-Äquivalent. Gängige Konventionen:

  • Element vollständig weglassen
  • Leeres Element einschließen: <fieldName/>
  • xsi:nil="true" Attribut verwenden (für XSD-fähige Systeme)

Das Root-Element-Problem

JSON-Objekte können mehrere Top-Level-Schlüssel haben. XML benötigt genau ein Root-Element. Deshalb braucht folgendes JSON-Objekt:

{
  "firstName": "Alice",
  "lastName": "Smith"
}

In XML einen Wrapper-Root-Element:

<root>
  <firstName>Alice</firstName>
  <lastName>Smith</lastName>
</root>

XML-Attribute vs. Kind-Elemente

XML unterstützt ein Konzept, das JSON schlicht nicht hat: Attribute auf Elementen. Ein XML-Element wie <user id="42" active="true">Alice</user> hat sowohl Attribute als auch Inhalt. JSON hat kein Äquivalent.

Für JSON zu XML wird dieser Unterschied normalerweise ignoriert und alles wird zu Kind-Elementen. Wenn Sie aber XML mit Attributen produzieren müssen, brauchen Sie zusätzliche Logik.

JSON vs. XML: Wann welches verwenden

JSON ist besser, wenn:

  • Sie REST-APIs aufbauen
  • Konfigurationsdateien gespeichert werden, die Entwickler lesen und schreiben
  • Daten zwischen Webdiensten und Browsern übertragen werden
  • In JavaScript/TypeScript gearbeitet wird
  • Dateigröße und Parse-Geschwindigkeit wichtig sind

XML ist besser, wenn:

  • Das Zielsystem es benötigt (SOAP, viele Enterprise-APIs)
  • Dokumentenstruktur benötigt wird
  • Metadaten an einzelne Felder angehängt werden müssen
  • SVG, RSS, XHTML oder andere XML-basierte Standards generiert werden
  • Langfristige Archivierung wichtig ist

In den meisten Neuentwicklungen gewinnt JSON wegen seiner Einfachheit. Aber die Legacy-XML-Welt ist riesig und geht nicht weg.

Verwendung des Konverters

Der JSON-zu-XML-Konverter behandelt die häufigen Fälle: einfache Objekte, verschachtelte Strukturen, Arrays und grundlegende Datentypen. Fügen Sie Ihr JSON ein, und er produziert formatierte XML-Ausgabe, die Sie kopieren oder herunterladen können.

Für Produktionsintegrationen validieren Sie die XML-Ausgabe immer gegen das Zielschema (XSD), falls eines vorhanden ist. Die Konvertierung behandelt die Struktur, aber Element-Namen, Attributanforderungen und Namespace-Deklarationen eines spezifischen Systems benötigen möglicherweise zusätzliche Anpassungen.

Für explorative oder einmalige Konvertierungen erledigt der Konverter es in Sekunden, ohne Code schreiben oder etwas installieren zu müssen.

Häufig gestellte Fragen

D

Über den Autor

Daniel Park

Senior frontend engineer based in Seoul. Seven years of experience building web applications at Korean SaaS companies, with a focus on developer tooling, web performance, and privacy-first architecture. Open-source contributor to the JavaScript ecosystem and founder of ToolPal.

Mehr erfahren

Artikel teilen

XLinkedIn

Verwandte Beiträge