JSON vs. CSV: Welches Format sollten Sie verwenden?

Warum wir dies schreiben: Wir sind Geonode und verkaufen Proxys an Personen, die Daten sammeln. Daher beobachten wir oft, wie viele gescrapte Datensätze im falschen Format auf die Festplatte geschrieben werden. Der Haftungsausschluss ist einfach: Die Wahl des Formats hat nichts mit Proxys zu tun, und wir verdienen kein Geld an Ihrer Entscheidung in dieser Frage. Was davon jedoch betroffen ist, sind Ihre Speicherkosten, Ihre Verarbeitungszeit und wie viel Zeit Sie in der Woche damit verbringen, zu debuggen, warum ein Feld, das ein Komma enthält, einen nachgelagerten Import zum Scheitern gebracht hat. Das sind echte Kosten, und Sie haben sie vollständig im Griff, bevor Sie den ersten Datensatz schreiben.

Der grundlegende Unterschied: Das eine ist ein Standard, das andere eine Gewohnheit

Das muss man als Erstes verstehen, denn alles andere ergibt sich daraus.

JSON ist standardisiert. RFC 8259 ist ein Dokument im Internet-Standards-Track. Es verfügt über eine formale Grammatik, verbindliche Anforderungen und dient ausdrücklich dazu, „Inkonsistenzen mit anderen JSON-Spezifikationen“ zu beseitigen und „Spezifikationsfehler“ zu beheben. Wenn zwei JSON-Parser zu unterschiedlichen Ergebnissen kommen, ist mindestens einer von ihnen falsch, und die Spezifikation gibt an, welcher.

CSV ist es nicht. RFC 4180 ist ein Informationsdokument, und das sagt es selbst in aller Deutlichkeit:

Zwar gibt es verschiedene Spezifikationen und Implementierungen für das CSV-Format … doch existiert keine formale Spezifikation, was eine Vielzahl von Interpretationen von CSV-Dateien zulässt. Dieser Abschnitt dokumentiert das Format, das offenbar von den meisten Implementierungen befolgt wird.

„Offenbar von den meisten Implementierungen befolgt“ hat in diesem Satz eine große Bedeutung. RFC 4180 ist eine Beschreibung gängiger Praxis, keine Definition. Wenn zwei CSV-Parser unterschiedliche Ergebnisse liefern, können beide Recht haben.

Deshalb haben CSV-Probleme den Charakter, den sie haben. Es handelt sich weniger um Fehler als vielmehr um berechtigte Meinungsverschiedenheiten über ein Format, das niemand jemals vollständig definiert hat – was auch der Grund dafür ist, dass sie an Integrationsgrenzen zutage treten, Monate nachdem die Datei erstellt wurde, und zwar in den Tools anderer.

Was CSV tatsächlich garantiert

RFC 4180 dokumentiert die gängigen Konventionen, und es lohnt sich, diese zu kennen, da Abweichungen davon oft zu Problemen führen.

Die Datensätze werden durch CRLF getrennt. Der letzte Datensatz kann einen abschließenden Zeilenumbruch haben oder auch nicht. Es kann eine optionale Kopfzeile vorhanden sein. Felder werden durch Kommas getrennt, jede Zeile sollte die gleiche Anzahl an Feldern enthalten, und „Leerzeichen gelten als Teil eines Feldes und sollten nicht ignoriert werden.“

Bei der Anführungszeichen-Verwendung wird es interessant:

Jedes Feld kann in doppelte Anführungszeichen gesetzt werden oder auch nicht (allerdings verwenden einige Programme, wie beispielsweise Microsoft Excel, überhaupt keine doppelten Anführungszeichen).

Und Felder, „die Zeilenumbrüche (CRLF), doppelte Anführungszeichen und Kommas enthalten, sollten in doppelte Anführungszeichen gesetzt werden“, wobei ein eingebettetes doppeltes Anführungszeichen „durch ein vorangestelltes weiteres doppeltes Anführungszeichen“ maskiert wird.

