XML zu JSON: Attribute, Textknoten und das Eins-gegen-viele-Problem

Warum ein <item> zu einem Objekt und zwei zu einem Array wurden – der XML-Feed, dessen JSON-Form sich abhängig von der Anzahl der Einträge ändert

Ein Feed mit `<item>one</item>` erzeugt `"item": "one"`; Durch das Hinzufügen eines zweiten Geschwisters wird diese Eigenschaft in `"item": ["one", "two"]` geändert. Der Parser kann nicht schließen, dass es sich bei einem Element konzeptionell um eine Liste mit einem Element handelte, da beide Bedeutungen die identische XML-Syntax haben. Code, der nur für das erste Beispiel erstellt wurde, kann daher fehlschlagen, wenn die Produktion das zweite Beispiel sendet.

ToolAcre verbirgt diese Instabilität nicht hinter einer Always-Array-Option. Es zeichnet einen Namen einmal als einen Wert und wiederholte Geschwister als Array auf. Diese direkte Zuordnung ist leicht zu überprüfen, aber Verbraucher, die eine stabile Sammlungsform benötigen, müssen Schemakenntnisse nutzen oder das Ergebnis nach der Konvertierung selbst normalisieren.

Was XML hat, was JSON nicht hat – Attribute, Text gemischt mit Elementen, geordnete Geschwister, Namespaces, Kommentare und Verarbeitungsanweisungen

XML trennt Attribute von untergeordneten Elementen, behält die Geschwisterreihenfolge bei, lässt Text zwischen Elementen zu, trägt Namespace-Präfixe und kann Kommentare und Verarbeitungsanweisungen enthalten. JSON bietet Objekte und Arrays, verfügt jedoch über keine integrierten Entsprechungen für diese Knotenkategorien. Jedes XML-zu-JSON-Ergebnis ist folglich eine ausgewählte Projektion und keine universelle Übersetzung.

Dieser Leser löscht die Erklärung, Kommentare und Verarbeitungsanweisungen. Namespace-Präfixe bleiben wörtlich und werden nicht aufgelöst: `<ns:item>` wird zum Schlüssel `ns:item`, während `xmlns:ns` zu `@xmlns:ns` wird. Gemischter Text wird unter einem Schlüssel zusammengefügt, sodass seine ursprüngliche Position um untergeordnete Elemente verloren geht und eine Warnung mit dem Hinweis angezeigt wird, dass bei der Konvertierung kein Roundtrip möglich ist.

Attributkonventionen – Präfixe wie @ oder $, warum sie existieren und wie ein Attribut und ein untergeordnetes Element mit demselben Namen kollidieren

Attribute verwenden ein `@`-Präfix. `<user id="7"><id>other</id></user>` wird zu einem Objekt mit `@id` gleich `"7"` und untergeordnetem `id` gleich `"other"`. Das Präfix verhindert, dass zwei verschiedene XML-Konstrukte in einer einzelnen Objekteigenschaft kollidieren. Es wird auch Teil des Vertrags des Konverters, wenn JSON in XML zurückgeschrieben wird.

Andere Bibliotheken verwenden möglicherweise `$`, ein Attributobjekt oder eine andere Konvention. ToolAcre unterstützt nur die sichtbare Zuordnung `@`. Wenn Sie dieses Präfix im Anwendungscode ändern, ohne den Writer zu ändern, würden Attribute in Elemente umgewandelt. Behalten Sie es daher bei, wenn Sie den konvertierten Wert als Zwischeninspektionsformular verwenden.

Textknotenkonventionen – #text oder _ für Elementinhalt und was passiert, wenn ein Element sowohl Text als auch untergeordnete Elemente hat

Ein Element, das nur Text enthält, wird auf diese Zeichenfolge reduziert. Wenn auch Attribute oder untergeordnete Elemente vorhanden sind, befindet sich der Text unter `#text`; CDATA wird separat unter `#cdata` aufbewahrt. Ein selbstschließendes Tag wird zu einer leeren Zeichenfolge. Mit diesen reservierten Schlüsseln kann der Autor gewöhnliche Kindernamen von Inhaltskategorien unterscheiden, die JSON selbst nicht definiert.

Gemischte Inhalte bleiben verlustbehaftet. In `<p>before<b>bold</b>after</p>` kann die Position von „vorher“ und „nachher“ relativ zum untergeordneten Element nicht aus einer verbundenen `#text`-Eigenschaft rekonstruiert werden. Das Tool erkennt dieses Strukturmuster und warnt. Verwenden Sie eine knotenerhaltende XML-API, wenn die Dokumentreihenfolge Teil der Bedeutung ist.

Das Eins-gegen-Viele-Problem – wiederholte Elemente werden nur dann zu Arrays, wenn sie wiederholt werden, und warum Verbraucher defensiv programmieren müssen

