JSON, XML oder CSV? Das richtige Datenformat für die Aufgabe wählen
13. Oktober 2026
JSON, XML und CSV existieren alle, um strukturierte Daten zwischen Systemen zu bewegen, aber sie als austauschbar zu behandeln, ist der Weg, wie Integrationsprojekte mit verlorenen Daten, kaputten Importen oder aufgeblähten Dateien enden. Jedes Format traf echte Design-Kompromisse für die Probleme und Epochen, für die es entwickelt wurde, und diese Kompromisse zu kennen macht die Wahl des richtigen Formats für eine bestimmte Aufgabe unkompliziert.
Worin ist CSV tatsächlich gut, und wo scheitert es?
CSV (kommagetrennte Werte) ist so einfach, wie ein strukturiertes Format nur sein kann – reiner Text, eine Zeile pro Datensatz, Werte durch Kommas getrennt –, was es universell lesbar für Tabellenkalkulationssoftware, Datenbanken und praktisch jedes je gebaute Datentool macht. Es ist hervorragend für flache, tabellarische Daten geeignet: eine Liste von Datensätzen, bei denen jede Zeile dieselben Felder hat. Es scheitert in dem Moment, in dem Daten irgendeine echte Struktur jenseits einer flachen Tabelle haben – verschachtelte Objekte, Eins-zu-viele-Beziehungen oder Felder, die legitim Kommas oder Zeilenumbrüche enthalten (uneinheitlich über verschiedene CSV-Implementierungen hinweg gehandhabt) – all das treibt CSV über das hinaus, wofür es konzipiert wurde.
Warum wurde JSON speziell für Web-APIs zum Standard?
Die Objekt-und-Array-Struktur von JSON bildet sich fast direkt auf die Art ab, wie die meisten modernen Programmiersprachen Daten bereits im Speicher darstellen, was bedeutet, dass eine JSON-Nutzlast oft mit minimalem Übersetzungsaufwand direkt in eine native Datenstruktur geparst werden kann – ein bedeutender praktischer Vorteil für Web-APIs, bei denen Geschwindigkeit und Einfachheit sowohl beim Erzeugen als auch beim Konsumieren von Daten zählen. Es ist außerdem vergleichsweise kompakt und menschenlesbar, was eine Balance schuf, die es mit der Verbreitung von Web-APIs zur natürlichen Standardwahl machte und XML bei neuen API-Designs weitgehend verdrängte, obwohl XML zuerst da war.
Was kann XML, was JSON strukturell nicht kann?
XML unterstützt Attribute an Elementen (Metadaten, die an einem Tag selbst hängen, unabhängig von dessen Inhalt), Namensräume (zur Vermeidung von Namenskonflikten beim Kombinieren von Vokabularen aus verschiedenen Quellen) und ein ausgereiftes, formales Schema-Validierungsökosystem (XSD) zur rigorosen Definition und Durchsetzung dessen, was ein gültiges Dokument genau enthalten muss – Fähigkeiten, die das einfachere Objekt-/Array-Modell von JSON nicht nativ bietet (JSON Schema existiert, kam aber später und ist weniger universell verbreitet). Deshalb hält sich XML in Bereichen, die strenge Dokumentvalidierung, Dokumente mit gemischten Vokabularen oder lange etablierte Unternehmens- und Behördendatenstandards erfordern, die älter sind als der Aufstieg von JSON.
Warum erfordert die Umwandlung von CSV in ein verschachteltes Format wie JSON mehr als eine mechanische Konvertierung?
CSV kennt kein Konzept der Verschachtelung – jede Zeile ist flach –, sodass die Umwandlung von CSV-Daten in ein Format, das Hierarchie unterstützt (wie JSON, das etwa eine Bestellung mit mehreren Positionen darstellt), eine echte Entscheidung darüber erfordert, wie die flachen Zeilen auf eine verschachtelte Struktur abgebildet werden: Wird jede Zeile ein separates Top-Level-Objekt, oder werden mehrere Zeilen mit derselben ID zu einem Objekt mit einem verschachtelten Array gruppiert? Diese Abbildungsentscheidung lässt sich nicht allein aus den CSV-Daten ableiten – sie hängt vom Verständnis der realen Beziehungen der Daten ab, weshalb „konvertiere einfach meine CSV in JSON" manchmal ein technisch gültiges, aber praktisch unbrauchbares Ergebnis liefert, wenn die Struktur nicht spezifiziert wurde.
Unterscheiden sich Dateigröße oder Parsing-Geschwindigkeit zwischen den drei Formaten spürbar?
CSV ist bei wirklich flachen, einheitlichen Daten im Allgemeinen am kompaktesten, da es kaum strukturellen Overhead hat – keine wiederholten Tag-Namen oder Schlüsselnamen pro Datensatz. JSON ist bei denselben verschachtelten Daten kompakter als XML, da es die redundanten schließenden Tags von XML nicht hat, enthält aber mehr Overhead als CSV durch wiederholte Schlüsselnamen in jedem Objekt, sofern keine kompaktere array-basierte Kodierung verwendet wird. XML ist bei gleichwertigen Daten typischerweise das größte der drei Formate aufgrund ausführlicher öffnender und schließender Tags, obwohl dies selten der entscheidende Faktor ist im Vergleich dazu, welche strukturellen Fähigkeiten und welches Tooling-Ökosystem eine bestimmte Integration tatsächlich benötigt.