Beachten Sie die Modalverben. „Kann, muss aber nicht.“ „Sollte.“ Der RFC beschreibt Tendenzen. Und der Einschub zu Excel ist das Eingeständnis des Dokuments aus dem Jahr 2005, dass das weltweit am häufigsten verwendete CSV-Tool dieser Konvention nicht folgt.

Die praktischen Konsequenzen, in der Reihenfolge, in der sie sich negativ auswirken werden:

Trennzeichen variieren je nach Ländereinstellung. Länder, die ein Komma als Dezimaltrennzeichen verwenden, nutzen üblicherweise ein Semikolon als Feldtrennzeichen. Eine von einem Kollegen in Deutschland exportierte Datei lässt sich möglicherweise nicht mit einem auf Kommas basierenden Leseprogramm auswerten, und keiner von euch hat dabei etwas falsch gemacht.

**Die Kodierung ist nicht deklariert.**In einer CSV-Datei wird die Zeichenkodierung nirgends angegeben. UTF-8, Latin-1, Windows-1252 und UTF-16 erzeugen alle eine Datei, die wie CSV aussieht, aber bei einem falschen Parser als „Mojibake“ angezeigt wird. Byte-Order-Marker erscheinen inkonsistent und stören die einfache Auswertung der Kopfzeilen.

Zeilenenden variieren. CRLF, LF und – in Feldern mit eingebetteten Zeilenumbrüchen – beides innerhalb von Anführungszeichen.

Datentypen gibt es nicht. Alles ist Text. Aus „007“ wird „7“, „2026-09-02“ wird in einem Tool zu einem Datum und in einem anderen zu einer Zeichenkette, und ein vorangestelltes „+“ verschwindet. Der Rundlauf einer CSV-Datei durch eine Tabellenkalkulation ist mit echten Datenverlusten verbunden.

Und CSV-Dateien können Code ausführen. Ein Feld, das mit =, +, - oder @ beginnt, kann von Tabellenkalkulationssoftware als Formel interpretiert werden. Dies ist eine sogenannte „Formula Injection“ – eine echte Sicherheitslücke, wenn Sie vom Benutzer bereitgestellte Daten in eine CSV-Datei schreiben, die jemand in Excel öffnet. Abhilfe schafft es, solchen Feldern ein einfaches Anführungszeichen voranzustellen oder sie auf andere Weise vor dem Speichern zu neutralisieren. Wenn Ihre Pipeline CSV-Dateien aus gescrapten oder von Benutzern übermittelten Inhalten erstellt, lohnt es sich, dies bewusst zu berücksichtigen.

Was JSON garantiert und wo es noch Probleme bereitet

Die JSON-Spezifikation ist strenger, und die Garantien sind entsprechend stärker.

Die Kodierung ist festgelegt. RFC 8259 §8.1: „JSON-Text, der zwischen Systemen ausgetauscht wird, die nicht Teil eines geschlossenen Ökosystems sind, MUSS mit UTF-8 kodiert sein.“ Darin heißt es außerdem, dass Implementierungen „keine Byte-Order-Markierung“ zu vernetztem JSON-Text hinzufügen „dürfen“, während Parser diese ignorieren dürfen. Die gesamte Klasse von Problemen bei der Erkennung der Kodierung, die CSV plagt, existiert hier schlichtweg nicht.

Es gibt Datentypen. Zeichenketten, Zahlen, Boolesche Werte, Null, Objekte und Arrays sind in der Grammatik unterscheidbar. "007" und 7 sind unterschiedliche Werte und bleiben unterschiedlich.

Verschachtelung ist nativ. Hierarchische Daten haben eine eindeutige Darstellung, anstatt einer Konvention zu bedürfen, auf die sich niemand geeinigt hat.

Zwei Punkte, in denen JSON weniger absolut ist, als man annimmt:

