CSV-Regeln nach RFC 4180

Die Grammatik: Datensätze, Felder, CRLF

Die Grammatik von RFC 4180 passt in einen Absatz. Eine Datei besteht aus Datensätzen, jeder Datensatz eine Folge von Feldern, getrennt durch Kommas; Datensätze werden durch CRLF getrennt – die zwei Bytes 0x0D 0x0A, nicht das nackte LF Unix-typischer Werkzeuge – und der letzte Datensatz endet mit einem abschließenden CRLF oder eben nicht. Felder stehen in Anführungszeichen oder nicht: Quoting ist eine Frage der Umstände, kein Stil. Der ABNF-Abriss lautet file = [header CRLF] record *(CRLF record); record = field *(comma field) – beachten Sie die optionale Kopfzeile innerhalb der eckigen Klammern.

id,name,score
1,Ada,99
2,Grace,98

Datensatz 1: id=1, name=Ada,   score=99
Datensatz 2: id=2, name=Grace, score=98

(jeder Datensatz endet mit den zwei Bytes CRLF;
beim letzten dürfen sie regelkonform fehlen)

Quoting: Das doppelte Anführungszeichen ist das gesamte Escape-System

Ein Feld steht in doppelten Anführungszeichen, wenn es muss, und die einzige Möglichkeit, ein doppeltes Anführungszeichen in ein solches Feld zu bekommen, ist es zu verdoppeln – "" innerhalb eines Felds in Anführungszeichen steht für genau ein literales Anführungszeichen. Das ist der gesamte Escape-Mechanismus: keine Backslashes, keine benannten Entities, kein zweites Anführungszeichen. Einfache Anführungszeichen sind gewöhnliche Daten, und ein einzelnes Leerzeichen nach einem Komma gehört zum nächsten Feld – die Spezifikation sagt ausdrücklich, dass Leerzeichen erhalten bleiben und nicht abgeschnitten werden dürfen.

year,quote,note
1962,"she said ""look, no hands""","multi-word, no problem"

year   → 1962
quote  → she said "look, no hands"
note   → multi-word, no problem

Zeilenumbrüche und Kommas innerhalb von Feldern

Weil Felder in Anführungszeichen Zeilenumbrüche enthalten dürfen, ist eine CSV-Zeile nicht dasselbe wie ein Datensatz: Jedes naive Aufteilen an \n zerstört jede Datei mit mehrzeiligen Feldern – deshalb scheitern Adressblöcke, Notizspalten und JSON-in-CSV-Nutzdaten an naiven Importern. Ein konformer Parser ist eine kleine State Machine: Innerhalb der Anführungszeichen sind Kommas und Zeilenumbrüche Daten, außerhalb sind es Trennzeichen. Korrekt lässt sich das nicht allein mit split() schreiben.

Dieselbe State Machine entscheidet auch die Grenzfälle um das doppelte Anführungszeichen: ein Anführungszeichen mitten im Wert, ein nicht abgeschlossenes Anführungszeichen am Dateiende, verdoppelte Anführungszeichen ganz am Ende eines Felds. Genau für diese Fälle wurden die wenigen Regeln von RFC 4180 geschrieben, und genau an ihnen widersprechen sich handgeschriebene Parser – die Quelle der meisten Meldungen nach dem Muster „funktioniert in Excel, bricht im Importer“.

name,address
"Ada","12 St James Square,
London"
"Grace","1 Loop Rd"

Datensatz 1: Ada | 12 St James Square,
London
Datensatz 2: Grace | 1 Loop Rd

(das Komma in der Adresse gehört zu den Daten,
ebenso das CRLF innerhalb der Anführungszeichen)

CRLF, die optionale Kopfzeile und text/csv

Drei Details sind von der Spezifikation festgelegt und werden doch routinemäßig anders angenommen. Datensätze enden mit CRLF – auch wenn der letzte Datensatz darauf verzichten darf und jeder Parser, den Sie täglich benutzen, nacktes LF akzeptiert. Der erste Datensatz kann Spaltennamen enthalten, aber die Grammatik behandelt ihn als optional: Eine Kopfzeile ist eine Konvention, die das Format unterstützt, keine Struktur, die es verlangt – Werkzeuge müssen es also gesagt bekommen oder selbst raten, ob die erste Zeile Daten sind. Und der registrierte MIME-Typ ist text/csv – von RFC 4180 selbst registriert, wobei die Charset-Parameter dem Absender überlassen bleiben.

Eine weitere Grenze zieht der RFC deutlich: Das Trennzeichen ist das Komma. Semikolongetrennte Dateien sind eine Locale-Konvention von Tabellenkalkulationen – verbreitet, wo das Dezimalkomma Standard ist –, keine Variante, die der Standard anerkennt. Ein konformer Schreiber rät nie, und ein konformer Parser findet das Trennzeichen entweder selbst heraus oder bekommt es gesagt, aber die Datei selbst trägt keine Markierung dafür, welcher Konvention sie folgt.

Wo reale Dateien vom Standard abweichen

Reales CSV ist älter als der RFC; Abweichung ist also die Norm, nicht die Ausnahme. Fünf Abweichungen erklären fast jeden Vorfall der Art „diese CSV lässt sich nicht parsen“:

Gute Werkzeuge machen diese Abweichungen sichtbar, statt stillschweigend zu raten. Wenn eine Datei wichtig ist – Rechnungen, Finanzimporte, alles, was ein Prüfer lesen könnte –, gleichen Sie sie mit der obigen Grammatik ab und beheben Sie die Abweichung an der Quelle, statt jedem nachgelagerten Parser dieselbe Ausnahme beizubringen.

CSV schreiben, das Round-Trips übersteht

Die Checkliste des zuverlässigen Erzeugers folgt direkt aus der Grammatik: durchgängig quoten – jedes Feld, oder genau die Felder, die die Regeln verlangen; beides ist konform, aber einheitliches Quoting lässt sich beim erneuten Einlesen sicherer verarbeiten –, dazu CRLF ausgeben, die Kopfzeile schreiben und als UTF-8 kodieren – notfalls mit einem BOM, der manchmal der Preis dafür ist, dass eine Tabellenkalkulation die Datei erkennt. Prüfen Sie alles Wichtige im Round-Trip: Parsen Sie die Datei, die Sie gerade geschrieben haben, bestätigen Sie, dass jedes Feld den Quelldaten entspricht, und geben Sie sie erst dann weiter. Der wiederkehrende Fehler ist immer derselbe – ein Wert, der das Trennzeichen enthält und den der Schreiber nie gequoted hat.