XML-zu-JSON-Konverter

1. 1

   XML hinzufügen

   Fügen Sie das Markup in den Editor ein oder legen Sie eine Datei auf der Seite ab. XML, SVG, RSS, Atom, WSDL, XSD, KML, GPX, plist und OPML werden akzeptiert, und die Kodierung wird aus der Bytereihenfolge-Markierung oder der XML-Deklaration erkannt.

2. 2

   Ausgabeform wählen

   Kompakt ist die vertraute Form, die die meisten Werkzeuge erzeugen. BadgerFish und GData sind die beiden Konventionen langlebiger APIs. Parker liefert die schlichtesten Werte. JsonML bewahrt die Dokumentreihenfolge und lässt sich exakt zurückwandeln.

3. 3

   Werteverhalten einstellen

   Entscheiden Sie, ob Attribute erhalten bleiben und welches Präfix ihre Schlüssel tragen, ob ein einzelnes Element zu einem einelementigen Array wird, was aus einem leeren Element wird und ob Zahlen und Booleans erkannt statt als Text belassen werden. Die Vorschau aktualisiert sich bei jeder Änderung.

4. 4

   Konvertieren, herunterladen oder kopieren

   Klicken Sie auf Konvertieren, um die Datei zu schreiben. Wählen Sie 2 Leerzeichen, 4 Leerzeichen, Tabulatoren oder minifizierte Ausgabe, dann laden Sie die .json herunter oder kopieren sie. Mit Pro konvertieren Sie bis zu 50 Dateien auf einmal und nehmen sie als ein einziges ZIP mit.

Die meisten XML-zu-JSON-Konverter treffen eine stille Entscheidung für Sie und lassen Ihnen keine Möglichkeit, sie zu ändern: sie wählen eine Form, verwerfen Ihre Attribute und geben JSON zurück, das richtig aussieht. Dieses hier fragt. Sie wählen die Ausgabekonvention, ob Attribute überleben und welches Präfix sie tragen, ob ein einzelnes Element ein Wert oder ein einelementiges Array ist, was ein leeres Element bedeutet und was mit Namensraum-Präfixen geschieht — und die Vorschau neben den Reglern zeigt die Antwort, während Sie jeden davon ändern.

• Nichts geht verloren — Attribute, CDATA-Abschnitte, gemischter Text und Verarbeitungsanweisungen überstehen alle die Konvertierung. Jedes davon hat einen Regler, Sie entscheiden also, was bleibt, statt hinterher zu entdecken, was fehlte.
• Fünf Ausgabeformen — Kompakt, BadgerFish, GData, Parker und JsonML. Vier sind die Konventionen echter APIs; JsonML ist die, die die Dokumentreihenfolge bewahrt und sich exakt zurückwandeln lässt.
• Fehler, mit denen man arbeiten kann — Ein fehlgeschlagenes Parsen nennt Zeile, Spalte, Quellzeile und setzt einen Zeiger unter das schuldige Zeichen, mit einer Meldung, die den Fehler benennt statt zu wiederholen, dass die Datei ungültig ist.
• Große Dateien bleiben flüssig — Lesen und Schreiben geschehen außerhalb der Oberfläche, die Seite friert also nie ein. Ein 25-MB-Dokument konvertiert in etwa einer Sekunde, mit Fortschrittsbalken und funktionierendem Abbrechen.

Es gibt keine einzig richtige Art, XML als JSON darzustellen — deshalb existieren mehrere Konventionen und deshalb lassen ernsthafte Bibliotheken Ihnen die Wahl. XML hat Attribute, geordnete Kinder, gemischten Text und Namensräume; JSON hat Objekte, Arrays und Zeichenketten. Jedes Mapping opfert eines davon. Das richtige Opfer für Ihren nächsten Schritt zu wählen ist der größte Teil der Arbeit.

• Kompakt — die Vorgabe — Elemente werden zu Schlüsseln, Attribute bekommen das Präfix @_ und Text steht unter #text. Das ist die Form, die die meisten Werkzeuge und Tutorials erzeugen, sie wird also demjenigen vertraut sein, der die Datei als Nächstes liest. Wählen Sie sie, wenn nichts dagegen spricht.
• BadgerFish — einheitlich — Jedes Element ist ein Objekt, Text steht immer unter $, Attribute unter @name und Namensraum-Deklarationen unter @xmlns. Nichts ist je eine nackte Zeichenkette, konsumierender Code muss also nie prüfen, ob ein Feld als Objekt oder als Wert zurückkam. Ausführlich, und dafür vorhersagbar.
• GData — Googles Form — Attribute werden zu normalen Schlüsseln neben den Kindelementen, Text steht unter $t. Kompakt zu lesen und die richtige Wahl, wenn Sie eine bestehende Google-Data- oder Atom-Form treffen müssen.
• Parker — die schlichteste — Attribute werden verworfen, der Name des Wurzelelements entfällt und Blätter werden zu ihren Werten. Das Ergebnis kommt dem am nächsten, was Sie von Hand geschrieben hätten, wenn Sie gleich in JSON angefangen wären. Für Konfiguration und einfache Daten, bei denen Attribute nichts Nötiges tragen.
• JsonML — verlustfrei — Jedes Element wird zu einem Array aus Tagname, Attributen und Kindern in Dokumentreihenfolge. Es ist die einzige Form hier, die einen Hin- und Rückweg übersteht, und die einzige, die ein Element, dann ein anderes, dann wieder das erste darstellen kann.

