CSV ist das gefährlichste Dateiformat in Ihrer Automatisierung

Eine CSV-Datei hat letztes Jahr 4.000 Postleitzahlen zerstört, und der Import lief grün durch

Ein Kunde im Versandhandel migrierte seine Kundenliste in ein neues CRM. Ein Make-Szenario zog die exportierte CSV, mappte die Felder und schrieb die Datensätze. Alles grün, keine Fehlermeldung, 38.000 Kontakte importiert. Drei Wochen später ging ein Katalog raus, und gut zwölf Prozent kamen als unzustellbar zurück.

Die Ursache lag nicht im Workflow. Sie lag in einer Tabellenkalkulation, die jemand vor dem Export kurz geöffnet hatte. Excel hatte aus jeder Postleitzahl die führende Null entfernt. Aus 01067 Dresden wurde 1067, aus 04109 Leipzig wurde 4109. Für Excel waren das Zahlen, und Zahlen haben eben keine führende Null. Der Import übernahm diese kaputten Werte anstandslos, denn es waren technisch nur fünf gültige Zeichen, kein Grund zu meckern.

CSV sieht aus wie das harmloseste Format der Welt. Man öffnet die Datei und sieht Zeilen, Spalten, lesbaren Text. Genau diese Lesbarkeit ist die Falle.

"CSV" ist kein Format, sondern ein Missverständnis

Es gibt keinen verbindlichen Standard. Zwar existiert ein RFC, die Nummer 4180, aber kaum ein Werkzeug hält sich strikt daran, und erzwungen wird er nirgends. Trennzeichen, Zeichenkodierung, Anführungszeichen, Zeilenende: alles variiert von System zu System. Zwei Programme behaupten beide, "CSV zu unterstützen", und verstehen sich trotzdem nicht.

Bei einer JSON-Datei oder einem API-Aufruf ist klar, was eine Zahl ist, was Text ist und welche Kodierung gilt. Bei CSV ist alles eine Zeichenkette, und jedes System rät selbst, was gemeint war. Dieses Raten ist die Quelle fast jedes Schadens, den ich in den letzten Jahren aufgeräumt habe.

Die vier Wege, auf denen CSV Ihre Daten leise ruiniert

Kodierung

UTF-8 oder Windows-1252, das ist die erste Bruchstelle. Deutsches Excel speichert eine CSV standardmäßig in der alten Windows-Kodierung. Liest Ihr Workflow die Datei als UTF-8, wird aus Müller ein Buchstabensalat und aus dem ß ein Fragezeichen. Das Tückische daran: Der Import bricht nicht ab. Er schreibt den Müll in die Datenbank, und Sie merken es erst, wenn ein Kunde sich über die Schreibweise seines Namens beschwert.

Trennzeichen

Im deutschen Raum trennt Excel Spalten mit einem Semikolon, weil das Komma als Dezimaltrennzeichen belegt ist. Ein Betrag steht als 1.299,00 in der Zelle. Eine Automatisierung, die auf das Komma als Spaltentrenner ausgelegt ist, zerlegt diese eine Zelle in zwei Spalten und schiebt alles Folgende um eine Position nach rechts. Ab da ist die komplette Zeile Murks, und das bei jeder einzelnen Zeile.

Excel als stiller Saboteur

Das ist die gefährlichste Kategorie, weil der Schaden entsteht, bevor die Datei den Workflow überhaupt erreicht. Excel will hilfreich sein und interpretiert Inhalte eigenmächtig um. Führende Nullen verschwinden, bei Postleitzahlen, Artikelnummern, Telefonvorwahlen. Lange Ziffernfolgen werden in wissenschaftliche Notation umgewandelt, aus einer IBAN oder einer EAN wird 4,01234E+12, und die Originalziffern sind weg. Werte, die nach Datum aussehen, werden zu Datum: Eine Artikelnummer wie 3-11 wird zum 3. November. Sobald Excel die Datei einmal gespeichert hat, sind diese Werte nicht beschädigt, sondern verloren. Aus der Datei lässt sich das Original nicht mehr rekonstruieren.

Anführungszeichen und Sonderzeichen

Ein Freitextfeld enthält ein Komma, einen Zeilenumbruch oder ein Anführungszeichen, etwa eine Adresse wie "Musterstraße 5, Hinterhaus" oder ein Kommentar mit einem Absatz darin. Ein naiver Parser, der einfach an jedem Trennzeichen schneidet, zerreißt diese Zeile. Ein eingebetteter Zeilenumbruch macht aus einem Datensatz zwei, und der Zähler stimmt für den ganzen Rest der Datei nicht mehr.

Warum Automatisierung das Problem verschärft, statt es zu lösen

Ein Mensch, der fünfzig Zeilen von Hand in ein System tippt, stutzt bei "1067 Dresden". Das sieht falsch aus, das prüft er nach. Eine Automatisierung importiert 40.000 Zeilen um drei Uhr nachts und meldet Erfolg.

