CSV zu JSON

CSV wirkt trivial zu analysieren — jede Zeile nach Kommas teilen, die erste Zeile als Kopfzeilen behandeln — bis ein Wert in echten Daten sein eigenes Komma enthält, was bei echten Tabellenkalkulations-Exporten ständig vorkommt: eine Adresse wie „Hauptstraße 123, Wohnung 4", ein Firmenname wie „Schmidt, Meyer & Co", oder eine Produktbeschreibung mit einer Liste. Die CSV-Spezifikation, formalisiert als RFC 4180, behandelt das, indem ein Feld in doppelte Anführungszeichen eingeschlossen werden kann, innerhalb derer Kommas, Zeilenumbrüche und sogar literale Anführungszeichen (escaped durch Verdopplung) einfach Daten statt Struktur sind. Ein Parser, der naiv jedes Komma teilt und Anführungszeichen völlig ignoriert, beschädigt genau diese Zeilen — teilt „Schmidt, Meyer & Co" in zwei separate Spalten — und tut das normalerweise still, ohne jeden Fehler, der signalisiert, dass etwas schiefging, was diesen Fehler gefährlich statt nur ärgerlich macht.

Die korrekt anführungszeichenbewusste Analyse verfolgt, ob der Leser sich gerade innerhalb eines Feldes in Anführungszeichen befindet, und ignoriert Trennzeichen und Zeilenumbrüche, bis das schließende Anführungszeichen erreicht ist, was der einzige Weg ist, Felder korrekt zu rekonstruieren, die legitim die Zeichen enthalten, die sonst mit Struktur verwechselt würden.

Jeder Wert in einer rohen CSV-Datei ist Text, da CSV kein natives Konzept von Zahl, Boolean, oder Nullwert hat — eine Zelle mit `42` und eine Zelle mit „hallo" werden identisch als Zeichen gespeichert. Typinferenz ist der Prozess zu erraten, welche Zeichenketten „wirklich" als Zahlen, Wahr/Falsch-Werte oder Nullwerte gedacht waren, und sie entsprechend zu konvertieren, damit das resultierende JSON echt typisierte Werte hat statt dass alles wie eine Zeichenkette in Anführungszeichen eingeschlossen ist.

Die Vermutung muss jedoch konservativ sein, weil ziemlich viele numerisch aussehende Werte überhaupt nicht als Zahlen behandelt werden sollen. Eine führende Null — `007`, `042` — signalisiert normalerweise einen Bezeichner oder aufgefüllten Code, bei dem die führende Null bedeutsam ist und beim Konvertieren zu einer Zahl still zerstört würde, da `7` und `007` dieselbe Zahl, aber sehr unterschiedliche Bezeichner sind. Eine Telefonnummer wie `+44 20 7946 0958` sieht teilweise numerisch aus, ist aber keine arithmetischen Daten. Werte jenseits des sicheren Ganzzahlbereichs von JavaScript verlieren an Präzision, wenn sie überhaupt zu einer Zahl konvertiert werden. Dieses Tool lässt all das speziell als Zeichenketten, weil hier falsch zu raten bedeutet, still Daten auf eine Weise zu beschädigen, die leicht bis viel später zu übersehen ist.

Ein JSON-Objekt kann nicht zwei Schlüssel mit demselben Namen haben — der zweite gefundene überschreibt einfach den ersten, wobei still der Wert einer ganzen Spalte verworfen wird, ohne dass irgendwo ein Fehler auftritt. Tabellenkalkulations-Exporte erzeugen häufiger doppelte Überschriften, als es wahrscheinlich scheint: ein Bericht mit zwei „Gesamt"-Spalten unterschiedlichen Umfangs, oder ein aus zwei Quellen zusammengeführter Export, die beide zufällig „Name" verwenden. Duplikate zu erkennen und das zweite Vorkommen zu `name_2` umzubenennen bewahrt die Daten jeder Spalte, statt still zu verlieren, welche auch immer zuerst im Zeilenobjekt erscheint. Leere Überschriften erhalten aus demselben Grund dieselbe Behandlung, da JSON keine Möglichkeit hat, einen Schlüssel darzustellen, der einfach eine leere Zeichenkette als bedeutsames, adressierbares Feld ist.