JSON-zu-XML-Konverter

1. 1

   JSON einfügen oder ablegen

   Fügen Sie JSON in das Feld ein oder legen Sie eine .json-, .jsonl-, .ndjson-, .geojson- oder .txt-Datei ab. JSON Lines wird automatisch erkannt — Sie müssen keinen Modus umschalten.

2. 2

   Wurzel und wiederholte Elemente benennen

   Legen Sie das oberste Element fest (Standard: root). Wählen Sie, ob alle Array-Elemente item heißen, nach dem Schlüssel des Arrays benannt werden oder nach dessen Singular — aus books wird dann book.

3. 3

   Entscheiden, wie Werte geschrieben werden

   Wählen Sie, was aus einem null wird: ein leeres Element, xsi:nil oder gar nichts. Aktivieren Sie die Attribut-Zuordnung, wenn Ihre Schlüssel der @name- und #text-Konvention folgen. Wählen Sie Einrückung, Deklaration und Ausgabekodierung.

4. 4

   Konvertieren, dann herunterladen oder kopieren

   Klicken Sie auf In XML konvertieren. Die Vorschau aktualisiert sich bei jeder Einstellung, sodass Sie die Struktur vor dem Export sehen. Laden Sie die .xml herunter, kopieren Sie sie oder erzeugen Sie ein passendes .xsd-Schema.

Dieser kostenlose Konverter macht aus JSON wohlgeformtes XML — auf Ihrem Gerät. Fügen Sie Daten ein oder legen Sie eine Datei ab, benennen Sie das Wurzelelement und die wiederholten Elemente eines Arrays, entscheiden Sie, was aus einem null und einem unbrauchbaren Schlüssel wird, und exportieren Sie. Die Vorschau aktualisiert sich bei jeder Einstellung, sodass Sie die Struktur sehen, bevor Sie sich festlegen. Ungültiges JSON zeigt das Problem, Zeile und Spalte sowie einen Ausschnitt — dazu Links zum JSON-Formatierer und -Validator.

• Wurzelelement — Das oberste Tag, das das Dokument umschließt — root, data, response, jeder gültige XML-Name. Ein ungültiger Name wird repariert und die Änderung wird Ihnen gezeigt statt stillschweigend angewendet.
• Benennung der Array-Elemente — Ein festes Tag für jedes Array, der Schlüssel des Arrays oder dessen Singular — aus einem books-Array werden book-Elemente, so wie es jemand von Hand geschrieben hätte.
• Attribute und Text — Mit der @name- und #text-Konvention wird ein Schlüssel @id zu einem XML-Attribut und #text zum Text des Elements. Das ist das exakte Gegenstück zum XML-zu-JSON-Tool.
• Null, leer und fehlend — Ein JSON-null kann ein leeres Element, ein xsi:nil-Element für ein Schema oder gar nichts sein. Drei wirklich verschiedene Bedeutungen — die meisten Konverter bieten eine.
• Fehlerdetails — Ungültiges JSON zeigt Meldung, Zeile, Spalte und einen Ausschnitt mit markierter Position. Doppelte Schlüssel werden ebenfalls gemeldet, weil sie zulässig und mehrdeutig sind.

JSON kennt sechs Arten von Werten, XML kennt Elemente, Attribute und Text. Die Zuordnung ist direkt; die einzigen Entscheidungen sind die, die die Einstellungen sichtbar machen.

• Objekte werden zu verschachtelten Elementen — Jeder Schlüssel wird zu einem gleichnamigen Kindelement, in der Reihenfolge der Quelle.
• Arrays werden zu wiederholten Elementen — Ein Array wird nicht zu einem Element mit einer Liste darin, sondern zum selben Element, einmal pro Eintrag geschrieben — so drückt XML seit jeher einen wiederholten Wert aus.
• Zeichenketten, Zahlen und Wahrheitswerte werden zu Text — XML hat für keinen davon einen eigenen Typ, also wird jeder als Textinhalt geschrieben. Mit Typangaben trägt jedes Element zusätzlich type="number", type="string" oder type="boolean".
• Zahlen werden kopiert, nicht neu berechnet — Es kommen die Ziffern heraus, die Sie geschrieben haben. Eine zwanzigstellige ID bleibt exakt, -0 bleibt -0 und 1e-7 bleibt 1e-7 — nichts davon übersteht einen Umweg über einen Gleitkommawert.
• Die Wurzel muss erfunden werden — JSON darf oben ein Array oder sogar eine nackte Zeichenkette haben; XML braucht genau ein Wurzelelement. Genau das benennt die Einstellung Wurzelelement.