Hier liegt das Missverständnis: Der grüne Haken bedeutet "Datei verarbeitet", nicht "Daten korrekt". Das Szenario hat getan, was es sollte, es hat Zeilen gelesen und Datensätze geschrieben. Dass der Inhalt dieser Datensätze Unsinn ist, kann es nicht wissen, weil ihm jeder Begriff davon fehlt, wie eine richtige Postleitzahl aussieht. Die Maschine prüft die Form, nicht die Bedeutung. Der Datenschaden bleibt still und fällt erst Wochen später auf, wenn er längst weitergeflossen ist, in Rechnungen, in Mailings, in Auswertungen.

Der Schaden bleibt selten an einer Stelle

Das Heimtückische an kaputten Daten aus einer CSV ist, dass sie nicht liegen bleiben. Die falsche Postleitzahl wandert vom CRM in den Versanddienstleister, von dort auf das Etikett und am Ende in die Retoure. Die aus einer Zahl verstümmelte Artikelnummer landet im Lagersystem und matcht beim nächsten Abgleich auf den falschen Artikel. Der Betrag mit dem falsch interpretierten Tausenderpunkt geht in den Rechnungslauf. Jeder nachgelagerte Schritt behandelt den Müll als Wahrheit, weil das vorgelagerte System ja "erfolgreich" gemeldet hat.

Hinzu kommt das Zahlenformat selbst. 1.000 bedeutet in Deutschland eintausend, im englischsprachigen Raum eine Eins mit drei Nachkommastellen. Liest ein System die Datei mit der falschen Annahme, wird aus tausend Euro ein Euro, oder umgekehrt. In einer Auswertung fällt so etwas vielleicht auf, in einem automatischen Buchungslauf eher nicht.

Genau deshalb ist die Stelle, an der die Datei hereinkommt, die einzige, an der sich der Schaden noch billig stoppen lässt. Eine Stunde Validierung an der Schnittstelle kostet weniger als drei Wochen später die Frage, welche der 38.000 Datensätze überhaupt noch zu retten sind.

Was wir stattdessen tun

Wenn beide Enden uns gehören, vermeiden wir die Datei ganz und nehmen eine API oder JSON statt eines CSV-Exports. Dort ist eine Zahl eine Zahl, die Kodierung ist definiert, und niemand kann zwischendurch Excel öffnen.

Wenn es CSV sein muss, nageln wir alles fest. Die Kodierung wird auf UTF-8 gesetzt und am Anfang der Datei geprüft. Das Trennzeichen geben wir explizit vor, statt es raten zu lassen. Und vor der Verarbeitung validieren wir gegen ein Schema: Stimmt die Spaltenzahl, hat jede Pflichtspalte einen Wert, passt das Format der Postleitzahl? Eine Datei, die das Schema verletzt, wird abgelehnt und nicht halb verarbeitet.

Wir lesen außerdem alles als Text ein und parsen es danach selbst. Die automatische Typerkennung des Werkzeugs schalten wir ab. Eine Postleitzahl ist Text, auch wenn sie nur aus Ziffern besteht. Wer das dem Tool überlässt, bekommt die führende Null wieder geklaut.

Und Excel bleibt aus der Pipeline draußen. Excel ist ein Werkzeug für Menschen, nicht für Maschinen. Sobald jemand die Datei "kurz in Excel öffnet und neu speichert", ist die ganze Mühe dahin. In einer sauberen Automatisierung berührt keine Tabellenkalkulation die Daten zwischen Quelle und Ziel.

Dazu führen wir eine Kanarienzeile mit, eine bekannte Testzeile mit den kritischen Werten am Anfang oder Ende der Datei: eine Postleitzahl mit führender Null, ein Umlaut, ein Betrag im deutschen Format. Kommt diese Zeile unbeschädigt im Ziel an, hat die Datei den Transport überstanden. Kommt sie kaputt an, stoppt der Workflow, bevor er die echten Daten anfasst.

Das eigentliche Problem ist nicht CSV

CSV ist nur die Stelle, an der es zuerst sichtbar wird, weil das Format so harmlos aussieht. Dahinter steckt Vertrauen ohne Prüfung. Wir behandeln eine Datei, die durch fremde Hände und fremde Programme gegangen ist, als wäre ihr Inhalt sauber, nur weil sie sich öffnen lässt.

Etwas, das aussieht wie eine Tabelle, ist trotzdem keine Tabelle. Es ist eine Textdatei mit Konventionen, auf die sich nie jemand geeinigt hat. Wer an jeder Übergabe prüft statt vertraut, hat den größten Teil dieser Fehlerklasse schon ausgeschlossen. Und wer es nicht tut, merkt es nicht am Workflow. Er merkt es am zurückgekommenen Katalog.