Doppelte Schlüssel werden lediglich nicht empfohlen. Die Spezifikation besagt: „Die Namen innerhalb eines Objekts SOLLTEN eindeutig sein“ – SOLLTEN, nicht MÜSSEN. Und sie ist offen hinsichtlich der Konsequenz: Wenn Namen nicht eindeutig sind, „ist das Verhalten von Software, die ein solches Objekt empfängt, unvorhersehbar. Viele Implementierungen geben nur das letzte Name-Wert-Paar zurück. Andere Implementierungen melden einen Fehler oder können das Objekt nicht parsen.“

Die Zahlenpräzision ist eine Empfehlung, keine Regel. Die Spezifikation erlaubt es Implementierungen, Grenzen für Bereich und Präzision festzulegen, und stellt fest, dass gute Interoperabilität dadurch erreicht wird, dass man nicht mehr erwartet, als IEEE 754 binary64 bietet. Der Fehlerfall wird direkt benannt: „Eine JSON-Zahl wie 1E400 oder 3,141592653589793238462643383279 kann auf potenzielle Interoperabilitätsprobleme hinweisen.“

In der Praxis handelt es sich hierbei um einen stillen Fehler, der oft unbemerkt bleibt. Große 64-Bit-Identifikatoren verlieren an Genauigkeit, wenn sie in JavaScript-Zahlen geparst werden; es wird kein Fehler ausgelöst, und zwei unterschiedliche Datensätze können denselben Wert annehmen. Die Standardmaßnahme zur Abhilfe besteht darin, große Ganzzahlen als Zeichenketten zu serialisieren – was bereits beim Schreiben der Daten sinnvoll ist, anstatt das Problem erst später zu entdecken. Auf die Parser-Seite dieses Themas sind wir in unserem Leitfaden zu JSON.parse eingegangen.

Größe und Geschwindigkeit

Der Kompromiss ist real, und die Tendenz verläuft nicht immer so, wie man es erwarten würde.

CSV ist bei flachen tabellarischen Daten kleiner, in der Regel um ein Vielfaches, da Feldnamen nur einmal in der Kopfzeile und nicht in jedem Datensatz vorkommen. Bei einer Million Zeilen mit jeweils fünf Feldern werden im CSV-Format fünf Feldnamen gespeichert, im JSON-Format hingegen fünf Millionen.

Durch Komprimierung verringert sich der Unterschied drastisch. Wiederholte Schlüssel lassen sich extrem gut komprimieren. Nach der gzip-Komprimierung sinkt der JSON-Leistungsaufwand bei einheitlichen Datensätzen oft auf ein überschaubares Maß – gelegentlich sogar auf null. Wenn Sie komprimierte Daten speichern – was Sie tun sollten –, ist das Größenargument für CSV viel schwächer, als die reinen Zahlen vermuten lassen.

CSV lässt sich in einfachen Fällen schneller parsen und in korrekten Fällen langsamer. Ein naiver „split(',')“ ist sehr schnell und falsch. Ein konformer Parser, der Anführungszeichen, eingebettete Zeilenumbrüche und escaped Anführungszeichen korrekt verarbeitet, liegt hinsichtlich des Aufwands näher am JSON-Parsing. Die meisten CSV-Geschwindigkeitsvergleiche vergleichen stillschweigend einen falschen Parser mit einem richtigen.

Der tatsächliche Aufwand bei JSON liegt im Speicher, nicht in der CPU. Ein einzelnes großes JSON-Dokument muss zum Parsen in der Regel im Speicher gehalten werden. Ein CSV-Dokument kann zeilenweise aus einem Stream mit konstantem Speicherbedarf verarbeitet werden. Bei einer Datei von zehn Gigabyte ist dieser Unterschied kein Leistungsdetail; er ist der Unterschied zwischen möglich und unmöglich auf einem bestimmten Rechner.

Genau dieses Problem löst der nächste Abschnitt.

Der Mittelweg: JSON Lines

