Läuft auf Ihrem Gerät · Ihre Datei verlässt nie Ihr Gerät.
Legen Sie eine .xml-Datei ab oder fügen Sie XML aus einer API, einem Feed oder einer Konfigurationsdatei ein und erhalten Sie JSON, mit dem Sie arbeiten können. Das Dokument liest der XML-Parser des Browsers selbst, in der Kodierung, die seine erste Zeile angibt; alles Wohlgeformte wird umgewandelt, und eine fehlerhafte Datei wird mit Zeile und Spalte des Problems gemeldet und damit, was dort nicht stimmt.
Die Zuordnung ist fest und umkehrbar: Jedes Element wird ein Schlüssel; gleichnamige Geschwister werden ein Array; Attribute bleiben unter Schlüsseln mit @ erhalten (id="A3" wird zu "@id": "A3"); und enthält ein Element sowohl Text als auch Kinder oder Attribute, landet der Text unter "#text". Ein Element mit nur Text wird direkt zu diesem Wert.
Mit eingeschalteter Typerkennung wird aus Text wie 12, true oder einem leeren Element eine Zahl, ein Wahrheitswert oder null; ausgeschaltet bleibt alles Text. Namen mit Namensraum (soap:Body) bleiben, wie geschrieben. Die Vorschau zeigt die ersten 200 Zeilen vor dem Herunterladen.
Nicht geeignet für: Dokumente, die kein wohlgeformtes XML sind (nicht geschlossene Tags, HTML-Seiten) – der Parser meldet das erste Problem, statt zu raten.
Die Typerkennung gilt für Attribute ebenso wie für Text und ändert einen Wert nur dort, wo nichts verloren geht. Ist sie an, wird id="3" zu "@id": 3, während id="007" der Text "007" bleibt. Auch 1.50 bleibt Text, weil es als Zahl als 1.5 zurückgeschrieben würde. TRUE wird zu true. Ein leeres Element wie <note/> und eines, das nur Leerzeichen enthält, werden zu null; das Wort NULL bleibt Text. Datumsangaben wie 2024-01-05 werden nie umgewandelt.
Ist die Erkennung aus, werden leere Elemente zu "", und jeder Wert bleibt Text, genau wie geschrieben.
Manche Teile eines XML-Dokuments haben in JSON keinen Platz und fallen weg: Kommentare, Verarbeitungsanweisungen und die DOCTYPE-Angabe. CDATA-Abschnitte werden zu gewöhnlichem Text, <a><![CDATA[<b>x</b>]]></a> ergibt also "a": "<b>x</b>".
Die Reihenfolge zwischen Elementen mit verschiedenen Namen geht verloren, weil jeder Name zu einem einzigen Schlüssel wird. In <step>1</step><note/><step>2</step> werden beide Schritte in "step": [1, 2] gesammelt, und nichts hält fest, dass die Notiz dazwischen stand. Text, der mit Auszeichnungen gemischt ist, verliert seinen Platz auf dieselbe Weise: <p>Hallo <b>Welt</b> und <i>du</i>!</p> wird zu "b": "Welt", "i": "du" und "#text": "Hallo und !". Für Dokumente, bei denen genau diese Reihenfolge der Inhalt ist, etwa formatierter Fließtext, passt diese Zuordnung nicht.
Namen mit Präfix bleiben, wie sie geschrieben sind, und Namensraum-Deklarationen erscheinen als Attribute: <soap:Envelope xmlns:soap="…"> ergibt einen Schlüssel "soap:Envelope" mit "@xmlns:soap", und /json-to-xml macht aus beidem wieder dasselbe XML.
Abgesehen von Entitäten, die die eigene DOCTYPE-Angabe des Dokuments definiert, werden nur die fünf in XML eingebauten (& < > " ') und numerische wie   verstanden. Hält der Parser an, nennt die Meldung Zeile und Spalte und sagt in klaren Worten, was falsch ist: ein Element, das mit einem anderen Namen geschlossen wird, ein unbekannter Name wie (schreiben Sie stattdessen  ), ein einzelnes & oder <, ein zweites Element auf oberster Ebene oder eine Datei, die zu früh endet.
Die Datei wird in der Kodierung gelesen, die ihre erste Zeile angibt, etwa ISO-8859-1 oder windows-1256. Ohne Angabe wird UTF-8 oder UTF-16 gelesen, und ältere Codepages werden so erkannt, wie es bei /csv-to-json beschrieben ist.
Diese Seite in anderen Sprachen: English · العربية · Français · Español · Русский · Português · 中文 · हिन्दी · Türkçe · עברית · فارسی · اردو · Bahasa Indonesia · বাংলা