JSON vs. CSV

Form: eine Tabelle gegenüber einem Baum

Eine CSV-Datei ist eine Folge von Datensätzen, alle von gleicher Breite: Name, E-Mail, Betrag, wiederholt für jede Zeile. Eine Kopfzeile – Konvention, nicht Garantie – benennt die Spalten einmal für die ganze Datei. JSON-Datensätze tragen ihre Schlüssel stattdessen mit sich, jedes Objekt beschreibt sich selbst, und ein Objekt darf ein Array von Objekten halten, die wiederum Arrays halten. Diese Asymmetrie entscheidet die Formatwahl mehr als jede Feature-Liste.

Typen und Anführungszeichen: deklariert versus abgeleitet

In JSON ist der Typ eines Werts sichtbar: Anführungszeichen bedeuten String, nackte Ziffern bedeuten Zahl, und true, false und null sind exakte Tokens. In CSV behauptet die Datei nichts – 007 und 7 sind beides schlichter Zellentext, und jeder Konsument leitet die Typen nach seinen eigenen Regeln neu ab. RFC 4180 spezifiziert das Quoting immerhin präzise: Felder mit Kommas, doppelten Anführungszeichen oder Zeilenumbrüchen werden in doppelte Anführungszeichen gesetzt, und eingebettete Anführungszeichen werden verdoppelt. Dateien, die das auslassen, erzeugen die klassischen kaputten-Zeilen-Bugs, die jeder Data Engineer schon einmal debuggt hat.

Beim erneuten Ableiten der Typen korrumpieren Daten leise. Eine Postleitzahl 02134 wird zur Zahl 2134; 1.20 wird zu 1.2; eine lange Kontonummer wird zu 4.2E+12. JSON hat die spiegelbildliche Regel – Zahlen dürfen überhaupt keine führenden Nullen tragen, also muss eine Postleitzahl auch dort ein String sein –, aber wenigstens ist die Deklaration explizit statt einer Vermutung aus der Tabellenkalkulation von jemand anderem.

Excel, Massendaten und wo welches Format gewinnt

Das Excel-Verhalten verdient einen eigenen Absatz, weil es so viele Pipelines verbrennt. Excel öffnet CSV nativ, leitet aber beim Laden für jede Zelle den Typ nach dem Locale des Rechners neu ab: Führende Nullen verschwinden, ISO-Zeitstempel werden zu locale-abhängigen Daten verhunzt, und in weiten Teilen Europas regiert der Semikolon-Dialekt, weil das Komma Dezimaltrennzeichen ist. Beim Speichern schreibt Excel die Datei dann mit diesen Ableitungen dauerhaft neu. JSON passiert Excel nie, was allein schon ein Grund ist, warum Integrationen es bevorzugen.

Bei großen Datenmengen ist CSVs Flachheit ein Feature: Zeilen lassen sich einzeln mit konstantem Speicher parsen, weshalb Multi-Gigabyte-Exporte und spaltenorientierte Tools weiterhin zuerst CSV sprechen. JSON gewinnt überall dort, wo der Konsument ein Programm ist und die Struktur echt: API-Payloads, Konfiguration, verschachtelte Dokumente. Nach dem Konsumenten zu wählen statt nach der Mode erledigt die meisten Streitfragen in einem Satz.

Wann sich welches eignet – und wie sich die Konvertierung verhält

Nehmen Sie CSV, wenn das Ziel tabellarisch ist: Tabellenkalkulationen, Datenbank-Massenimporte, BI- und Data-Science-Tools. Nehmen Sie JSON, wenn die Struktur verschachtelt oder der Konsument Code ist. In echten Pipelines kippt die Empfehlung ständig: Eine API liefert JSON, ein Analyst will CSV, ein Anbieter schickt CSV, die ein Dienst einlesen muss – Konvertierung ist Routinepflege, kein Migrationsprojekt.

Konvertierung hat ehrliche Grenzen. JSON zu CSV muss abflachen: Ein Array von Objekten wird zu Zeilen, die Vereinigung ihrer Schlüssel wird zu Spalten, und jedes verschachtelte Array oder Objekt muss stringifiziert, zusammengefügt oder weggelassen werden. CSV zu JSON muss ableiten: Leere Zellen werden zu null oder leeren Strings, und zahlenähnliche Zellen werden zu Zahlen. Die Konverter dieser Site dokumentieren genau diese Regeln, statt still zu raten.