JSON Lines – auch NDJSON oder „newline-delimited JSON“ genannt – besteht aus einem JSON-Dokument pro Zeile ohne umschließendes Array. Es ist das Format, das die meisten Menschen verwenden sollten, das aber vergleichsweise wenigen bekannt ist.

{"id": 1, "name": "Ada", "tags": ["engineer"]}
{"id": 2, "name": "Grace", "tags": ["engineer", "admiral"]}

Was es Ihnen bietet:

Streaming. Jede Zeile wird unabhängig analysiert, sodass Sie eine Datei von hundert Gigabyte in konstantem Speicher verarbeiten können. Damit wird der größte praktische Nachteil von JSON beseitigt.

Schreiben nur am Ende. Neue Datensätze werden am Ende angehängt. Es gibt kein umschließendes Array, das geschlossen werden muss, was bedeutet, dass die Datei nicht neu geschrieben werden muss und keine fehlerhafte Ausgabe entsteht, wenn ein Prozess während des Schreibvorgangs abstürzt.

Teilweise Wiederherstellung. Eine unvollständige Datei liefert immer noch jede vollständige Zeile. Ein unvollständiges JSON-Array liefert gar nichts – eine fehlende Klammer und das gesamte Dokument ist nicht mehr auswertbar. Allein schon dafür lohnt sich die Wahl bei allem, was von einem lang laufenden Job geschrieben wird.

Triviale Parallelität. Aufteilung nach Zeilen und unabhängige Verarbeitung der Shards. Kein zeilenübergreifender Status.

Volle JSON-Semantik. Typen, Verschachtelung und eindeutige Kodierung bleiben vollständig erhalten.

Die Nachteile sind überschaubar und gering: Die Dateien sind etwas größer als CSV-Dateien, lassen sich nicht direkt in einer Tabellenkalkulation öffnen, und jeder Datensatz enthält seine eigenen Schlüssel. Für gescrapte Daten, Protokollausgaben, Ereignisströme und alles, was inkrementell angehängt wird, ist dies die richtige Standardwahl – und genau das würden wir jedem empfehlen, der Sammelausgaben auf die Festplatte schreibt.

Jenseits von beidem: Parquet und Co.

Das sollte man wissen, denn bei analytischen Workloads ist die Frage „JSON oder CSV?“ manchmal völlig falsch gestellt.

Parquet ist spaltenorientiert und binär. Es speichert jede Spalte zusammenhängend, was bedeutet, dass eine Abfrage, die drei Spalten mit jeweils vierzig Einträgen betrifft, nur diese drei liest. Es verfügt über ein Schema, lässt sich weitaus besser komprimieren als zeilenorientierter Text, da ähnliche Werte nebeneinander liegen, und bewahrt die Datentypen exakt bei.

Seine Stärken: analytische Abfragen über große Datensätze, die Langzeitspeicherung umfangreicher Datenmengen und jede Pipeline, die ein Data Warehouse speist. Die Komprimierungsverhältnisse gegenüber CSV sind häufig um ein Vielfaches höher, und die Unterschiede in der Abfrageleistung sind noch größer.

Wo es Schwächen hat: Es ist nicht menschenlesbar, lässt sich nicht wie JSON Lines nachträglich ergänzen und erfordert eine Bibliothek statt eines Texteditors. Für Streaming, den Austausch mit Menschen und für kleine Datenmengen sind Textformate nach wie vor die richtige Wahl.

Eine gängige und sinnvolle Architektur: Erfassung im JSON-Lines-Format, da dieses nachschreibbar und fehlertolerant ist, anschließend batchweise Konvertierung in Parquet zur Analyse und Archivierung. Jedes Format wird dort eingesetzt, wo seine Eigenschaften von Vorteil sind.

Auswahl nach Anwendungsfall

Drei Regeln, die die meisten Fälle lösen, ohne dass die Tabelle benötigt wird.