Das ist die eine Sache, die die meisten JSON-zu-XML-Konverter falsch machen, und man sieht es der Ausgabe nicht an. XML kann Leerraum nicht als dekorativ kennzeichnen — jedes Zeichen zwischen den Tags eines Elements gehört zu seinem Wert. Ein Element mit Textinhalt kann also nicht eingerückt werden, ohne seine Aussage zu ändern.

• Der Fehler — Naiv geschrieben wird aus dem Array ["a","b"] ein item-Element mit einem Zeilenumbruch vor dem a und einem Zeilenumbruch plus zwei Leerzeichen danach. Von jedem konformen Parser zurückgelesen ist dieser Wert nicht "a", sondern Zeilenumbruch, a, Zeilenumbruch, zwei Leerzeichen.
• Die Folge — Pretty-Print einzuschalten verändert die Daten, und die kompakte und die eingerückte Ausgabe desselben Konverters bedeuten Unterschiedliches. Nichts meldet einen Fehler und nichts sieht falsch aus.
• Die Regel hier — Leerraum wird nur dann in ein Element eingefügt, wenn jedes seiner Kinder ein Element ist. Ein Element mit Text steht bei jeder Einrückung auf einer Zeile. Der Rückweg durch zwei unabhängige XML-Parser ist Teil der Testsuite dieses Tools.

JSON kennt keine Attribute, also braucht ein Konverter eine Konvention, um welche zu erzeugen. Dieses Tool nutzt die, die XML-zu-JSON-Bibliotheken ohnehin sprechen: Ein Schlüssel, der mit @ beginnt, wird zum Attribut des umschließenden Elements, und der Schlüssel #text wird zu dessen Textinhalt. Standardmäßig aus, weil Ihre Daten diese Schlüssel legitim verwenden dürfen.

• Was dabei herauskommt — {"@id": "7", "name": "Ada"} wird zu einem Element mit id="7" und einem name-Kind, statt zu zwei Kindelementen, von denen eines _id heißt.
• Hin und zurück — Es ist die Konvention, die das XML-zu-JSON-Tool dieser Seite liest — ein Dokument, das hin und zurück konvertiert wird, behält seine Form.
• Wenn ein Wert kein Attribut sein kann — Ein Attribut enthält flachen Text. Ein Objekt oder Array unter einem @Schlüssel wird stattdessen als gewöhnliches Kindelement geschrieben — nie verworfen, nie als JSON-Klumpen in Ihr XML gepresst — und die Anzahl wird angezeigt.
• Gemischter Inhalt — Hat ein Element am Ende sowohl Text als auch Kindelemente, wird das gesamte Element auf einer Zeile geschrieben. Nur so bleibt der Text genau erhalten; siehe den Abschnitt darüber.

JSON-Schlüssel sind beliebige Zeichenketten. XML-Elementnamen nicht: Sie müssen mit einem Buchstaben oder Unterstrich beginnen, dürfen keine Leerzeichen und kaum Satzzeichen enthalten und nicht mit den Buchstaben xml beginnen. Irgendetwas muss nachgeben — und wie, ist hier eine Einstellung statt einer stillen Entscheidung.