Ein XML-Element trägt drei verschiedene Dinge gleichzeitig — seine Attribute, seinen Text und seine Kindelemente — und ein JSON-Objekt hat für alle drei nur einen Schlüsselraum. Jede Konvention löst diese Kollision anders, und die Kollision ist real: ein Element mit einem Attribut namens name und einem Kindelement namens name braucht beide.

• Das Attribut-Präfix — @_ als Vorgabe, und konfigurierbar. Seine einzige Aufgabe ist zu verhindern, dass der Schlüssel eines Attributs mit einem gleichnamigen Kindelement kollidiert — jedes Präfix, das in Ihren Tagnamen nicht vorkommt, funktioniert. Setzen Sie es auf leer, wenn Sie wissen, dass es keine Kollisionen gibt, und die flachste Ausgabe wollen.
• Der Textschlüssel — #text als Vorgabe. Er wird benutzt, wenn ein Element sowohl Text als auch etwas anderes hat: Attribute, Kindelemente oder beides. Ein Element mit nichts als Text wird direkt als dieser Text geschrieben, einfache Dokumente bleiben also einfach.
• Gemischter Inhalt — Ein Absatz mit einer fetten Passage hat Text vor, zwischen und nach seinen Kindern. Dieser Text wird gesammelt und unter dem Textschlüssel behalten statt verworfen — ein Dokument, das Sie eher als Prosa denn als Daten beschreiben würden, konvertiert also trotzdem zu etwas Lesbarem.
• Leerraum — Text wird standardmäßig getrimmt, denn die Einrückung einer formatierten XML-Datei ist Darstellung und keine Daten. Zusammenfassen reduziert jede Folge von Leerraum auf ein Leerzeichen; Unverändert behält den Text genau wie geschrieben, was Sie für alles wollen, dessen Formatierung zählt, etwa eingebetteten Code.

Die häufigste Überraschung bei der XML-zu-JSON-Konvertierung ist, dass die Form der Ausgabe von der Anzahl der Datensätze in der Eingabe abhängt. Eine Bestellung in der Datei ergibt ein Objekt; zwei ergeben ein Array. Code, der gegen ein Beispiel mit zwei Bestellungen geschrieben wurde, bricht an dem Tag, an dem ein Kunde eine einzige schickt — und der Fehler sieht nach schlechten Daten aus statt nach einem mehrdeutigen Mapping.

• Bei Wiederholung (Vorgabe) — Ein mehrfach als Geschwister auftretender Tag wird zum Array und bewahrt Reihenfolge und Anzahl. Ein einmal auftretender Tag bleibt ein einzelner Wert. Das tun fast alle Konverter, und es ist die lesbarste Ausgabe.
• Immer — Jedes Element, das sich wiederholen könnte, wird zum Array, auch bei einem einzigen Vorkommen. Die Ausgabe ist etwas ausführlicher und vollständig vorhersagbar — was Sie wollen, wenn das JSON direkt in Code geht statt von einem Menschen gelesen zu werden.
• Reihenfolge über verschiedene Tags hinweg — Arrays bewahren die Reihenfolge gleichnamiger Geschwister, aber keine schlüsselbasierte Form kann die verschiedener bewahren — die Schlüssel eines Objekts tragen keine Reihenfolge. Wenn die Verschachtelung zählt, ist JsonML die Form, die sie behält.

Namensräume sind der Grund, warum Unternehmens-XML so aussieht, wie es aussieht, und sie sind die Stelle, an der ein naiver Konverter still etwas Falsches erzeugt. Ein Präfix wie soap: ist nicht Teil des Elementnamens — es ist ein Verweis auf eine weiter oben deklarierte URI, und dasselbe Präfix kann in verschiedenen Teilen eines Dokuments Verschiedenes bedeuten.