Wenn die Daten flach und einheitlich sind und in eine Tabellenkalkulation oder einen Massenlader gelangen sollen, verwenden Sie CSV. Das sind die echten Stärken von CSV, und nichts anderes bietet sie so bequem. Insbesondere der Massenimport in Datenbanken ist ein echter Vorteil – die meisten Datenbanken verfügen über einen schnellen Importweg für CSV, nicht jedoch für JSON.

Wenn die Daten verschachtelt oder variabel strukturiert sind oder vom Benutzer eingegebene Inhalte enthalten, verwenden Sie JSON oder JSON Lines. Das Abflachen verschachtelter Daten in CSV erfordert die Einführung einer Konvention, und jede dafür erfundene Konvention war bisher eine Quelle für Fehler. Außerdem enthält Benutzereingabe Kommas, Anführungszeichen und Zeilenumbrüche – genau das, was CSV am wenigsten zuverlässig verarbeitet.

Wenn Sie fortlaufend Datensätze schreiben, verwenden Sie JSON Lines. Nicht CSV, da CSV keine Datentypen kennt und diese dadurch verloren gehen. Auch kein JSON-Array, da dieses nicht sicher angehängt werden kann und ein abgestürzter Prozess eine nicht mehr auswertbare Datei hinterlässt.

Häufig gestellte Fragen

Ist JSON besser als CSV?

Je nach Anwendungsfall: ja und nein. JSON ist ein formaler Standard mit Datentypen, Verschachtelung und obligatorischer UTF-8-Kodierung. CSV ist bei flachen tabellarischen Daten kompakter, lässt sich nahtlos streamen und in Tabellenkalkulationsprogrammen öffnen. Das gewichtigere Argument ist, dass CSV keine formale Spezifikation hat – RFC 4180 besagt dies ausdrücklich –, was es über verschiedene Tools hinweg weniger vorhersehbar macht.

Warum funktioniert meine CSV-Datei in Excel nicht richtig?

Meistens liegt es an der Kodierung oder dem Trennzeichen. CSV-Dateien geben ihre Zeichenkodierung nicht an, daher muss Excel raten, und Ländereinstellungen, die ein Komma als Dezimaltrennzeichen verwenden, erwarten ein Semikolon als Trennzeichen. Beide Probleme sind einem Format inhärent, das beides nie festgelegt hat. Der Export als UTF-8 mit BOM hilft oft speziell bei Excel, führt jedoch dazu, dass andere Parser verwirrt werden.

Was ist „JSON Lines“ und wann sollte ich es verwenden?

Ein JSON-Dokument pro Zeile ohne umschließendes Array. Verwenden Sie es immer dann, wenn Sie Datensätze schrittweise schreiben – beispielsweise bei gescrapten Daten, Protokollen oder Ereignisströmen. Es wird im Arbeitsspeicher gestreamt, lässt sich sicher anhängen, übersteht eine Kürzung, wobei jede vollständige Zeile intakt bleibt, und behält vollständige JSON-Typen und Verschachtelungen bei.

Ist CSV kleiner als JSON?

Unkomprimiert und bei flachen, einheitlichen Daten in der Regel deutlich kleiner, da Feldnamen nur einmal und nicht pro Datensatz vorkommen. Nach der Komprimierung verringert sich der Unterschied stark, da sich wiederholende Schlüssel sehr gut komprimieren lassen. Wenn Sie komprimierte Daten speichern, ist das Größenargument für CSV viel schwächer, als die reinen Zahlen vermuten lassen.

Kann CSV verschachtelte Daten verarbeiten?

Nicht von Haus aus. Jede Verschachtelung erfordert eine von Ihnen festgelegte Konvention – Abflachung mit durch Punkte getrennten Spaltennamen, JSON-Zeichenfolgen in Zellen oder mehrere miteinander verknüpfte Dateien. All diese Methoden funktionieren, bedeuten jedoch, dass Ihre CSV-Datei ohne Ihre spezifische Konvention für generische Tools nicht mehr lesbar ist – was ja gerade der Hauptgrund für die Verwendung von CSV ist.