• Reparieren und auflisten — Aus "first name" wird first_name, aus "2024" wird _2024. Einer führenden Ziffer wird ein Zeichen vorangestellt statt sie zu löschen, damit 2024 und 024 nicht denselben Namen ergeben. Jede Umbenennung steht im Feld neben der Vorschau.
• Oder den Originaltext behalten — Die andere Option schreibt ein key-Element mit name="first name", sodass die Originalzeichenkette wörtlich im Dokument überlebt. Hässlicher, verlustfrei, und genau das, was diese Seite vor dem Rebuild erzeugt hat.
• Umlaute und nicht-lateinische Schriften bleiben — Führung, señor und 名前 sind allesamt gültige XML-Elementnamen und werden unverändert geschrieben. Konverter, die alles außer A–Z entfernen, verstümmeln kommentarlos die Feldnamen der meisten nicht-englischen Exporte.
• Kollisionen werden getrennt — Reparieren "first name" und "first-name" beide zu first_name, wird das zweite zu first_name_2 — sie zu verschmelzen wäre Datenverlust, der wie Erfolg aussieht. Ein bereits gültiger Schlüssel behält immer seinen eigenen Namen.
• Emoji werden absichtlich zum Unterstrich — Die XML-Spezifikation erlaubt sie; echte Parser sind sich uneinig. Ein strenger Parser weist ein Dokument mit einem Emoji im Elementnamen komplett zurück, ein anderer verwirft das Element samt Inhalt stillschweigend. Ein Unterstrich wird überall gleich gelesen.

"Kein Wert" hat in JSON mehrere Bedeutungen und in XML mehrere Schreibweisen. Die Wahl entscheidet darüber, ob ein Schema das Dokument prüfen kann oder nicht.

• Ein leeres Element — Der Standard. Aus einem null wird ein Element ohne Inhalt — die Form, die die meisten Empfänger erwarten.
• xsi:nil — Schreibt das Element als nil und deklariert den Schema-Instance-Namespace auf der Wurzel. Nur diese Schreibweise lässt sich von "das Feld wurde vergessen" unterscheiden, und genau sie erwartet ein XSD.
• Ausgelassen — Das Element wird gar nicht geschrieben. Das gilt nur für Objekt-Mitglieder — ein null als Array-Eintrag wird trotzdem geschrieben, denn die Länge eines Arrays ist Information, und ein entfernter Eintrag verschiebt stillschweigend jeden nachfolgenden Index.
• Leere Objekte und Arrays — Beide werden zu einem leeren Element. Ein leeres Array erzeugt keine Leerzeile zwischen zwei Tags, was ein naiver Schreiber ausgibt.

Jeder konkurrierende Konverter schreibt für jedes Array im Dokument item und verliert damit genau die Information, die das Array trug: was darin stand. Hier gibt es drei Optionen, und die dritte bietet sonst niemand.

• Ein festes Tag — Jeder Array-Eintrag bekommt das Tag, das Sie eintippen — standardmäßig item. Vorhersehbar, und das, was ein gegen einen anderen Konverter geschriebener Empfänger erwartet.
• Der übergeordnete Schlüssel — Die Einträge werden nach dem Schlüssel benannt, an dem das Array hing — ein books-Array erzeugt books-Elemente in einem books-Element.
• Der Singular des Schlüssels — books ergibt book, categories ergibt category, children ergibt child. So hätte es jemand von Hand geschrieben. Lässt sich das Wort nicht verkürzen, wird das feste Tag verwendet, statt einen Namen in sich selbst zu schachteln.
• Ein Array ganz oben — Ein Array an der Spitze des Dokuments hat keinen Schlüssel, nach dem es benannt werden könnte — dann dient der Name des Wurzelelements als übergeordneter Name.

Die drei Einstellungen, die bestimmen, wie die Datei aussieht, nicht was sie sagt. Die Kodierung lohnt das Lesen: Sie ist die Einstellung, die am häufigsten als Beschriftung statt als Tatsache umgesetzt wird.

