CSV zu JSON: Fallen, die Daten zerstören

CSV in JSON zu konvertieren wirkt wie die einfachste Aufgabe in der Datenverarbeitung: Zeilen rein, Objekte raus. Es ist gleichzeitig einer der zuverlässigsten Wege, einen Datensatz ohne eine einzige Fehlermeldung zu beschädigen. Die Beschädigung entsteht nie durch den Konvertierungsschritt selbst — sie entsteht durch zwei Fragen, die jeder Konverter beantworten muss, meist stillschweigend: wo endet dieses Feld, und welchen Typ hat dieser Wert.

CSV wirkt einfach. Ist es nicht.

JSON hat eine echte Grammatik (ECMA-404). CSV hat RFC 4180, das weniger eine Spezifikation als eine Beschreibung verbreiteten Verhaltens ist — und viele reale Dateien ignorieren selbst das. Die Regeln der RFC, die naiver Code falsch macht:

• Felder dürfen quotiert werden, und ein quotiertes Feld darf Kommas enthalten, sodass "Schmidt, Johann" ein Feld ist. Eine Zeile bei Kommas aufzuteilen ist falsch, sobald ein Feld quotiert ist.
• Anführungszeichen werden durch Verdopplung escaped: "5'10""" kodiert 5'10". Backslash-Escaping, das viele selbstgebaute Parser annehmen, ist nicht RFC 4180.
• Quotierte Felder dürfen Zeilenumbrüche enthalten. Eine mehrzeilige Adresse ist gültiges CSV, was bedeutet, dass man eine CSV-Datei nicht einmal zeilenweise lesen kann. Diese eine Regel ist, warum ein korrekter Parser zustandsbehaftet sein muss.

Dann kommt hinzu, was die RFC nicht abdeckt: Dateien, die mit Semikolons oder Tabulatoren „getrennt“ sind (europäische Gebietsschemata, wo das Komma das Dezimaltrennzeichen ist), eine UTF-8-Byte-Order-Mark, die drei unsichtbare Bytes still an den ersten Spaltennamen klebt (sodass Ihr Code nach id sucht, der Schlüssel aber tatsächlich id ist), und veraltete Kodierungen wie Windows-1252, die jeden Namen mit Umlaut zu Mojibake machen, wenn er als UTF-8 gelesen wird. Ein Konverter, der den Trenner nicht erkennt, das BOM nicht entfernt und die Kodierung nicht richtig bestimmt, beschädigt die Datei, bevor die Typbehandlung überhaupt beginnt.

Kopfzeilen-Erkennung

RFC 4180 macht die Kopfzeile optional, und nichts in der Datei sagt, ob sie vorhanden ist. Raten Sie in die eine Richtung falsch, wird Ihr erster Datensatz zu den Schlüsselnamen für alle anderen; raten Sie in die andere Richtung falsch, erhalten Sie Schlüssel wie field1. Gute Konverter nutzen eine Heuristik — eine erste Zeile aus lauter nicht-numerischen, nicht-wiederholenden Strings ist wahrscheinlich eine Kopfzeile — aber Heuristiken scheitern bei reinen Textdaten, daher lässt Sie jeder brauchbare Konverter die Annahme überschreiben. Achten Sie auch auf doppelte Kopfzeilen-Namen: JSON-Objektschlüssel müssen eindeutig sein, zwei amount-Spalten bedeuten also, dass eine still gewinnt oder umbenannt wird.

Das Typproblem: alles ist ein String

CSV kennt keine Typen. 42, TRUE und 2024-01-05 sind alle nur Zeichenfolgen, und der Konverter muss entscheiden, was daraus in JSON wird. Jede Wahl verliert etwas:

• Führende Nullen. Erkennt man 02134 als Zahl, wird aus der Postleitzahl 2134. Dasselbe gilt für Telefonnummern, Produktcodes und Bankleitzahlen: Kennungen, die numerisch aussehen, sind keine Zahlen.
• Große Ganzzahlen. JSONs Grammatik erlaubt Zahlen beliebiger Größe, aber JavaScript (und die meisten JSON-Parser) speichern sie als IEEE-754-Doubles, exakt nur bis 2⁵³ − 1. Eine 19-stellige Datenbank-ID oder eine kreditkartenlange Zahl wird still auf einen nahegelegenen Wert gerundet. IDs gehören in Strings.
• Booleans. Ist TRUE der JSON-Wert true oder der String, den jemand eingegeben hat? Was ist mit Yes, Y, 1? Es gibt keine richtige Antwort, nur eine dokumentierte.
• Daten. JSON hat überhaupt keinen Datumstyp, und 03/04/2024 ist der 4. März oder der 3. April, je nach Gebietsschema. Daten als Strings zu behalten ist die einzige sichere Standardeinstellung.
• Leere Felder. CSV kann null nicht von einem leeren String oder einem fehlenden Wert unterscheiden; JSON unterscheidet alle drei.

Excel verdient hier eine eigene Warnung, denn ein Großteil der CSV-Beschädigung passiert, bevor überhaupt ein Konverter die Datei sieht. Excel wendet beim Öffnen aggressive Typerkennung an: Führende Nullen werden entfernt, Ganzzahlen über 15 Stellen werden gerundet, und datumsähnliche Strings werden umgewandelt — bekanntermaßen auch menschliche Gennamen wie MARCH1 und SEPT2, die in Tausenden veröffentlichter Genetikstudien als Daten erschienen, bis die Gene 2020 offiziell umbenannt wurden. Wurde eine CSV jemals in Excel geöffnet und gespeichert, behandeln Sie jede numerisch wirkende Kennung darin als verdächtig.