Was lässt sich schneller parsen: JSON oder CSV?

In einfachen Fällen ist es CSV, aber der Vergleich ist oft unfair – ein schneller „split(',')“ ist kein korrekter CSV-Parser, und einer, der Anführungszeichen und eingebettete Zeilenumbrüche korrekt verarbeitet, liegt vom Aufwand her viel näher an JSON. Der wichtigere Unterschied ist der Speicherbedarf: CSV wird zeilenweise gestreamt, während ein JSON-Dokument in der Regel vollständig geladen werden muss, was durch „JSON Lines“ behoben wird.

Sind doppelte Schlüssel in JSON erlaubt?

Die Spezifikation besagt, dass Namen „einzigartig sein SOLLTEN“ statt „MÜSSEN“, daher sind sie technisch gesehen zulässig. Sie warnt jedoch auch davor, dass das Verhalten unvorhersehbar ist, wenn dies nicht der Fall ist – manche Parser behalten den letzten bei, manche geben einen Fehler aus, manche schlagen komplett fehl. Behandeln Sie Duplikate als Fehler in dem Programm, das das Dokument erzeugt hat.

Welches Format sollte ich für gescrapte Daten verwenden?

In den meisten Fällen JSON Lines. Gescrapte Datensätze sind häufig verschachtelt und variabel strukturiert, womit CSV schlecht zurechtkommt, und die Erfassung erfolgt inkrementell, womit JSON-Arrays schlecht zurechtkommen. Wenn die Daten wirklich flach sind und für eine Tabellenkalkulation oder einen Massenimport bestimmt sind, ist CSV in Ordnung – und wenn Sie CSV aus gescraptem Text erstellen, neutralisieren Sie Felder, die mit =, +, - oder @ beginnen, um das Einfügen von Formeln zu vermeiden.

Fazit

Der Aspekt, der diese Entscheidung leicht macht, ist nicht „strukturiert versus einfach“. Es ist vielmehr, dass eines dieser Formate über eine Spezifikation verfügt, während das andere eine Beschreibung gängiger Praktiken enthält. RFC 8259 legt fest, was JSON leisten muss; RFC 4180 beschreibt, wie CSV-Dateien üblicherweise funktionieren, und drückt dies in eigenen Worten aus.

Dieser Unterschied ist die Ursache für im Grunde jedes CSV-Problem – nicht deklarierte Kodierungen, lokalisierungsabhängige Trennzeichen, inkonsistente Anführungszeichen, Typen, die in Tabellenkalkulationsprogrammen stillschweigend verloren gehen, und Felder, die sich in Formeln verwandeln. Keines davon ist ein Fehler im Parser eines Anbieters. Es handelt sich um das vorhersehbare Ergebnis eines Formats, das nie vollständig definiert wurde.

Für die meisten Menschen, die Daten eher schreiben als lesen, ist „JSON Lines“ die Lösung – und wird viel zu selten genutzt. Es behält die Typen, die Verschachtelung und die festgelegte Kodierung von JSON bei und beseitigt gleichzeitig dessen einzige echte Schwäche: Es lässt sich per Stream verarbeiten, sicher anfügen und übersteht einen unvollständigen Schreibvorgang, wobei jeder vollständige Datensatz intakt bleibt. Behalten Sie CSV für die beiden Aufgaben, die es wirklich am besten erfüllt: die Übergabe einer flachen Tabelle an jemanden, der sie in einer Tabellenkalkulation öffnet, und das Massenladen einer Datenbank. Und wenn der Datensatz groß und analytisch ist, ist keines der beiden Textformate das richtige Endziel; konvertieren Sie ihn in ein spaltenorientiertes Format und lassen Sie jedes Format die Aufgabe erfüllen, für die es konzipiert ist.