XML bis JSON: die Entscheidungen, die jeder Konverter treffen

Die Mehrdeutigkeit, die kein Konverter vermeiden kann

Betrachten Sie `<items><item>x</item></items>`. Sollte `item` ein String oder eine Liste von einem sein? XML sagt es nicht, und der Unterschied spielt in dem Moment eine Rolle, in dem Sie Code dagegen schreiben: Ein Verbraucher, der immer ein Array erwartet, bricht bei einer Antwort mit einem einzigen Element, und ein Verbraucher, der erwartet, dass ein Objekt bricht, wenn ein zweites Element ankommt. Mit ausgereiften Konvertern können Sie Arrays für bekannte Listenelemente erzwingen, anstatt stillschweigend zu raten, da die Vermutung gerade oft genug richtig ist, um die Produktion zu erreichen.

Attribute benötigen eine Namenskonvention

Json hat keine Attribute, daher muss ein Attribut entweder ein Geschwisterschlüssel oder ein verschachteltes Objekt werden. Die weit verbreitete Konvention präfixiert Attributnamen mit `@` — `<image src="a.png"/>` wird zu `{"@src": "a.png"}` — während Elementtext in einen reservierten Schlüssel wie `#text` eingeht, wenn ein Element sowohl Attribute als auch Inhalt hat. Unabhängig von der Konvention, die der Konverter verwendet, sollte er konsistent angewendet werden, da halb konvertiertes XML schlechter ist als nicht konvertiertes XML.

                <rss version="2.0"><channel><title>Feed</title></channel></rss>
→ {
  "rss": {
    "@version": "2.0",
    "channel": { "title": "Feed" }
  }
}
              

Namensräume

Namespace-Dokumente – SOAP-Dienste, Sitemaps, Office-Formate – qualifizieren Elementnamen als `ns:element`. JSON hat kein Äquivalent, daher löscht ein Konverter entweder das Präfix, behält es als Teil des Schlüssels oder ordnet das Dokument um den Namespace-URI herum neu an. Das Löschen kommt häufig vor und kann manchmal katastrophal sein, wenn zwei Namespaces denselben lokalen Namen verwenden. Wenn Ihr Dokument Namespaces verwendet, überprüfen Sie die Ausgabe auf Kollisionen, bevor Sie ihr vertrauen, und behalten Sie lieber das Präfix im Schlüssel bei.

Wo diese Konvertierung tatsächlich verwendet wird

• RSS- und Atom-Feeds – das Lesen eines Feeds in JavaScript ist nach der Konvertierung viel einfacher.
• SOAP und Legacy-APIs – eine Antwort in etwas verwandeln, das ein moderner Client nutzen kann.
• Sitemaps und Konfigurationsdateien – Überprüfung der Struktur ohne einen Editor, der Schemata versteht.
• Datenmigrationen – Verschieben von Datensätzen aus einem XML-Ära-System in ein JSON-basiertes System.

Round-Trip-Fidelity ist ein Mythos. Das Konvertieren von XML in JSON und zurück gibt selten Byte für Byte das ursprüngliche Dokument zurück, da Deklarationsreihenfolge, Leerzeichen, Kommentare und CDATA nicht erhalten bleiben. Konvertieren Sie, wenn Sie die Daten an anderer Stelle nutzen müssen, nicht als Backup-Strategie.

Erst validieren, dann konvertieren

XML-Parser gehen bei nicht geschlossenen Tags und ungültigen Entitäten streng vor und die Fehlermeldungen sind normalerweise präzise. Korrigieren Sie das Dokument vor der Konvertierung – eine wohlgeformte Eingabe ist die einzige Möglichkeit, eine JSON-Struktur zu erhalten, die es wert ist, beibehalten zu werden. Die Konvertierung wird dann lokal im Browser ausgeführt, was wichtig ist, wenn es sich bei dem XML um einen Kundenexport oder eine interne Serviceantwort handelt, und sie funktioniert weiterhin offline.