XML-zu-JSON-Konverter

Das Datenmodell von XML ist strikt reicher als das von JSON. XML hat geordnete Kinder, Attribute, Text zwischen Elementen, Namensräume, Kommentare und CDATA. JSON hat ungeordnete Objekte, Arrays, Zeichenketten, Zahlen, Wahrheitswerte und null. Jede Abbildung vom Ersten aufs Zweite muss etwas verwerfen oder etwas erfinden.

Michael Kay hat es in seinem Balisage-Papier zur schemabewussten Umwandlung klar gesagt: Ein generischer Konverter „rät, welche Semantik das Objektmodell hinter dem lexikalischen XML hat, und er rät falsch“. An diesen sieben Stellen muss er raten:

• Attribute oder Kindelemente. <user id="7"/> und <user><id>7</id></user> sind verschiedene Dokumente, die die meisten als dasselbe JSON haben wollen. Führt man sie zusammen, liefert <user id="7"><id>8</id></user> einen doppelten Schlüssel, den RFC 8259 als unvorhersehbar bezeichnet.
• Ein Vorkommen oder viele. Nichts in <items><item>a</item></items> sagt, ob item sich wiederholen kann, also rät ein Konverter durch Zählen.
• Gemischter Inhalt. <p>Etwas Text <b>ist wichtig</b>.</p> hat drei geordnete Kinder, und ein JSON-Objekt kann diese Reihenfolge nicht ausdrücken.
• Reiner Leerraum-Text. Zeilenumbruch und Einrückung zwischen Elementen in formatiertem XML sind echte Textknoten; sie zu behalten ist treu, aber unbrauchbar.
• Namensräume. Ein Präfix ist nicht der Name, die URI ist es, und JSON kennt überhaupt keine Namensräume.
• Kommentare und Verarbeitungsanweisungen. Beides existiert in JSON nicht.
• Leere Elemente. <e/> lässt sich plausibel auf null, "", {} oder einen leeren Textschlüssel abbilden, und <e/> und <e></e> sind dasselbe Dokument.

Standard ist die Attribut-Präfix-Konvention, die Stefan Goessner 2006 beschrieben hat und von der fast-xml-parser, xml2js und das AWS SDK Varianten benutzen. Attribute bekommen das Präfix @_, damit sie nicht mit einem gleichnamigen Kindelement kollidieren. Text, der sich ein Element mit Attributen oder Kindern teilt, landet unter #text. Ein einmal auftretendes Element ist ein Wert; ein zweimal auftretendes wird ein Array. Ein reines Textelement fällt zu einer Zeichenkette zusammen, <name>Alice</name> ist also "Alice".

Das Wurzelelement bleibt der äußerste Schlüssel, Kommentare entfallen, Leerraum wird gekürzt und Entity-Referenzen werden aufgelöst, ein als "A &amp; B" geschriebenes Attribut kommt also als "A & B" an. Die Bedienelemente über dem Editor setzen Attributpräfix, Textschlüssel, eine Liste „immer ein Array“ mit Elementnamen und drei Kästchen: Namensraum-Präfixe entfernen, Attribute verwerfen, Typen umwandeln. Alle drei sind aus.

<order id="00042">
  <total currency="GBP">19.90</total>
  <line sku="0071">Widget</line>
  <line sku="0072">Gasket</line>
  <note/>
</order>

{
  "order": {
    "@_id": "00042",
    "total": { "@_currency": "GBP", "#text": "19.90" },
    "line": [
      { "@_sku": "0071", "#text": "Widget" },
      { "@_sku": "0072", "#text": "Gasket" }
    ],
    "note": ""
  }
}

XML ohne Schema ist durch und durch Text. "123" in eine Zahl zu verwandeln ist bequem – genau bis zu dem Moment, in dem es einen Bezeichner zerstört, und Bezeichner sind das meiste, was durch XML-Integrationen fließt.

Wenn Sie die Umwandlung einschalten, ist sie bewusst eng gefasst. Ein Wert wird nur dann zur Zahl, wenn er einer strengen JSON-Zahlengrammatik entspricht und danach einen Hin- und Rückweg übersteht: Das geparste Ergebnis wird zurückserialisiert und Zeichen für Zeichen mit dem Original verglichen. Diese Prüfung verhindert die Fehler, mit denen andere Konverter ausgeliefert werden. Auch mit eingeschalteter Umwandlung bleiben diese Zeichenketten:

• Führende Nullen. "00042" und "01730" scheitern schon an der Grammatik, denn eine JSON-Zahl darf nicht mit einer Null vor weiteren Ziffern beginnen. Postleitzahlen, Bankleitzahlen und Artikelnummern überleben.
• Nachgestellte Nullen hinter dem Komma. "19.90" ergibt geparst 19.9, was als "19.9" zurückserialisiert wird, also bleibt die Zeichenkette. "1.10" wird nicht zu 1.1.
• Ganze Zahlen, die ein double nicht hält. "9007199254740993" ergibt einen Wert, der auf 992 endet, der Rückweg scheitert, die Zeichenkette bleibt. Genau das zerstört anderswo neunzehnstellige Auftragsnummern.
• Nicht kanonische Exponenten. "1e5" ergibt 100000, was nicht "1e5" ist, also bleibt es Text.
• Alles, was nicht exakt true, false oder null ist. "TRUE", "yes" und "Y" bleiben Zeichenketten.

Drei Dinge überleben nicht. Die Dokumentreihenfolge zwischen unterschiedlich benannten Geschwistern verschwindet: Wechseln sich <line> und <discount> ab, sagt das JSON nichts darüber. Gemischter Inhalt wird flachgeklopft: Textfragmente werden aneinandergehängt und die Elemente dazwischen wandern in eigene Schlüssel, <root>35<nested>34</nested>46</root> ergibt also den Textwert "3546". Kommentare werden verworfen.

Namensräume bleiben wörtlich erhalten statt aufgelöst zu werden, soap:Body wird also zum Schlüssel "soap:Body". Das Entfernen der Präfixe ergibt "Body", aber dann kollidieren zwei Elemente aus verschiedenen Namensräumen mit gleichem lokalen Namen auf einem Schlüssel, und JSON bietet keine dritte Möglichkeit.

Wenn diese Konvention nicht das ist, was Ihr Konsument erwartet, haben die Alternativen Namen. BadgerFish legt Text unter $, Attribute unter @name und trägt jeden Namensraum im Gültigkeitsbereich mit: besser umkehrbar, kaum lesbar. Parker verwirft Attribute und schluckt die Wurzel – die schlankeste und einseitigste Ausgabe von allen. JsonML schreibt jedes Element als [Name, Attribute, Kinder] und ist die einzige verbreitete Konvention, die gemischten Inhalt und Kindreihenfolge unversehrt lässt.

Dieselbe Umwandlung in den Sprachen, die XML tatsächlich verarbeiten. Jedes Beispiel schaltet die Entity-Auflösung ab, denn in mehreren dieser Stacks lädt die Standardeinstellung eine im DOCTYPE genannte URL – das ist die XXE-Schwachstelle. Jedes benennt außerdem die Abbildungsentscheidung, die die Bibliothek für Sie trifft.