XML in JSON umwandeln
XML zu JSON wandelt ein Dokument in Ihrem Browser um. Zwischen den beiden Formaten gibt es keine kanonische Abbildung, also ist jede Entscheidung eine Option statt eines stillen Standardwerts – die wichtigste ist die Force-Array-Liste, denn XML kann eine Liste mit einem Eintrag nicht von einem Einzelwert unterscheiden, und kein Konverter kann das ableiten.
Wie funktioniert XML in JSON umwandeln?
XML und JSON beschreiben nicht dieselben Formen, also gibt es keine einzelne korrekte Übersetzung zwischen ihnen. Ein Konverter, der trotzdem eine vorgibt, verschweigt vier Entscheidungen – und jede davon kann still und leise Ihre Daten korrumpieren.
Das Ein-Element-Problem, das sich nicht ableiten lässt
XML hat keine Arrays. <line/><line/> sind zwei Elemente; <line/> ist eines. Ein Konverter macht daher aus wiederholten Elementen ein Array und lässt ein einzelnes Element als Skalar stehen – derselbe Endpoint liefert also {"line": {…}} für eine Bestellung mit einer Position und {"line": [{…}, {…}]} für eine Bestellung mit zwei. Code, der gegen die zweite Variante geschrieben ist, stürzt bei der ersten ab – in Produktion, an dem Tag, an dem ein Kunde genau eine Sache bestellt.
Das ist nicht durch Raten lösbar. Die benötigte Information – ist dieses Element eine Sammlung? – steckt im Schema, nicht in der Instanz. Die ehrliche Lösung ist die Force-Array-Liste: Nennen Sie die Elemente, die Sammlungen sind, und sie sind immer Arrays, egal wie viele das Dokument heute zufällig enthält.
Attribute müssen irgendwohin
<line sku="X"><sku>Y</sku></line> hat ein Attribut und ein Kind-Element mit demselben Namen. Beide zusammenzuführen verliert eines. Das Präfix – standardmäßig @ – erhält beide, auf Kosten von Keys, die sich in JavaScript etwas umständlich tippen lassen. Setzen Sie es auf leer, um sie zusammenzuführen, und akzeptieren Sie die Kollision.
XML hat keine Typen
<qty>3</qty> ist der String "3". Ihn in eine Zahl zu zwingen ist ein Raten – und zwar das Raten, das aus der Teilenummer 007 eine 7 und aus der Postleitzahl 01970 eine 1970 macht. Die Wertparsung ist daher standardmäßig aus, und wenn sie an ist, hält eine führende Null den Wert weiterhin als String – die JSON-Grammatik verbietet führende Nullen ohnehin, also gibt es nichts zu verlieren.
Gemischter Inhalt überlebt nicht
<p>before<b>bold</b>after</p> hat Text vor und nach einem Kind. JSON-Objekte haben keine Ordnung, also werden die beiden Textstücke unter einem Key zusammengefügt, und ihre Position relativ zu <b> geht verloren. Nichts kann das reparieren; dokumentenförmiges XML ist nicht datenförmig, und es in JSON umzuwandeln ist der falsche Schritt, kein verlustreicher.
Fehlerhafte Eingabe wird abgelehnt, nicht erraten
Falsch gepaarte Tags und ungeschlossene Elemente erzeugen einen Fehler, der Tag und Zeile nennt. Ein Konverter, der <a><b></a> akzeptiert und plausibel aussehendes JSON ausgibt, ist schlechter als einer, der fehlschlägt – denn wer abgeschnittenes XML einfügt, erfährt nie, dass es abgeschnitten war.
XML
<order id="1"> <line sku="A">Widget</line> </order>
JSON
{
"order": {
"@id": "1",
"line": {
"@sku": "A",
"#text": "Widget"
}
}
}
// with "line" forced: "line": [ … ]Welche Optionen und Sonderfälle unterstützt XML in JSON umwandeln?
| Parameter | Typ | Standard | Verhalten & Sonderfälle |
|---|---|---|---|
| Array erzwingen | Elementnamen | (keine) | Namen in dieser Liste sind immer Arrays, selbst bei einem einzigen Vorkommen. Die mit Abstand wichtigste Option: Sie ist die einzige Lösung für das Ein-Element-Listen-Problem und lässt sich aus dem Dokument nicht ableiten. |
| Attribut-Präfix | string | @ | Hält Attribute von gleichnamigen Kind-Elementen getrennt. Setzen Sie es auf leer, um beide zu verschmelzen – mit dem Risiko, dass bei einer Kollision eines gewinnt. |
| Text-Schlüssel | string | #text | Wohin der Text eines Elements kommt, wenn es auch Attribute oder Kinder hat. Ein Element mit nur Text wird stattdessen zu einem bloßen String. |
| Werte parsen | Boolesch | aus | Macht aus „3“ die Zahl 3, aus „true“ true und aus „null“ null. Standardmäßig aus, weil XML keine Typen hat und Raten Teilenummern zu Ganzzahlen macht. |
| Führende Nullen | als string behalten | immer | 007 bleibt „007“, selbst bei aktiviertem Wert-Parsing. Die JSON-Grammatik verbietet eine führende Null, es gibt also keine Darstellung, in die man ihn konvertieren könnte, ohne sie zu verlieren. |
| Namespaces entfernen | Boolesch | aus | Entfernt Präfixe, sodass aus soap:Envelope Envelope wird, und löscht xmlns-Deklarationen. Praktisch bei SOAP; verlustreich, wenn zwei Namespaces denselben lokalen Namen verwenden. |
| Kommentare behalten | Boolesch | aus | Bewahrt Kommentare unter einem #comment-Member auf. Ihre Position zwischen Elementen bleibt nicht erhalten, weil JSON-Objekte keine Reihenfolge haben. |
| Leere Elemente | null | immer | <a/> und <a></a> sind in XML dasselbe, und beide werden null statt einem leeren String – eine leere Zeichenfolge würde einen Wert suggerieren. |
| CDATA | literaler Text | — | Inhalt in CDATA wird wörtlich übernommen: Ein < darin ist ein kaufmännisches Und gefolgt von lt, kein Kleiner-als-Zeichen. Dafür ist CDATA da. |
| Entities | dekodiert | die fünf vordefinierten | & < > " ' plus numerische Referenzen. Eine nicht deklarierte Entity bleibt wörtlich stehen, statt gelöscht zu werden – stillschweigend Inhalt zu löschen ist der schlimmere Fehler. |
Häufig gestellte Fragen
Warum ist ein Element ein Objekt, aber zwei Elemente ein Array?
Weil XML keine Arrays hat – und das ist die größte einzelne Gefahr bei der Umwandlung. Ein Konverter sieht ein <line> und kann nicht wissen, ob das Schema mehr erlaubt. Tragen Sie den Elementnamen in das Force-Array-Feld ein, und es ist jedes Mal ein Array – genau danach muss Ihr Code geschrieben sein. Das lohnt sich vor dem Ausliefern, nicht erst, wenn eine Ein-Position-Bestellung die Produktion lahmlegt.
Warum beginnen meine Keys mit @?
Das sind Attribute. XML hat zwei Arten von Mitgliedern, JSON nur eine, daher brauchen Attribute ein Präfix, sonst kollidieren sie mit Kind-Elementen – und ein Element mit sowohl einem sku-Attribut als auch einem sku-Kind ist nicht ungewöhnlich. Sie können das Präfix auf leer setzen, um sie zusammenzuführen, oder es durch etwas Freundlicheres wie einen Unterstrich ersetzen.
Warum sind meine Zahlen Strings?
Weil sie in XML Strings sind. Das Dokument enthält keine Typinformation, also ist die Umwandlung von <qty>3</qty> in die Zahl 3 ein Raten, das bei Mengen zufällig richtig und bei Teilenummern, Postleitzahlen und Telefonnummern falsch ist. Schalten Sie die Wertparsung ein, wenn Ihre Daten keine mit Nullen aufgefüllten Kennungen enthält; auch dann hält eine führende Null den Wert als String.
Was ist mit dem Text um meine Kind-Elemente herum passiert?
Er wurde zusammengefügt und unter den text-Key gelegt, und seine Position ging verloren. Das ist gemischter Inhalt, und JSON kann ihn wirklich nicht darstellen: Ein Objekt hat keine Ordnung, also gibt es keinen Ort, an dem sich festhalten ließe, dass ein Teil des Textes vor einem Kind kam und ein Teil danach. Ist Ihr XML dokumentenförmig – XHTML, DocBook, alles mit Markup im Fließtext –, ist die Umwandlung zu JSON der falsche Vorgang, kein verlustreicher.
Klappt das auch mit SOAP-Antworten?
Ja – und schalten Sie „strip namespaces“ ein; das macht aus soap:Envelope ein Envelope und entfernt die xmlns-Deklarationen, die sonst als Attribute an jedem Element auftauchen würden. Bedenken Sie, dass das Entfernen verlustbehaftet ist, wenn das Dokument wirklich zwei Namensräume mit demselben lokalen Namen verwendet – in SOAP selten, in XML mit gemischtem Vokabular üblich.
Wird mein XML hochgeladen?
Nein. Tokenizer und Konverter laufen beide in dem Tab, den Sie bereits geöffnet haben – prüfen Sie den Netzwerk-Tab. Das ist relevant, weil XML im Datenverkehr heute meist SOAP, SAML-Assertions und Finanznachrichten sind – also etwas von dem Sensibelsten, was ein Entwickler in der Hand hat.