Warum CSV-Exporte aus Tabellenkalkulationen beim Konvertieren kaputtgehen
Ein CSV-Export wirkt wie simple, offensichtlich strukturierte Daten. Doch sobald eine echte Adresse, eine führende Null oder ein eingebetteter Zeilenumbruch auftaucht, entpuppt sich diese Einfachheit als Illusion.
· 3 Min. Lesezeit
Warum CSV trivial wirkt – und es nicht ist
Eine CSV-Datei wirkt so simpel, wie ein Datenformat nur sein kann – jede Zeile an Kommas aufteilen, die erste Zeile als Spaltenüberschriften behandeln, fertig –, und genau diese scheinbare Einfachheit macht das Format so leicht angreifbar, sobald reale Daten ins Spiel kommen. Der naive Ansatz, einfach an Kommas zu trennen, funktioniert bei einem Spielzeugbeispiel einwandfrei und scheitert an der allerersten Zeile, in der ein echter Datenwert zufällig selbst ein Komma enthält – was ein ganz normaler Fall ist, kein Ausnahmefall: Eine Adresse wie „Hauptstraße 123, 2. OG", ein Firmenname wie „Müller, Schmidt & Co." oder eine Produktbeschreibung mit einer Aufzählung sind alles völlig gewöhnliche Werte, die legitim genau das Zeichen enthalten, das ein naiver Parser als Feldtrenner benutzt.
Wie CSV Kommas innerhalb eines echten Werts wirklich behandelt – und wie naive Tools das falsch machen
Die CSV-Spezifikation löst das Problem eingebetteter Kommas, indem sie erlaubt, ein Feld in doppelte Anführungszeichen zu setzen – innerhalb derer Kommas und sogar Zeilenumbrüche schlicht literale Daten sind, keine Struktur. Ein korrekt in Anführungszeichen gesetztes Feld wie `„Müller, Schmidt & Co."` wird als ein einziger Wert mit einem enthaltenen Komma verstanden, nicht als zwei an diesem Komma getrennte Werte. Ein Parser, der naiv bei jedem Komma trennt, ohne zu verfolgen, ob er sich gerade innerhalb eines in Anführungszeichen gesetzten Felds befindet, kann diese Unterscheidung nicht treffen und teilt diesen einen Firmennamen still in zwei überflüssige Spalten auf – meist ohne irgendeinen Fehler auszugeben, was diese Fehlerklasse gerade so gefährlich macht: Die Konvertierung wirkt erfolgreich, und die Beschädigung fällt erst später auf, oft lange nachdem die fehlerhaften Daten bereits irgendwo verwendet wurden.
Eingebettete Zeilenumbrüche innerhalb einer einzelnen Zelle
Eine Tabellenzelle mit einer mehrzeiligen Notiz oder Adresse ist völlig normal, und wenn diese Zelle als CSV exportiert wird, behandelt die Spezifikation sie genauso wie ein eingebettetes Komma: Das gesamte Feld wird in Anführungszeichen gesetzt, und der darin enthaltene Zeilenumbruch ist wirklich Teil der Felddaten, kein Signal für den Beginn einer neuen Zeile. Ein Parser, der davon ausgeht, dass jeder Zeilenumbruch in der Datei den Beginn eines neuen Datensatzes markiert, ohne zu verfolgen, ob er sich gerade innerhalb eines offenen, in Anführungszeichen gesetzten Felds befindet, teilt diese eine mehrzeilige Zelle in scheinbar mehrere separate Zeilen auf – und beschädigt damit still die Zeilenstruktur von allem, was in der Datei danach folgt, da jede nachfolgende Zeile nun um so viele überflüssige zusätzliche Zeilen verschoben ist, wie die kaputte Zelle eingeführt hat.
Typ-Mehrdeutigkeit: führende Nullen, Telefonnummern und Zahlen, die eigentlich keine sind
Jeder einzelne Wert in einer rohen CSV-Datei wird als reiner Text gespeichert, ohne eingebaute Möglichkeit anzuzeigen, ob ein bestimmter Wert „wirklich" eine Zahl, ein Boolean oder einfach eine Zeichenkette ist, die zufällig numerisch aussieht – und genau das wird zum echten Problem, sobald ein Konverter hilfreich sein und Typen automatisch erkennen will. Eine Postleitzahl wie „007" oder eine ID wie „042" hat eine führende Null, die semantisch bedeutsam ist – es handelt sich um einen Bezeichner fester Breite, und „7" und „007" sind unterschiedliche Bezeichner, auch wenn sie dieselbe Zahl darstellen –, doch ein Konverter, der numerisch aussehende Zeichenketten eifrig in echte Zahlen umwandelt, verwirft diese führende Null still, denn die Zahl 7 hat kein Konzept davon, wie viele Nullen ihr einmal vorangingen. Eine Telefonnummer wie „+49 30 1234567" sieht teilweise numerisch aus, ist aber überhaupt keine arithmetische Größe, und sie in eine Zahl umzuwandeln erzeugt etwas wirklich Sinnloses. Die sichere, korrekte Grundeinstellung ist, mehrdeutige Werte als Text zu belassen, solange ein Wert nicht eindeutig und sicher numerisch ist, denn eine falsche Vermutung beschädigt hier Daten still, statt einen sichtbaren, erkennbaren Fehler auszulösen.
Warum ausgerechnet Excel eine zweite, unabhängige Fehlerquelle hinzufügt
Über die echten Grenzfälle des CSV-Formats selbst hinaus bringt Microsoft Excel zusätzliche Reibung mit ins Spiel, die mit der CSV-Spezifikation selbst gar nichts zu tun hat: Viele europäische und andere regionale Excel-Konfigurationen verwenden standardmäßig ein Semikolon statt eines Kommas als Feldtrenner, da das Komma in diesen Regionen bereits als Dezimaltrennzeichen dient – was bedeutet, dass eine aus einer solchen Excel-Konfiguration exportierte CSV-Datei mit einem kommagetrennten Parser gar nicht korrekt eingelesen wird. Excel hat außerdem die bekannte Angewohnheit, Werte, die es zu erkennen glaubt, beim Öffnen einer CSV-Datei automatisch neu zu formatieren – etwa eine lange numerische ID in wissenschaftliche Notation umzuwandeln –, was eine Fehlinterpretation von Excel beim Anzeigen ist und kein Fehler in der zugrunde liegenden CSV-Datei, aber regelmäßig für eine tatsächliche Datenbeschädigung im Export selbst gehalten wird.