JSON XML Konverter

JSON und XML als austauschbare Bäume

JSON und XML stellen beide hierarchische Daten dar, stammen aber aus unterschiedlichen Traditionen. JSON ist ein leichtgewichtiges Objekt-/Array-Modell, das die meisten Web-APIs nutzen. XML ist ein markiertes Dokumentmodell mit Elementen, Attributen, Namensräumen und gemischtem Inhalt — nach wie vor zentral für Unternehmensnachrichten, Publishing und viele Konfigurationsformate.

Die Umwandlung zwischen beiden ist eine strukturelle Abbildung, kein bloßes Umstylen der Syntax. Namen, Verschachtelung und Typ-Hinweise müssen bewusst gewählt werden, weil die Modelle nicht isomorph sind. Dieser Hub erklärt diese Abbildungsfamilie. Für einen direkten Konvertierungspfad öffnen Sie Von JSON zu XML.

Subtools in dieser Familie

• Von JSON zu XML — nimmt einen JSON-Wert und erzeugt ein XML-Dokument, das Objekte als Elemente und Arrays als wiederholte Kinder abbildet (gemäß den Regeln des Konverters).
• Von XML zu JSON — parst XML und erzeugt eine JSON-Darstellung von Elementen, Text und Attributen.
• JSON formatieren — pretty-print oder Minifizieren von JSON, wenn Sie Layout-Kontrolle im gleichen Workflow wie die Konvertierung brauchen.

Nutzen Sie die Konverter, wenn Systeme auf beiden Seiten einer Integration unterschiedliche Kodierungen erwarten. Nutzen Sie format-json, wenn die Nutzlast bereits JSON ist und Sie nur lesbare oder kompakte Form vor oder nach einer Transformation brauchen.

Wo die Modelle auseinanderlaufen

Objekte vs. Elemente. JSON-Objekte sind ungeordnete Abbildungen von String-Schlüsseln auf Werte. XML-Elemente stehen in Dokumentreihenfolge und dürfen denselben Namen wiederholen. Ein JSON-Array von Objekten wird oft zu wiederholten Geschwisterelementen; ein JSON-Objekt wird zu einer Menge eindeutig benannter Kindelemente — bis ein Schlüssel als XML-Name unzulässig ist.

Attribute vs. Eigenschaften. XML-Attribute sind nur Strings, ungeordnet am Element und nicht verschachtelbar. JSON hat keinen separaten Attributkanal; Konverter mappen Attribute typischerweise auf Schlüssel mit konventionellem Präfix (z. B. @id) oder betten sie unter einem reservierten Objekt ein. Round-Trips müssen sich auf diese Konvention einigen, sonst vertauschen Attribute und Kindelemente ihre Bedeutung.

Typen. JSON unterscheidet Zahlen, Booleans, null, Strings, Arrays und Objekte. XML-Text bleibt Text, bis ein Schema (XSD) oder eine Konvention ihn neu interpretiert. Ohne Typ-Metadaten können true, 1 und "true" als Strings überleben — oder ein Konverter wendet Heuristiken an, die überraschen.

Namensräume. XML-Namensräume (xmlns) trennen Vokabulare. JSON hat keinen nativen Namensraum-Knoten; Präfixe werden oft in Schlüsselstrings abgeflacht oder verworfen. Verlorene Namensraum-Information ist ein häufiges stilles Versagen, wenn XML→JSON→XML als „Aufräum“Pipeline genutzt wird.

Gemischter Inhalt. XML erlaubt Text und Elemente im Wechsel (<p>Hallo <em>Welt</em></p>). JSON-Bäume speichern üblicherweise entweder einen String oder Kinder, nicht beides — außer der Konverter nutzt ein explizites Inhalts-Array. Dokumentzentriertes XML braucht oft eine reichere Abbildung als datenzentriertes XML.

JSON → XML (konzeptuelle Pipeline)

1. JSON parsen; ungültige Syntax ablehnen, bevor XML gebaut wird.
2. Wurzelelement-Namen wählen (JSON verlangt bei einem Top-Level-Array keine einzelne Wurzel; Konverter erfinden einen Wrapper).
3. Jeden Objektschlüssel gemäß Namensregeln auf Kind-Element oder Attribut abbilden.
4. Arrays auf wiederholte Elemente mit demselben Tag abbilden.
5. Sonderzeichen (&, <, >, Anführungszeichen) in Text und Attributen escapen.
6. Mit oder ohne XML-Deklaration und Einrückung serialisieren.