• Erhalten — Präfixe bleiben genau wie geschrieben, soap:Envelope bleibt also soap:Envelope und das JSON entspricht dem Dokument, das Sie vor sich haben. Das ist die richtige Vorgabe für SOAP-Antworten und WSDL, wo die Präfixe das sind, worauf sich alle beziehen.
• Entfernen — Präfixe werden für eine sauberere, kürzere Form entfernt. Zwei Elemente aus verschiedenen Namensräumen können dann auf demselben Schlüssel landen, was echter Informationsverlust ist — wenn das passiert, zählt das Werkzeug die Kollisionen und sagt es Ihnen, statt die Verschmelzung still durchgehen zu lassen.
• Auflösen — Jedes Präfix wird durch seine vollständige Namensraum-URI in geschweiften Klammern ersetzt. Nichts ist mehrdeutig und nichts kann kollidieren, um den Preis langer Schlüssel. Diese Form wählt man, wenn das JSON validiert oder verglichen statt gelesen wird.
• Attribute ohne Präfix — Ein Attribut ohne Präfix liegt in gar keinem Namensraum — es erbt nicht den Standard-Namensraum des Elements. Das ist eine Regel, die Konverter regelmäßig falsch machen, und sie falsch zu machen erfindet einen Namensraum, den das Dokument nie deklariert hat.

XML kennt keine Typen. Jeder Wert in einem Dokument ist Text, und jeder Konverter, der Ihnen eine Zahl zurückgibt, hat für Sie entschieden, dass der Text numerisch genug aussah. Diese Entscheidung ist oft nützlich und gelegentlich zerstörerisch — deshalb ist sie hier ein Regler und deshalb ist sie aus, bis Sie sie einschalten.

• Was umgewandelt wird — Einfache Ganzzahlen und Dezimalzahlen, true, false und null. Sonst nichts.
• Was bewusst nicht umgewandelt wird — Ein Wert mit führenden Nullen bleibt Text, denn eine als 007 geschriebene Bestellnummer ist nicht 7. Ein führendes Plus bleibt Text, denn eine Telefonvorwahl ist keine Zahl. Ein Wert jenseits des sicheren Ganzzahlbereichs bleibt Text, denn ihn umzuwandeln würde die Ziffern still verändern. Ebenso Exponential- und Hexadezimalschreibweise, ebenso Infinity und NaN, die eine naive numerische Umwandlung akzeptiert und die kein XML-Dokument meint.
• Die Hin-und-zurück-Regel — Ein Wert wird nur dann zur Zahl, wenn das Zurückschreiben dieser Zahl genau die Zeichen ergibt, die in der Datei standen. Das schützt 1.0, das die meisten Konverter in 1 verwandeln und zurückgeben, als wäre nichts geschehen.
• Leere Elemente — Ein leeres Element kann sinnvollerweise eine leere Zeichenkette, ein null oder ein leeres Objekt sein, und welches richtig ist, hängt von Ihrem nächsten Schritt ab. Statt für Sie zu wählen ist es ein Regler, damit sich ein nullbares Feld von einem wirklich leeren unterscheiden lässt.

Kaputtes XML ist der Normalfall, nicht die Ausnahme, und es ist meist aus einem von etwa sechs Gründen kaputt. Ein Konverter, der mit dem Wort Ungültig antwortet, hat Ihnen nichts gesagt, was Sie nicht wussten; was Sie brauchen, ist das Zeichen, das es ausgelöst hat.

• Zeile, Spalte und ein Zeiger — Jeder Fehlschlag meldet, wo er passierte, zeigt die Quellzeile und setzt einen Zeiger unter das genaue Zeichen. Lange einzeilige Dokumente werden um die Fehlerstelle ausgeschnitten, damit sich eine minifizierte Datei nicht komplett in das Fehlerfeld druckt.
• Ein nicht maskiertes Kaufmanns-Und — Der häufigste Fehler in handgeschriebenem XML. Ein einzelnes & in Q&A oder in einer URL-Abfrage ist kein gültiges Markup und muss & geschrieben werden. Die Meldung sagt das, statt einen rätselhaften Entity-Fehler zu melden.
• Tags, die nicht zusammenpassen — Ein Start-Tag, der mit einem anderen Namen geschlossen wird, oder ein am Dateiende offen gebliebener Tag. Beide nennen den betroffenen Tag, und der offene Fall zeigt auf die Stelle, an der das Element geöffnet wurde, nicht auf das Dokumentende.
• Namensräume und Duplikate — Ein Präfix, das ohne Deklaration verwendet wird, oder dasselbe Attribut zweimal an einem Element. Beides sind Fehler und keine stillen Verschmelzungen, denn still einen von zwei Werten zu behalten setzt Daten in Ihre Ausgabe, die niemand geschrieben hat.
• Entities und DTDs — Ein DOCTYPE wird geparst und übersprungen, nicht befolgt. Deklarierte Entities werden am Namen erkannt, aber nie expandiert — ein Verweis darauf wird klar gemeldet statt ersetzt, was hier zugleich den klassischen Entity-Expansion-Angriff unmöglich macht.

