CSV in Excel und zurück, ohne Ihre Daten zu verfälschen

Das Problem mit dem Trennzeichen beginnt, bevor die Datei überhaupt geöffnet ist

Wie Excel eine CSV-Datei in Spalten aufteilt, entscheidet es anhand des Listentrennzeichens aus den Regionaleinstellungen Ihres Betriebssystems, nicht anhand der Datei. Auf einem Computer mit europäischen Regionaleinstellungen ist dieses Trennzeichen standardmäßig ein Semikolon. Ein gewöhnlicher Export mit Kommas als Trennzeichen landet dort deshalb als ungeteilter Text in einer einzigen Spalte. Auf einem Computer mit US-Einstellungen passiert dasselbe umgekehrt mit einer Datei, die Semikolons verwendet. Keines der beiden Ergebnisse bedeutet, dass die Datei kaputt ist. Es bedeutet nur, dass Excel anhand von Einstellungen geraten hat, die nichts damit zu tun haben, wie die Datei geschrieben wurde. Ein Konverter wie CSV in Excel liest die Datei probeweise mit mehreren möglichen Trennzeichen und prüft, bei welchem die Zeilen der Stichprobe durchgehend gleich viele Felder ergeben. So entfällt das Raten ganz: Er verlässt sich weder auf die Dateiendung noch auf eine Systemeinstellung.

Führende Nullen und lange Zahlen gehen unbemerkt verloren

Den größten Schaden richtet eine Umwandlung von CSV in Excel an, wenn sie Text zu eifrig in Zahlen verwandelt. Eine Artikelnummer wie 00123 wird zur Zahl 123, sobald eine Tabellenkalkulation sie für numerisch hält, und die führende Null lässt sich danach nicht wiederherstellen. Sie ist einfach weg. Längere Kennungen gehen auf andere Weise kaputt. Eine sechzehnstellige Karten- oder Barcode-Nummer verliert ohne jede Warnung ihre letzten Ziffern, weil die üblichen Zahlen einer Tabellenkalkulation nicht mehr als etwa fünfzehn signifikante Stellen ohne Rundung speichern können. Beides sollte Text bleiben, statt umgewandelt zu werden, und dieselbe Regel gilt, wenn das Ziel kein Excel ist, sondern ein Programm: CSV in JSON behält solche Werte als Zeichenketten. Werte, die wirklich Zahlen sind, etwa Mengen, Preise und Summen, sollten dagegen ganz normal umgewandelt werden, damit sich mit ihnen rechnen lässt und sie summiert werden können.

An der Codierung scheitern nicht englische Daten

Dateien, die ältere Buchhaltungssysteme oder Datenbanken exportieren, sind oft gar nicht in UTF-8 codiert. Die häufigsten Fälle sind Windows-1251 für kyrillischen Text und Windows-1252 für westeuropäische Buchstaben mit Akzenten und Umlauten. Wird eine solche Datei unter der falschen Annahme geöffnet, entsteht der bekannte Zeichensalat. Die echte Codierung lässt sich automatisch erkennen: zuerst nach einer Byte-Order-Mark (BOM) suchen, dann streng als UTF-8 prüfen und, wenn das scheitert, anhand der Verteilung der hohen Bytes auf eine andere Codierung zurückgreifen. Niemand muss dann in einem Menü mit Codierungen raten.

Auch die BOM selbst kann unbemerkt Schaden anrichten

Eine UTF-8-BOM besteht aus drei unsichtbaren Bytes ganz am Anfang einer Datei, die Excel mitteilen, dass der folgende Text Unicode ist. Das ist nützlich, wenn die Datei in Excel landen soll. Zum Problem wird es, sobald sie für etwas anderes als Excel bestimmt ist. Bei einem Kommandozeilen-Tool oder einer älteren Datenpipeline, die diese Bytes nicht entfernt, kleben sie danach am ersten Zeichen der ersten Zelle in der Kopfzeile. Eine Spalte, die „id“ heißen soll, passt dann zu nichts mehr, was genau diesen Namen erwartet. Ob die BOM bleiben oder wegfallen soll, hängt allein davon ab, was die Datei als Nächstes liest – nicht von einer einzigen, für alle gültigen Standardeinstellung.

Der Rückweg verlangt eigene Entscheidungen

Wandeln Sie eine Tabelle mit Excel in CSV zurück in CSV um, stellt sich eine Frage, die in der anderen Richtung nie aufkommt. Eine Zelle mit einer Formel hat zwei Werte: den Formeltext selbst und die Zahl, die bei der letzten Berechnung herauskam. CSV kann immer nur einen davon aufnehmen. Den berechneten Wert erwarten die meisten Systeme beim Import. Den Formeltext möchte dagegen ein Mensch lesen, der die Tabelle prüft. Datumsangaben verdienen dieselbe ausdrückliche Sorgfalt. Schreiben Sie sie in einem festen, bewusst gewählten Format, statt dem zu vertrauen, was die Tabelle gerade anzeigte, liefert dieselbe Datei keine unterschiedlich aussehenden Datumsangaben mehr – je nachdem, mit welchen Regionaleinstellungen welcher Computer sie formatiert hat.

Häufige Fehler und die Einstellung, die jeden davon verhindert

Das Dezimaltrennzeichen auf Punkt lassen. Ein Export mit Semikolons aus einem Land, in dem man eineinhalb als 1,50 schreibt, braucht in CSV in Excel beim „Dezimaltrennzeichen“ die Wahl „Komma“; sonst bleibt jeder Preis eine Zeichenkette und lässt sich nicht summieren. Bei Kennungen der automatischen Typerkennung vertrauen. Sie schützt führende Nullen und alles über fünfzehn Stellen, aber eine Bestellnummer oder eine Postleitzahl ohne führende Null wird trotzdem zur Zahl. Braucht keine Spalte Rechenoperationen, behält die Wahl „Alles als Text“ unter „Zelltypen“ jeden Wert genau so, wie er geschrieben wurde. Einen Export mit einigen Millionen Zeilen in eine einzige Arbeitsmappe zwängen. XLSX endet bei 1.048.576 Zeilen. Eine längere CSV-Datei wird deshalb mit einem Link zu CSV aufteilen abgelehnt, statt kommentarlos abgeschnitten zu werden.

Auf dem Rückweg vergleichen Sie drei Standardeinstellungen in Excel in CSV mit dem, was die Datei als Nächstes liest. Die „Ausgabecodierung“ ist „UTF-8 mit BOM“, die Form, die Excel braucht; ein Skript oder ein Importprogramm für eine Datenbank erwartet meist einfaches UTF-8. Das „Datumsformat“ ist ISO 8601, sodass aus dem 14. März 2026 auf jedem Computer 2026-03-14 wird; zur Wahl stehen außerdem 14.03.2026, 03/14/2026 und die Excel-Seriennummer. „Zeilenenden“ steht auf CRLF für Windows; für Unix-Tools gibt es LF. Eine vierte Einstellung wird leicht übersehen: Standardmäßig wird nur das erste Blatt exportiert. Eine Arbeitsmappe mit einem zweiten Tabellenblatt braucht deshalb „Alle Blätter“, und Sie erhalten ein ZIP-Archiv mit einer CSV-Datei je Blatt.