Wiederholte Geschwister werden erst dann zu Arrays, wenn Wiederholungen beobachtet werden. Ein einzelnes `<book>` ist ein Objekt; Zwei Bücher sind eine Reihe von Objekten. Dies wird manchmal als Eins-gegen-Viele-Problem bezeichnet, es handelt sich jedoch nicht um einen Parser-Defekt. Das Quelldokument enthält einfach keine Listendeklaration unabhängig von ihren Vorkommen.

Defensive Verbraucher können bekannte Pfade mit Schemakenntnissen normalisieren: Wrap `catalogue.book`, wenn es sich nicht bereits um ein Array handelt. Wenden Sie diese Regel nicht auf jede Eigenschaft an, da ein gewöhnlicher Skalar nicht nur aus Symmetriegründen zu einer Liste werden sollte. Der Konverter vermeidet es bewusst, solche Domäneninformationen zu erfinden.

Arbeitsbeispiel: Konvertieren eines kleinen Dokuments im RSS-Stil – Attribute, ein wiederholtes Element und ein Namespace, mit dem resultierenden JSON mit Anmerkungen

Konvertieren Sie `<feed xmlns:m="https://example.invalid/meta"><item id="1"><m:title>One</m:title></item><item id="2"><m:title><![CDATA[Two & More]]></m:title></item></feed>`. Der Stamm ist `feed`; `@xmlns:m` behält die Namespace-Deklaration bei; `item` ist ein Array; jedes `@id` ist Text; und der zweite Titel enthält `#cdata`.

Die Typinferenz ist standardmäßig deaktiviert, daher bleibt auch `id="2"` die Zeichenfolge `"2"`. Durch die Aktivierung der Inferenz kann der Parser numerischen und booleschen Text als diese JavaScript-Typen lesen, aber XML hat diese Absicht nicht erklärt. Bei dieser Option handelt es sich um eine vom Benutzer kontrollierte Vermutung und nicht um einen durch das Dokument gelieferten Beweis.

Was dies nicht abdeckt – schemagesteuerte Konvertierung, die weiß, dass es sich bei einem Element immer um eine Liste handelt, die eine XSD oder eine manuelle Zuordnung erfordert

Es ist keine XSD geladen und es sind keine schemagesteuerten Listeninformationen verfügbar. Der Konverter kann nicht wissen, dass ein Element wiederholbar ist, wenn nur eines vorkommt, erforderliche untergeordnete Elemente validieren, Namespace-URIs in Anwendungstypen auflösen oder einen typisierten Client generieren. Bei einer erfolgreichen Analyse werden nur wohlgeformte XML erstellt, die vom konfigurierten Reader akzeptiert werden.

DOCTYPE-Deklarationen werden vor dem Parsen abgelehnt, auch harmlose. Diese Grenze verhindert externe Entitätsanforderungen, das Lesen lokaler Dateien und die Entitätserweiterung. Durch das Entfernen eines DOCTYPE werden möglicherweise auch Deklarationen entfernt, von denen das Dokument abhängt. Tun Sie dies also nur, wenn Sie Eigentümer der Daten sind und die Konsequenzen verstehen.

Fazit: XML zu JSON ist eine Zuordnung, keine Übersetzung – und wie Sie diese Zuordnung im Syntaxkonverter-Bedienfeld in Ihrem Browser überprüfen können

Behandeln Sie das Ergebnis als dokumentierte Zuordnung von ToolAcre: `@` für Attribute, `#text` für gemischten Elementtext, `#cdata` für CDATA, Arrays nach wiederholten Geschwistern und literale Namespace-Präfixe. Diese Regeln machen die Ausgabe vorhersehbar, ohne vorzugeben, dass XML und JSON ein gemeinsames Datenmodell haben.

Zur Inspektion ist diese Projektion schnell und lesbar. Für eine dauerhafte Integration testen Sie ein oder mehrere Vorkommen, Attribute, die Namen mit untergeordneten Elementen teilen, leere Elemente, gemischte Inhalte und Namespaces. Wenn Elementreihenfolge oder Schemaeinschränkungen wichtig sind, analysieren Sie XML anhand dieses Vertrags, anstatt von einer generischen konvertierten Form abhängig zu sein.

Behalten Sie die rohe Vorrichtung XML neben der normalisierten Erwartung. Durch diese Paarung bleiben Beweise erhalten, wenn ein Abhängigkeits-Upgrade die Array-Verarbeitung, das Beschneiden von Leerzeichen oder die Entitätsdekodierung ändert. Es bietet Prüfern außerdem die Möglichkeit, Unterscheidungen zu sehen, die die Ansicht JSON nicht tragen kann. Ein konvertiertes Objekt allein kann nicht beweisen, ob eine leere Zeichenfolge von einem selbstschließenden Element, gepaarten Tags oder einer anderen Konvention in der Quelle stammt.