Die konservative Regel: Lassen Sie den Konverter Typen für offensichtliche Messwerte erkennen, behalten Sie aber alles, was als Kennung fungiert — Postleitzahlen, IDs, Kontonummern — als String, und prüfen Sie das Ergebnis stichprobenartig, bevor Sie ihm vertrauen.

Flache Zeilen vs. verschachteltes JSON

Eine CSV-Zeile ist flach; ein JSON-Objekt muss es nicht sein. Soll das Ergebnis verschachtelt sein, muss die Verschachtelung in den Spaltennamen kodiert werden, und die De-facto-Konvention sind Pfad-Kopfzeilen: Eine Spalte namens user.address.city (Punktnotation) oder user[address][city] (Klammernotation) wird zu verschachtelten Objekten, und items[0].sku, items[1].sku zu einem Array von Objekten. Viele Konverter und Bibliotheken unterstützen diese Expansion; nichts davon ist standardisiert, sodass Punkte, die eigentlich Teil eines Spaltennamens sind (price.usd als flacher Schlüssel), falsch expandiert werden, sofern das Werkzeug die Expansion nicht abschaltbar macht. Wählen Sie eine Konvention, wenden Sie sie in beide Richtungen an, und dokumentieren Sie sie.

Zurück-Konvertieren: JSON nach CSV verliert mehr

Die umgekehrte Konvertierung ist verlustreicher. Ein einheitliches Array flacher Objekte bildet sich sauber auf eine Tabelle ab; alles andere erzwingt Entscheidungen. Verschachtelte Objekte werden zu Pfad-Spalten abgeflacht. Arrays sind schlimmer: Eine Bestellung mit drei Positionen explodiert entweder zu drei Zeilen (was die Bestellfelder dupliziert und die Zeilenzahl ändert) oder wird als JSON-String in einer CSV-Zelle serialisiert — technisch gültig, praktisch unlesbar in einer Tabellenkalkulation. Datensätze mit unterschiedlichen Schlüsseln vereinigen sich zu einer breiten, dünn besetzten Tabelle, in der null, leerer String und „Schlüssel fehlt“ alle in dieselbe leere Zelle fallen. Übersteht Ihr Datensatz CSV→JSON→CSV byteidentisch, war er wirklich tabellarisch; wenn nicht, zeigt der Unterschied genau, welche Struktur CSV nicht tragen kann. Das Zwischenergebnis-JSON in einem Formatierer zu prüfen, bevor Sie zurückkonvertieren, macht diese Verluste sichtbar statt still.

Wann JSONL einem JSON-Array überlegen ist

Eine konventionelle Konvertierung packt jedes Zeilenobjekt in ein großes JSON-Array — das heißt, ein Konsument muss die gesamte Datei parsen, bevor er den ersten Datensatz anfasst, und ein Produzent muss alles im Speicher halten, um die schließende Klammer zu schreiben. JSON Lines (JSONL/NDJSON) verzichtet auf das Array: ein vollständiges JSON-Objekt pro Zeile, durch Zeilenumbruch getrennt. Jede Zeile lässt sich unabhängig parsen, sodass das Format wie CSV streamt, angehängt und aufgeteilt werden kann und sich grepen lässt, während JSONs Typen und Verschachtelung erhalten bleiben. Es ist das native Massenformat für Werkzeuge wie BigQuery und Elasticsearch, und die richtige Wahl, sobald die Zeilenzahl groß oder unbegrenzt ist. Faustregel: JSON-Array für konfigurationsgroße Nutzlasten, die eine API auf einmal zurückgibt; JSONL für Datensätze.

Größe und Streaming

JSON wiederholt jeden Schlüsselnamen in jedem Datensatz, sodass die konvertierte Ausgabe typischerweise zwei- bis viermal so groß ist wie die Quell-CSV — bedenkenswert, bevor Sie einen mehrere Gigabyte großen Export konvertieren. Umgekehrt bedeutet CSVs Regel zu quotierten Zeilenumbrüchen, dass korrektes Streaming weiterhin einen zustandsbehafteten Parser braucht, keinen Zeilen-Splitter. Für Dateien bis in den Bereich mehrerer Dutzend Megabyte erledigt ein Browser-Konverter die gesamte Aufgabe lokal; darüber hinaus streamen Sie mit einer Bibliothek (Pythons csv-Modul, PapaParse und ihre Entsprechungen parsen alle inkrementell) und geben JSONL aus, damit keine Seite den Datensatz im Speicher halten muss. Und wandert die Daten in eine Konfigurationsdatei statt in eine Pipeline, ist JSON womöglich ohnehin nicht die Endstation — siehe unseren Vergleich von JSON und YAML für Konfigurationsdateien.

Kurzfassung: CSV mit einem echten Parser lesen, niemals mit einem Komma-Split; das BOM entfernen und Trenner sowie Kodierung bestätigen; Kennungen unabhängig davon, wie numerisch sie aussehen, als Strings behandeln; Datendateien niemals durch Excel schleusen; Verschachtelung mit einer dokumentierten Pfad-Konvention kodieren; und zu JSONL greifen, sobald die Daten nicht mehr bequem in den Speicher passen.