Alles Folgende ist XML, und jede dieser Dateien war eine, die Sie in der vorigen Fassung dieser Seite auswählen konnten, mit der dann aber nichts geschah — weil sie nur die Endung .xml kannte, während das Betriebssystem für die meisten anderen gar keinen Typ meldet.

• Feeds und Syndication — RSS und Atom, samt der item- und entry-Mengen, die die nützlichste zeilenweise Ausgabe ergeben. OPML für Abonnementlisten.
• Webdienste — WSDL-Dienstdefinitionen und XSD-Schemata, beide voller Namensräume und der Grund, warum Erhalten die Vorgabe ist.
• Grafik und Geografie — SVG-Dokumente, wo die Umwandlung nach JSON der Weg ist, auf dem ein Build-Skript einen Pfad oder eine viewBox liest. KML und GPX für Kartendaten und aufgezeichnete Strecken.
• Konfiguration und Dokumente — Apple-plist-Eigenschaftslisten, .config- und .csproj-Builddateien, Maven-POM-Dateien, XSLT-Stylesheets und XHTML.

Das Dokument wird außerhalb der Oberfläche gelesen und geschrieben, die Seite bleibt also während der Konvertierung einer großen Datei bedienbar — mit echtem Fortschritt und einem Abbrechen, das sofort wirkt.

• Ausgabeform — Kompakt, BadgerFish, GData, Parker oder JsonML. Ändert die gesamte Struktur; die Vorschau aktualisiert sich sofort.
• Attribute — Behalten oder verwerfen, und das Präfix ihrer Schlüssel festlegen. In Parker ohne Wirkung, das Attribute per Definition verwirft.
• Textschlüssel — Der Schlüssel, der den eigenen Text eines Elements trägt, wenn es zusätzlich Attribute oder Kinder hat.
• Arrays — Nur wiederholte Elemente, oder für jedes wiederholbare Element ein Array erzwingen.
• Namensräume — Präfix erhalten, entfernen oder zur vollen URI auflösen.
• Typen — Jeden Wert als Text belassen, oder Zahlen, Booleans und null mit der Hin-und-zurück-Regel erkennen.
• Leere Elemente — Eine leere Zeichenkette, ein null oder ein leeres Objekt.
• Leerraum — Trimmen, Folgen auf ein Leerzeichen zusammenfassen, oder den Text unverändert lassen.
• CDATA — Mit dem Elementtext verschmelzen, oder unter einem eigenen Schlüssel behalten.
• Kommentare und Anweisungen — Standardmäßig verworfen; behalten Sie eines von beiden, wenn Sie es brauchen — vollständig ausdrücken können das nur die reihenfolgetreuen Formen.
• Einrückung — 2 Leerzeichen, 4 Leerzeichen, Tabulatoren oder minifiziert in einer Zeile.
• Kodierung — Wird aus der Bytereihenfolge-Markierung oder der XML-Deklaration erkannt und lässt sich überschreiben, wenn eine Datei die falsche deklariert.

In XML lebt noch immer sehr viel echter Datenbestand — Kontoauszüge, behördliche Feeds, SOAP-Dienste, Builddateien, Kartenexporte und jeder je veröffentlichte RSS-Feed — während fast alles, was heute zum Verarbeiten von Daten gebaut wird, JSON erwartet. Konvertieren ist meist der kürzeste Weg dazwischen, und kurz bleibt er nur, wenn die Konvertierung unterwegs nichts verliert.

• Alte Dienste in modernen Code — Eine SOAP-Antwort wird zu etwas, das ein fetch-Aufruf ohne XML-Bibliothek im Bundle lesen kann.
• Feeds in Pipelines — Ein RSS- oder Atom-Feed wird zu einer Datensatzmenge, und mit zeilenweiser Ausgabe zu etwas, das ein Datenwerkzeug streamen kann.
• Konfiguration in Werkzeuge — Eine plist, eine POM oder eine .config-Datei wird für ein Skript lesbar, das keinen XML-Parser hat.
• Untersuchen — Ein tief verschachteltes Dokument liest sich als JSON in einem Editor, der es einklappt, deutlich besser — oft der eigentliche Grund zu konvertieren.
• Es bleibt privat — Kontoauszüge und Dienstantworten sind genau die Dokumente, die niemand in eine Website einfügen sollte, die sie hochlädt. Diese hier lädt nichts hoch.

• JSON zu XML
• JSON-Formatierer
• JSON-Validator
• JSON-Betrachter
• YAML zu JSON
• JSON-Minifizierer