Unzulässige XML-Namen (Schlüssel mit Ziffern am Anfang, Leerzeichen oder Kollision mit reservierten xml-Präfixen) müssen bereinigt oder abgelehnt werden. In Datenpipelines lieber laut scheitern als nicht wohlgeformtes Markup ausgeben.

XML → JSON (konzeptuelle Pipeline)

1. Als wohlgeformtes XML parsen (optional gegen ein Schema anderswo validieren).
2. Jedes Element als JSON-Objekt darstellen — oder als Wert, wenn es nur Text hat.
3. Entscheiden, wie Attribute, wiederholte Kinder und leere Elemente kodiert werden ("" vs. null vs. {}).
4. Textknoten gemäß Richtlinie für gemischten Inhalt zusammenfassen oder erhalten.
5. JSON-Text ausgeben; optional pretty-print zur Prüfung über JSON formatieren.

Geschwisterelemente mit demselben Namen werden meist zu einem JSON-Array. Ein einzelnes Kind mit diesem Namen kann ein nacktes Objekt werden — ein weiteres Round-Trip-Risiko, wenn Code immer Arrays annimmt.

JSON formatieren im Konvertierungs-Workflow

Konvertierungsfehler lassen sich an eingerücktem JSON leichter diagnostizieren. Minifiziertes JSON eignet sich besser zum Einbetten in Logs oder Transport, nachdem Sie fertig editiert haben. Format-json in dieser Familie ist das Layout-Geschwister: es verschiebt keine Daten nach XML; es bereitet JSON für Menschen oder Maschinen rund um die Konverter vor.

Verlustfreiheit und wann Round-Trips stoppen

Round-Trips sind standardmäßig verlustbehaftet, sofern beide Richtungen kein dokumentiertes Konventionsset teilen (Attributpräfixe, Array-Wrapping, Typ-Koersion, Namensraum-Behandlung). Sichere Muster:

• Einmal an einer Systemgrenze konvertieren und ein einziges System of Record behalten.
• Original-XML speichern, wenn rechtliche/archivische Treue zählt; JSON als Arbeitsprojektion behandeln.
• Für Unternehmensnachrichten schema-bewusste Werkzeuge (XSD + Data Binding) gegenüber ad-hoc Baumwanderungen bevorzugen.

Unsichere Muster: JSON als XML-Editor nutzen (XML→JSON, manuell editieren, JSON→XML) für signierte Dokumente, Namensräume oder gemischten Inhalt ohne Golden Tests.

Zeichen, Kodierung und Größe

XML-Dokumente deklarieren die Kodierung oft im Prolog; JSON-Text in APIs ist fast immer UTF-8. Beim Konvertieren muss der Unicode-String im Speicher vor der Serialisierung korrekt sein. Steuerzeichen, die in XML 1.0 unzulässig sind, müssen laut Richtlinie entfernt oder escaped werden — sie können in JSON-Strings vorkommen und naive XML-Schreiber brechen.

Sehr große Dokumente belasten den Browser-Speicher. Für Multi-Megabyte-Exporte Streaming-Konverter im Standard-Ökosystem Ihrer Sprache bevorzugen; Browser-Tools eignen sich für Samples, Fixtures und Debug-Ausschnitte.

Praktische Integrationsbeispiele

• Legacy-SOAP/XML-Dienst, moderner JSON-Client: Antwort-XML für die UI nach JSON mappen; Request-Templates in XML belassen, wenn der Remote-Vertrag es verlangt.
• Konfigurationsbrücke: interne Config als JSON pflegen; XML für Tools ausgeben, die nur XML lesen.
• Fixture-Bau: Daten als JSON authoren, nach XML für einen Parser-Harness konvertieren — Golden Input/Output-Paare unter denselben Mapping-Regeln wie Produktion halten.

Einschränkungen

Diese Tools validieren nicht gegen XSD oder JSON Schema, führen kein XSLT aus und implementieren keine XML Canonicalization (C14N) für Signaturen. Sie fokussieren auf praktische Baumprojektion. Für digital signiertes XML dedizierte Signaturbibliotheken verwenden.

Verwandte Werkzeuge

Syntaxprüfungen: Gültiges JSON, Gültiges XML. Reines JSON-Layout: Pretty-print JSON. Konvertieren, wenn sich das Modell ändern muss; formatieren oder validieren, wenn es gleich bleibt.