XML-zu-JSON-Konverter für SOAP-, API-Payloads und Tag-Attribute
SOAP-Antworten und XML-API-Payloads im Browser als JSON lesen und JSON-Objekte wieder in Tags und Attribute schreiben. Das compact-Mapping ist berechenbar, aber ein einzelnes Kind und zwei gleichnamige Kinder ergeben unterschiedliche JSON-Strukturen, und die Reihenfolge gemischten Texts bleibt nicht erhalten.
So verhält sich dieser XML-↔-JSON-Konverter
Tags werden zu Schlüsseln, Attribute zu _attributes
Jedes Element erhält einen Schlüssel nach seinem Tag. <user id="7">Ann</user> wird zu { user: { _attributes: { id: "7" }, _text: "Ann" } }; Attribute und Text geraten nicht mit Kind-Tags durcheinander.
Ein Kind ist ein Objekt, zwei werden ein Array
Ein einzelnes <item> bleibt ein Objekt, zwei gleichnamige <item> werden ein JSON-Array. Sinkt eine Antwort von zwei Zeilen auf eine, ändert sich die Struktur; der Client sollte beide Formen abfangen.
Deklaration, Kommentar und CDATA haben eigene Schlüssel
_declaration, _doctype, _comment und _cdata stehen neben dem Wurzelelement. CDATA wird als Rohtext gelesen, und alle vier werden bei JSON → XML wieder geschrieben.
Text bleibt, seine Position nicht
Im compact-Modus werden Texte vor und nach einem Kind zu einem _text-Array zusammengefasst: <r>before<a>1</a>after</r> wird zu _text: ["before", "after"], und beim Zurückschreiben entsteht beforeafter<a>1</a>. Für einen sauberen Roundtrip nur Elementinhalt verwenden.
Namespaces und Sonderzeichen werden behandelt
xmlns / xmlns:p bleiben normale Attribute; <, & und > im Text werden beim Ausgeben maskiert und beim Einlesen zurückgewandelt. Dateien werden lokal gelesen und umgewandelt, nichts wird hochgeladen.
FAQ zur XML-↔-JSON-Konvertierung
Warum ändert sich die JSON-Struktur, wenn nur eine Zeile zurückkommt?
Wegen des compact-Modus von xml-js: wiederholte gleichnamige Kinder werden zu einem Array, ein einzelnes Kind bleibt ein Objekt. Zwei <item> ergeben item: [...], eines ergibt item: {...}. Vor dem Lesen der Felder im Client auf ein Array normalisieren.
Wie werden Attribute und Elementtext dargestellt?
Attribute landen in _attributes, Text in _text, z. B. <user id="7">Ann</user> → { user: { _attributes: { id: "7" }, _text: "Ann" } }. Text ist immer eine Zeichenkette, auch bei <n>42</n>, und ein leeres Element wird zu {}.
Kann ich ein JSON-Array auf oberster Ebene in XML umwandeln?
Nein. Die JSON-Wurzel muss ein einzelnes Objekt sein; ein Array erzeugt ungültige Elementnamen wie <0><r>a</r></0><1><r>b</r></1>. Das Array in ein Wurzelobjekt packen, z. B. { "items": { "item": [...] } }.
Bleiben Deklaration, Kommentare, CDATA und DOCTYPE erhalten?
Ja, über die Schlüssel _declaration, _comment, _cdata und _doctype. Beim Lesen enthält _comment die umgebenden Leerzeichen (z. B. " hi "); beim Zurückschreiben entstehen <?xml ...?>, <!--hi-->, <![CDATA[...]]> und <!DOCTYPE r>.
Was passiert mit Text zwischen Kindelementen?
Der compact-Modus sammelt die Textstücke in einem _text-Array und verliert ihre Positionen. <r>before<a>1</a>after</r> wird zu { r: { _text: ["before", "after"], a: { _text: "1" } } }, und beim Zurückschreiben entsteht <r>beforeafter<a>1</a></r>. Der nicht-compacte Modus erhält die Reihenfolge, diese Seite ist aber auf compact festgelegt.
Wie werden Namespaces und Sonderzeichen behandelt?
Namespace-Deklarationen bleiben normale Attribute (xmlns, xmlns:p), präfixierte Tags behalten das Präfix im Schlüssel (p:a). Text maskiert <, & und > beim Schreiben und löst Entities beim Lesen auf; Attributwerte maskieren nur Anführungszeichen, ein rohes < oder & in einem Attribut kann also ungültiges XML erzeugen.
Welche Fehler treten auf, und werden Daten hochgeladen?
Mehrere Wurzeln scheitern mit 'Text data outside of root node', ein falsch geschlossenes Tag mit 'Unmatched closing tag', eine skalare Wurzel mit 'The JSON structure is invalid'. Das Feld wird rot und es wird keine Teilausgabe geschrieben. Alles läuft im Browser, Dateien werden nie hochgeladen.