• Die XML-Deklaration — Standardmäßig an. Sie nennt Version und Kodierung, und ein Empfänger, der sie liest, glaubt ihr — deshalb müssen die Bytes dazu passen.
• Einrückung — Zwei Leerzeichen, vier Leerzeichen, Tabs oder gar nichts. Ohne Einrückung steht das ganze Dokument auf einer Zeile — genau richtig, wenn der Empfänger ein Programm ist und kein Mensch.
• UTF-8 — Der Standard und fast immer die richtige Antwort. Ohne Byte Order Mark geschrieben, weil die Deklaration das bereits sagt und ein solches Zeichen Empfänger stört, die eine spitze Klammer als erstes Zeichen erwarten.
• UTF-16 — Als echte UTF-16-Bytes mit Byte Order Mark geschrieben, denn ein UTF-16-Dokument ohne dieses Zeichen ist nicht zuverlässig erkennbar und wird von mehreren Parsern abgelehnt.
• ISO-8859-1 — Wirklich als Latin-1 kodiert. Jedes Zeichen, das die Kodierung nicht führen kann, wird zuvor als numerische Zeichenreferenz geschrieben — gültiges XML, ohne Verlust. Ein Dokument, das ISO-8859-1 sagt, ist dann auch eines. Ein Konverter, der nur die Beschriftung schreibt und trotzdem UTF-8 ausgibt, erzeugt eine Datei, die auf eine Weise falsch ist, die kein Validator bemerkt.

Ein JSON-Wert pro Zeile, ohne umschließendes Array. Genau das erzeugen Log-Pipelines, Massen-Exporte von APIs und Data-Warehouse-Dumps, und der normale JSON-Parser weist es rundheraus ab — die meisten Konverter können also gerade die Dateien nicht öffnen, die die Leute am häufigsten haben.

• Erkannt, nicht eingeschaltet — Legen Sie eine .jsonl- oder .ndjson-Datei ab und sie wird erkannt. Auch eine .json- oder .txt-Datei, die sich als ein Wert pro Zeile entpuppt, wird erkannt — die Endung ist ein Hinweis, kein Versprechen.
• Was dabei entsteht — Jede Zeile wird zu einem wiederholten Element unter der Wurzel, genau als wären die Zeilen ein Array gewesen. Alle Array-Einstellungen gelten wie sonst auch.
• Leerzeilen werden ignoriert — Ein abschließender Zeilenumbruch am Dateiende ist üblich und kein Fehler. Jede andere Zeile, die kein gültiges JSON ist, meldet ihre Zeilennummer — die einzige Koordinate, die in diesem Format etwas bedeutet.

JSON hat kein Schema, also muss ein XSD aus dem Dokument selbst abgeleitet werden. Dieses wird beim Schreiben des XML gesammelt und nicht in einem zweiten Durchgang über das JSON — es kann daher nur Elemente beschreiben, die tatsächlich erzeugt wurden, mit den Namen, die sie tatsächlich bekommen haben.

• Häufigkeiten kommen aus den Daten — Ein Kindelement, das in irgendeiner Instanz seines Elternteils fehlt, wird als optional markiert. Eines, das in einer einzelnen Instanz mehrfach vorkommt, wird als unbegrenzt markiert.
• Typen werden nur bei Gewissheit eingeengt — Ein Element bekommt einen Ganzzahltyp nur dann, wenn jeder gesehene Wert im Quelltext ganzzahlig war — auch solche, die als Gleitkommazahl nicht überleben würden. Eine einzige Dezimalzahl weitet ihn.
• Mehrdeutigkeit weitet, statt zu raten — Ein Element mit Text und Kindern wird als gemischt markiert; eines, das sowohl Container als auch einfacher Wert war, bleibt offen. Ein Schema, das die Datei ablehnt, aus der es erzeugt wurde, ist schlimmer als gar keines.
• Namespaces passen zusammen — Ein Ziel-Namespace wird nur deklariert, wenn das Dokument selbst in einen geschrieben wurde — ein Schema, das einen Namespace deklariert, den die Instanz nicht nutzt, prüft nichts.

Viele Systeme sprechen weiterhin XML und sonst nichts. Eine Konvertierung erlaubt es, vorhandene JSON-Daten wiederzuverwenden, ohne den Erzeuger umzuschreiben — meist der günstigste Schritt einer Integration.

