JSON zu XML

Lokale Verarbeitung
app.xml.view

Daten auch über #data={"name":"Ada"} oder #url=... einfügen; nach dem Lesen wird die Adressleiste geleert.

JSON und XML in beide Richtungen. Alte APIs mit XML oder Systeme, die nur XML kennen: lokal eine Fassung zur Strukturprüfung. Wurzelname änderbar, Standard rootJSON und XML in beide Richtungen. Alte APIs mit XML oder Systeme, die nur XML kennen: lokal eine Fassung zur Strukturprüfung. Wurzelname änderbar, Standard

Bidirektional

JSON → XML oder XML → JSON. Mapping Felder zu Tags sehen, nicht einmal Produktion.

Danach Validator des Zielsystems.

Ähnliche Struktur

Objekte als Element-Nesting, Arrays oft wiederholte Tags. Übliche Konvention, nicht zwingend fremdes Schema.

Attribute vs. Kindelemente je System – stichprobenartig.

Attribute und Text

XML-Attribute und Textknoten können im JSON anders aussehen als im Ursprungssystem – nach der Konvertierung prüfen.

SOAP mit Namespaces lässt sich kaum perfekt automatisch wandeln.

Beispiel

JSON
{
  "note": {
    "to": "Ada",
    "body": "hello"
  }
}
XML (Beispiel) 
<note>
  <to>Ada</to>
  <body>hello</body>
</note>
Bleiben Namespaces?

Komplexes SOAP / xmlns von Hand prüfen; Automatik erhält Namespace-Details selten perfekt.

YAML oder XML?

Moderne Configs oft YAML; Enterprise-Bus, Payment/Gov oft noch XML.

Wozu der Wurzelname?

JSON hat kein einzelnes «Wurzeltag». Beim XML-Export umhüllt dieser Name das Dokument.

Muss ich «Konvertierung ausführen» klicken?

Ja. Nach geändertem Wurzelname erneut konvertieren.

Empfohlener Ablauf

  1. JSON einfügen (oder XML, je nach Seite), Wurzelname setzen.
  2. «Konvertierung ausführen», Tag-Struktur in der Vorschau.
  3. Kopieren oder Download, einmal im Zielsystem parsen.
  4. Bei Namespace- oder Attributreihenfolge professionelle XML-Tools zum Abschluss.

Diese Seite zeigt zuerst die Struktur. Strenges XSD / SOAP nicht nur der Automatik überlassen.

Verwandte Tools

YAMLCSV Formatieren