CSV und JSON sind die beiden häufigsten Tabellendatenformate in moderner Software, und der zuverlässige Wechsel zwischen ihnen ist eine der häufigsten Datenentwicklungsaufgaben bei jedem Projekt. CSV ist die Verkehrssprache von Tabellenkalkulationen, Analyseexporten und Legacy-Systemen. JSON ist der Standard für Web-APIs, moderne Datenpipelines und Dokumentendatenbanken. In den folgenden Abschnitten werden die subtilen Randfälle erläutert, die unbedarfte Konverter zum Stolpern bringen, wann die einzelnen Formate ausgewählt werden sollten und wie die Ausgabe des Dateninspektors zu interpretieren ist, um Qualitätsprobleme zu erkennen, bevor sie in die Produktion gelangen.
Randfälle, die naive Konverter aus der Fassung bringen
Ein naiver CSV-Parser teilt jede Zeile anhand des Trennzeichens auf und nennt sie einen Tag, aber reale CSV-Dateien enthalten mehrere Randfälle, die diesen Ansatz zunichte machen. Felder in Anführungszeichen kommen am häufigsten vor: Eine Zelle wie „Smith, John“ enthält ein Komma, das Teil des Werts ist, und kein Feldtrennzeichen, und der Parser muss den Anführungszeichenstatus beim Durchlaufen der Zeile verfolgen. Eingebettete Zeilenumbrüche in Feldern in Anführungszeichen sind gemäß RFC 4180 zulässig, werden jedoch häufig falsch analysiert – eine CSV-Zeile kann sich über mehrere physische Zeilen erstrecken, wenn eine Zelle in Anführungszeichen umbrochen wird. Mit Escapezeichen versehene doppelte Anführungszeichen innerhalb von Feldern mit Anführungszeichen werden als zwei aufeinanderfolgende doppelte Anführungszeichen dargestellt („He said „hello“““), die in der Ausgabe zu einem einfachen Anführungszeichen zusammengefasst werden müssen. Unicode-BOMs (Byte-Order-Markierungen) erscheinen am Anfang von Dateien, die von Excel unter Windows gespeichert werden, und erzeugen unsichtbare Junk-Bytes im ersten Feldnamen, sofern sie nicht entfernt werden. Verschiedene Systeme verwenden unterschiedliche Zeilenenden (LF unter Unix, CRLF unter Windows, gelegentlich bloßes CR bei alten Mac-Dateien), und der Parser muss alle drei verarbeiten, um leere abschließende Zeilen zu vermeiden. Dieser Konverter behandelt jeden dieser Fälle korrekt. Wenn Sie jedoch Ihren eigenen Konverter schreiben, verwenden Sie keinen eigenen Parser – verwenden Sie eine gut getestete Bibliothek wie Papa Parse in JavaScript, ein CSV-Modul in Python oder ein gleichwertiges Element.
Wann sollte man sich für CSV vs. JSON entscheiden?
Die Formatwahl hängt eher vom Verbraucher und der Datenform als von der Quelle ab. Wählen Sie CSV, wenn die Daten im Wesentlichen tabellarisch sind (Zeilen homogener Datensätze), wenn der Verbraucher ein Tabellenkalkulationsprogramm (Excel, Google Sheets, Numbers), eine ältere ETL-Pipeline oder ein Analyst ist, der die Datei öffnet, um sie zu betrachten. CSV hat keinen strukturellen Zusatzaufwand und ist damit die kompakteste Darstellung tabellarischer Daten – ein Vorteil bei Dateien mit mehreren Gigabyte. Die Nachteile: CSV hat kein Typsystem (alles ist ein String), keine Unterstützung für verschachtelte Strukturen (hierarchische Daten müssen abgeflacht werden) und keine formale Möglichkeit, Nullen darzustellen (normalerweise leere Strings oder einen Sentinel wie „NULL“). Wählen Sie JSON, wenn Datensätze heterogen sind (unterschiedliche Form pro Datensatz), wenn Daten eine natürliche Verschachtelung aufweisen (Bestellungen mit Einzelposten, Benutzer mit Adressen) oder wenn der Verbraucher eine moderne API, eine JavaScript-Anwendung oder eine Dokumentdatenbank ist. JSON behält native Typen und Strukturen bei. Die Nachteile sind die Größe (JSON mit wiederholten Schlüsseln ist zwei- bis fünfmal größer als entsprechende CSV-Dateien) und die Analysekosten (JSON erfordert einen vollständigen Parser, während CSV-Dateien gestreamt werden können). JSONL ist der Nährboden für sehr große Datensätze, die von Natur aus hierarchisch sind – jede Zeile kann unabhängig analysiert werden, was echtes Streaming ermöglicht, ohne dass die gesamte Datei im Speicher gehalten werden muss.
Verwenden des Dateninspektors zum Erkennen von Problemen
Auf der Registerkarte „Dateninspektor“ werden Probleme mit der Datenqualität sichtbar gemacht, die sonst erst später auftauchen würden, wenn etwas kaputt geht. Das wichtigste Signal ist die Füllrate pro Spalte – der Prozentsatz der Zeilen, die in jeder Spalte einen Wert ungleich Null haben. Eine Spalte mit 100 % Füllung ist vollständig ausgefüllt; Bei einer Spalte mit 50 % Füllung ist die Hälfte der Zeilen leer. Dies kann korrekt sein (optionale Felder) oder auf eine Beschädigung der Upstream-Daten hinweisen. Überprüfen Sie stichprobenartig Spalten mit weniger als 80 % Füllung, bevor Sie die Daten an einen wichtigen Ort senden. Typinferenz meldet, ob eine Spalte konsistent numerisch, konsistent Zeichenfolgen oder gemischt ist. Spalten mit gemischten Typen sind normalerweise ein Fehler in der Quelle – typischerweise eine numerische Spalte mit einigen vereinzelten Texteinträgen, die in einem streng typisierten Downstream-Consumer zu Typfehlern führen. Die Anzahl der eindeutigen Werte erfasst doppelte Schlüssel: Wenn Ihre vermeintliche Primärschlüsselspalte weniger eindeutige Werte aufweist als die Gesamtzahl der Zeilen, weisen die Quelldaten Duplikate auf, die vor dem Import dedupliziert werden müssen. Mithilfe von Beispielwerten können Sie schnell überprüfen, ob die ersten paar Werte in jeder Spalte angemessen aussehen – Datumsangaben, die als Zeichenfolgen analysiert wurden, Zahlen mit noch angehängten Währungssymbolen oder nachgestellte Leerzeichen, die dazu führen, dass Zeichenfolgenübereinstimmungen fehlschlagen. Zusammen erfassen diese Diagnosen etwa 90 % der realen CSV/JSON-Datenqualitätsprobleme, bevor sie dieses Tool verlassen.