• Unternehmens- und SOAP-Integration — SOAP-Dienste, EDI-Gateways und ältere ERP-Systeme akzeptieren ausschließlich XML. Eine konvertierte Nutzlast ist oft die ganze Arbeit.
• Konfigurations- und Build-Dateien — Ant, Maven, Spring, Android-Layouts und .NET-Konfiguration sind XML. Als JSON erzeugte Daten müssen in dieser Form ankommen.
• Schema-Validierung — XML hat XSD, womit ein empfangendes System eine fehlerhafte Nutzlast zurückweisen kann, bevor es damit arbeitet. JSON Schema gibt es, aber weit weniger Systeme erzwingen es.
• Dokumente statt Daten — XML beherrscht gemischten Inhalt — Text mit Auszeichnung darin —, was JSON überhaupt nicht ausdrücken kann. Deshalb sind Publikationsformate XML.
• Datenschutz — Die Konvertierung läuft auf Ihrem Gerät. Nichts von der Nutzlast verlässt es, was zählt, wenn die Nutzlast Kundendaten sind und die Alternative wäre, sie in fremde Server einzufügen.

Eine 9 MB große JSON-Datei wird in etwa sechs Zehntelsekunden zu 17,8 MB XML — ohne dass die Seite einfriert.

• Wurzelelement — Das einzige oberste Tag. Muss ein gültiger XML-Name sein; ein ungültiger wird repariert und die Änderung angezeigt.
• Array-Item-Tag — Der Elementname für jeden Array-Eintrag, wenn die Benennung auf ein festes Tag gestellt ist.
• Benennung der Array-Elemente — Festes Tag, übergeordneter Schlüssel oder dessen Singular.
• Umgang mit ungültigen Schlüsseln — Den Schlüssel zu einem gültigen XML-Namen reparieren oder den Originaltext in einem name-Attribut behalten.
• Null-Werte — Ein leeres Element, xsi:nil oder aus dem Dokument ausgelassen.
• Attribut-Zuordnung — @Schlüssel als Attribute und #text als Elementtext behandeln.
• Typangaben — Fügt jedem Element type="number", type="string" oder type="boolean" hinzu. Pro.
• Namespace und Präfix — Eine Ziel-Namespace-URI für das Dokument, als Standard-Namespace oder an ein Präfix gebunden. Pro.
• XML-Deklaration — Ob die Zeile mit Version und Kodierung oben geschrieben wird.
• Ausgabekodierung — UTF-8, UTF-16 oder ISO-8859-1 — deklariert und tatsächlich kodiert.
• Einrückung — Zwei Leerzeichen, vier Leerzeichen, Tabs oder eine kompakte Zeile.
• Dateiname — Der Stamm für die heruntergeladene .xml und .xsd.

Alles, was über die Richtigkeit der Konvertierung entscheidet, ist gratis. Der Tarif entscheidet, wie viel Sie auf einmal hindurchschicken können und ob die Extras dabei sind.

• Gratis — Eine Datei auf einmal, bis 10 MB — etwa vierzigtausend Datensätze eines typischen Exports. Jede Struktureinstellung, jeder Benennungsmodus, jede Null-Regel, die Attribut-Zuordnung, alle vier Einrückungen und alle drei Kodierungen.
• Pro — Keine auferlegte Größenbegrenzung — bis zu dem, was Ihr Gerät leisten kann. Bis zu 50 Dateien in einem Durchgang, als ein ZIP heruntergeladen, dazu XSD-Erzeugung, Ziel-Namespaces und Typangaben.
• Was eine abgelehnte Datei bekommt — Die tatsächliche Größe, die Grenze und einen Link zum JSON-Minifier — bei einer Datei, die ein paar Megabyte darüber liegt, ist das wirklich der richtige erste Schritt. Nie ein Fortschrittsbalken, der dann scheitert.

• XML zu JSON
• JSON-Formatierer
• JSON zu YAML
• JSON-Tools
• Check it parses at all

  Confirms the document is valid JSON and says where it stops being valid if not

• Flatten it into a table

  When a person with a spreadsheet is the consumer rather than a system with a schema