XML to JSON Converter

The attribute forces the element to become a JSON object rather than a plain string, since a plain string value has nowhere to hang the attribute. The text content moves to a #text key alongside the attribute key: {"price": {"@currency": "USD", "#text": "19.99"}}. If the element had no attributes, the same tag would have simplified to a plain string value instead.

Per the XML 1.0 spec, a self-closing tag and an explicitly-closed empty tag are equivalent — there's no way to distinguish them once parsed, so both convert identically. With no attributes and no text or child content, there's nothing to populate the JSON value with, so this typically comes through as an empty string or null rather than an empty object, since there are no attribute or child keys to place inside one.

No. JSON's grammar (RFC 8259 / ECMA-404) has no comment syntax and no node type analogous to a processing instruction (<?xml-stylesheet type="text/xsl" href="style.xsl"?>), so both are stripped during conversion. Only element structure, attributes, and character data survive the conversion; anything that isn't data in the XML infoset sense is discarded.

Two separate spec gaps compound here. First, XML often contains whitespace-only text nodes between elements purely for pretty-printing indentation, which can surface as stray #text entries unless explicitly stripped. Second, the JSON grammar (ECMA-404) never mandates that object members preserve insertion order — most parsers do in practice, but it isn't a spec guarantee — so attribute order captured as @keys isn't reliably round-trippable either.

Das ist eine inhärente Mehrdeutigkeit, kein Fehler eines bestimmten Tools. XML kennt keinen nativen Zahlen- oder Boolean-Typ – laut XML-1.0-Spezifikation ist der Inhalt jedes Elements Zeichendaten –, sodass eine XML-zu-JSON-Umwandlung immer eine Entscheidung treffen muss, wann Text zu einer JSON-Zahl bzw. einem Boolean werden soll und wann er ein String bleibt. Diese Entscheidung ist bei Werten wie "007" (eine Postleitzahl oder ein Produktcode, keine 7) oder "1.50" (ein Preis, bei dem eine Umwandlung in eine Zahl die abschließende Null stillschweigend als 1,5 verschluckt) tatsächlich gefährlich. Der sichere Standard, für den sich die meisten Umwandlungen entscheiden, ist, alle Element- und Attributwerte als JSON-Strings zu belassen und dem konsumierenden Code zu überlassen, wann und wie er umwandelt – so geht keine Information stillschweigend verloren.

Browser und Node.js haben kein integriertes Äquivalent zu JSON.parse für XML – man bräuchte DOMParser (nur im Browser) oder eine XML-Bibliothek (Node) und müsste anschließend selbst Traversierungscode schreiben, um Werte über getElementsByTagName oder XPath aus dem DOM-Baum zu holen. JSON.parse hingegen ist ein einziger eingebauter Aufruf, der einem sofort verwendbare Objekte und Arrays liefert, die man direkt destrukturieren kann. Genau diese Lücke erklärt, warum Legacy-SOAP-APIs, RSS-/Atom-Feeds und sitemap.xml-Dateien so häufig am Rand einer JavaScript-Codebasis in JSON umgewandelt werden: Es liegt nicht daran, dass JSON leistungsfähiger wäre, sondern daran, dass das JS-Tooling zum Konsumieren davon bereits vorhanden ist.

XML ist etwa ein Jahrzehnt älter als JSON: XML 1.0 wurde im Februar 1998 zur W3C-Empfehlung, abgeleitet von SGML und als Dokument-Markup-Sprache konzipiert (daher Attribute, gemischter Inhalt und Namensräume). JSON wurde Anfang der 2000er-Jahre von Douglas Crockford aus der Objektliteral-Syntax von JavaScript extrahiert, zunächst 2006 formal als RFC 4627 spezifiziert, dann als ECMA-404 (2013) neu spezifiziert und liegt heute als RFC 8259 (2017) vor. JSONs Minimalismus – vier Datentypen, keine Attribute, kein gemischter Inhalt – spiegelt seinen Ursprung als Übertragungsformat zum Austausch von Datenstrukturen mit einem laufenden Programm wider, nicht zur Auszeichnung von Dokumenten.

Nein – und die @-Präfix-Konvention, die dieses Tool für Attribute verwendet, ist selbst ein Beleg für diese Lücke. Diese Konvention (@key für Attribute, #text für gemischten Inhalt) ist nicht Teil der JSON-Spezifikation; sie ist eine weit verbreitete, aber informelle Konvention, und verschiedene XML-zu-JSON-Tools behandeln dieselbe Eingabe unterschiedlich – manche flachen Attribute zu einfachen Schlüsseln ab, manche verpacken Elementinhalte in einen $- oder _text-Schlüssel, manche nutzen die BadgerFish- oder Parker-Konventionen. JSON kennt von Haus aus überhaupt kein Attributkonzept, sodass jedes XML-zu-JSON-Tool seine eigene Konvention über reine JSON-Objekte legt – und die JSON-Ausgabe eines Konverters muss nicht mit der eines anderen für dieselbe XML-Eingabe übereinstimmen.

Da dieser Konverter Namensraum-Präfixe wörtlich als Teil des Schlüsselnamens beibehält, statt sie zur vollständigen Namensraum-URI aufzulösen, werden "a:id" und "b:id" zu zwei unterschiedlichen JSON-Schlüsseln und kollidieren nicht – aber nur solange sich die Präfixe selbst unterscheiden. Verwenden zwei verschiedene Teile eines Dokuments zufällig dasselbe Präfix für unterschiedliche Namensraum-URIs (in XML zulässig, da Präfixbindungen auf das Element beschränkt sind, in dem sie deklariert werden), oder parst ein nachgelagertes Tool das JSON ohne Namensraumkontext neu, identifiziert dieser präfixbasierte Schlüssel nicht mehr zuverlässig, zu welchem Namensraum das Element ursprünglich gehörte. Bei Dokumenten, in denen Namensraum-URIs wichtiger sind als Präfixe, ist es sicherer, Präfixe vor der Umwandlung zu normalisieren.