JSON in XML umwandeln
Dieses Tool wandelt ein Dokument in Ihrem Browser um. Member, deren Namen mit dem Attribut-Präfix beginnen, werden zu XML-Attributen, ein Array wiederholt seinen Member-Namen, statt ein Wrapper-Element zu bekommen, und ein JSON-Schlüssel, der kein gültiger XML-Name ist, wird umgeschrieben, wobei der Originalname in einem name-Attribut erhalten bleibt – statt stillschweigend verunstaltet zu werden.
Wie funktioniert JSON in XML umwandeln?
Die schwierige Richtung ist meist XML → JSON, weil XML die strukturreichere Seite ist. Umgekehrt gibt es weniger Entscheidungen, aber drei davon sind tragend, und eine davon falsch zu treffen erzeugt eine Ausgabe, die überhaupt kein wohlgeformtes XML ist.
JSON-Schlüssel sind keine XML-Namen
Ein JSON-Schlüssel kann alles Mögliche sein: 2024 total, user.name, "", ein Emoji. Ein XML-Elementname darf nicht mit einer Ziffer beginnen, darf keinen Leerraum enthalten und darf nicht leer sein. Die übliche Reaktion ist, Unterstriche einzusetzen – was den Schlüssel stillschweigend zerstört. Hier wird der Name genauso repariert, und der Originalname wird in ein name-Attribut geschrieben; das Dokument ist damit wohlgeformt, und nichts geht verloren. Die Anzahl reparierter Schlüssel wird ausgewiesen, statt sie zu verstecken.
Ein Array als Wurzel würde zwei Wurzelelemente erzeugen
Ein XML-Dokument hat genau ein Wurzelelement; das ist keine Stilregel, das ist es, was ein Dokument zu einem Dokument macht. Die Elemente eines Top-Level-JSON-Arrays auf der obersten Ebene auszugeben erzeugt so viele Wurzeln, wie es Elemente gibt, und jeder XML-Parser lehnt das ab. Deshalb wird eine Array-Wurzel verpackt, und ihre Elemente bekommen den Item-Namen.
Ein Array, das ein Member ist, ist ein anderer Fall: Es wiederholt den eigenen Elementnamen des Members, denn so drückt XML eine Liste aus. Es gibt kein Container-Element, außer das JSON hätte eines – genau das lässt die Ausgabe den Weg durch den Konverter „XML in JSON umwandeln“ zurücknehmen und ergibt dasselbe Element wieder, wenn es in einer Force-Array-Liste steht.
Escaping ist nicht optional
&, < und > im Text, dazu " und echte Zeilenumbrüche in Attributwerten, müssen alle escapet werden, sonst ist die Ausgabe fehlerhaft. Der Zeilenumbruch in einem Attribut ist der, den Leute übersehen: XML-Parser normalisieren ihn zu einem Leerraumzeichen, sofern er nicht als geschrieben ist – der Wert ändert sich auf dem Rückweg also stillschweigend.
XML ist größer, und das ist der Preis dafür
Jeder Elementname wird zweimal geschrieben. Die Größendifferenz wird in der Statistikleiste ausgewiesen, damit die Kosten sichtbar bleiben. Was man dafür bekommt, sind Attribute, Namespaces, Kommentare, Processing Instructions und Schema-Validierung – keines davon hat JSON, und jedes davon kann der Grund sein, warum Sie überhaupt umwandeln.
JSON
{
"@id": "1",
"line": ["a", "b"],
"note": null
}XML
<?xml version="1.0" encoding="UTF-8"?> <root id="1"> <line>a</line> <line>b</line> <note/> </root>
Welche Optionen und Sonderfälle unterstützt JSON in XML umwandeln?
| Parameter | Typ | Standard | Verhalten & Sonderfälle |
|---|---|---|---|
| Wurzelname | Elementname | root | Das einzelne umschließende Element. Erforderlich, da ein XML-Dokument genau ein Root-Element hat, die oberste Ebene von JSON jedoch keinen Namen liefert. |
| Attributpräfix | string | @ | Mit diesem beginnende Member werden zu Attributen. Entspricht dem Standard des XML-zu-JSON-Konverters, sodass ein Dokument einen Rundtrip durch beide überlebt. |
| Textschlüssel | string | #text | Der Member, der als Elementinhalt und nicht als untergeordnetes Element geschrieben wird. So erhält ein Element sowohl Attribute als auch Text. |
| Elementname für Listenpunkte | Elementname | Element | Elementname für die Items eines Top-Level-Arrays, das keinen Member-Namen zum Entleihen hat. Arrays, die Member sind, wiederholen stattdessen den Member-Namen. |
| Einrückung | Leerzeichen | 2 | Null erzeugt eine Zeile, was für die Übertragung wünschenswert ist – Whitespace zwischen Elementen ist für einen strengen Parser signifikant, und das Formatieren ändert das Dokument. |
| Deklaration | Boolesch | on | Gibt <?xml version="1.0" encoding="UTF-8"?> aus. Schalten Sie es aus, wenn die Ausgabe ein Fragment ist, das in ein größeres Dokument eingebettet wird. |
| Leere selbst schließen | Boolesch | on | null und leere Objekte werden zu <a/> statt <a></a>. Beide sind für jeden XML-Parser identisch; einige downstream-Tools sind anspruchsvoller als die Spezifikation. |
| Ungültiger Schlüssel | repariert | Original beibehalten | Ein Schlüssel, der nicht als Elementname verwendet werden kann, wird umgeschrieben und der Original in einem Attribut namens name geschrieben. Die Anzahl der reparierten Schlüssel wird über der Ausgabe gemeldet. |
| Escaping | automatisch | — | & < > im Text; & < > " und Zeilenumbrüche in Attributwerten. Ein nicht escapter Zeilenumbruch in einem Attribut wird vom Reader zu einem Leerzeichen normalisiert, was den Wert ändert. |
Häufig gestellte Fragen
Wie bekomme ich Attribute statt Kindelemente?
Setzen Sie dem Member-Namen ein @ voran – {"@id": "1"} wird zu id="1" am Element. Das Präfix ist konfigurierbar, und es ist derselbe Standard, den der Konverter „XML in JSON umwandeln“ verwendet; ein Dokument kann also XML → JSON → XML durchlaufen und in derselben Form wieder herauskommen.
Warum wurde mein Schlüssel umbenannt?
Weil er kein gültiger XML-Elementname ist: Er begann mit einer Ziffer, enthielt einen Leerraum oder ein Zeichen, das XML nicht erlaubt, oder er war leer. Der Elementname wird repariert, und der ursprüngliche Schlüssel wird in ein name-Attribut geschrieben; nichts geht verloren, und das Dokument ist wohlgeformt. Die Anzahl steht über der Ausgabe, damit Sie wissen, dass es passiert ist.
Warum gibt es kein Wrapper-Element um mein Array?
Weil XML eine Liste ausdrückt, indem es das Element wiederholt, und nicht durch ein umschließendes Element. {"line": ["a","b"]} wird zu zwei <line>-Elementen – das ist idiomatisches XML und überlebt einen Round-Trip korrekt. Wenn Sie <lines><line>…</line></lines> wollen, stecken Sie diese Verschachtelung ins JSON: {"lines": {"line": ["a","b"]}}.
Sollte ich die Ausgabe einrücken?
Nicht für alles, was über die Leitung geht. Leerraum zwischen Elementen ist in XML signifikant – ein strikter Parser liest Ihre Einrückung als Textknoten, und bei gemischten Inhalten ändert sie das Dokument tatsächlich. Einrücken zum Lesen, indent auf 0 zum Senden. Das ist ein echter Unterschied zu JSON, wo Leerraum nie eine Rolle spielt.
Kann es ein Dokument erzeugen, das gegen mein XSD validiert?
Nur zufällig. Ein Schema legt Elementreihenfolge, Kardinalität, Datentypen und Namespaces fest, und diese Informationen existieren im JSON nicht – die Member eines Objekts haben keine aussagekräftige Reihenfolge, der Konverter kann also nicht wissen, welche Sequenz Ihr Schema verlangt. Nutzen Sie das Tool, um die Form zu bekommen; sortieren Sie dann um und ergänzen Sie Namespaces, passend zum Schema.
Wird mein JSON hochgeladen?
Nein. Parsen und Umwandlung laufen in dem Tab, den Sie schon offen haben; das können Sie im Netzwerk-Panel bestätigen. Der übliche Grund, JSON zu XML umzuwandeln, ist die Anbindung eines älteren Enterprise-Systems, und die Payloads dabei sind selten solche, die man durch einen unbekannten Server laufen lassen möchte.