CSV-Import kaputt: das unsichtbare Zeichen am Dateianfang

Die erste Spalte wird nicht erkannt. Umlaute erscheinen als Buchstabensalat. Der JSON-Parser bricht bei Position 0 ab, wo scheinbar nichts steht. Drei Symptome, eine Ursache — und leider eine, die je nach Zielprogramm genau gegenteilig behandelt werden muss.

Die schnelle Diagnose

  1. Öffne die Datei in VS Code und schau unten rechts in die Statusleiste.
  2. Steht dort UTF-8 mit BOM, hast du die Ursache gefunden.
  3. Klick auf die Anzeige, wähle Save with Encoding und dann UTF-8 ohne Zusatz.
  4. Datei speichern und erneut importieren.

Was das BOM ist und warum es existiert

Das Byte-Order-Mark ist ein unsichtbares Zeichen mit dem Codepoint U+FEFF, das ganz am Anfang einer Datei steht. Sein Zweck ist eine Ansage an das lesende Programm: „Diese Datei ist UTF-8 kodiert." Ohne diesen Hinweis muss jedes Programm raten, und Windows rät traditionell falsch.

Damit ist das BOM kein Fehler, sondern eine Hilfe — im richtigen Kontext. Das Problem entsteht daraus, dass zwei Welten unterschiedliche Erwartungen haben: Excel will das BOM, um Umlaute korrekt darzustellen. Programmierschnittstellen wollen es nicht, weil es für sie ein normales Zeichen im Datenstrom ist.

Die drei Symptome

Die erste Spalte wird nicht gefunden

Deine CSV-Datei hat die Überschriften Kunde;Umsatz;Datum, und dein Skript findet die Spalte Kunde nicht. Technisch heißt sie nämlich \uFEFFKunde — das BOM klebt am ersten Wert. Auf dem Bildschirm ist davon nichts zu sehen.

Das ist der heimtückischste Fall, weil alles korrekt aussieht. Ein Abgleich mit if spalte == "Kunde" schlägt fehl, obwohl beide Zeichenfolgen identisch wirken.

Umlaute werden zu Buchstabensalat

Aus Müller wird Müller, aus Straße wird Straße. Hier ist es genau umgekehrt: Das BOM fehlt, und Excel hat die Datei deshalb als Windows-Kodierung statt als UTF-8 gelesen. Die Lösung ist nicht, das BOM zu entfernen, sondern es hinzuzufügen.

Der Parser bricht bei Zeichen 0 ab

Meldungen wie Unexpected token in JSON at position 0 oder Invalid character deuten fast immer auf das BOM. Der Parser erwartet an erster Stelle eine geschweifte Klammer und findet ein unsichtbares Zeichen.

Das BOM entfernen

Programm Vorgehen
VS CodeKodierung in der Statusleiste anklicken › Save with EncodingUTF-8
Notepad++Menü KodierungUTF-8 (nicht „UTF-8 BOM")
PythonBeim Lesen encoding="utf-8-sig" statt utf-8 — entfernt das BOM automatisch
PowerShellSet-Content -Encoding utf8NoBOM beim Schreiben
Kommandozeilesed -i '1s/^\uFEFF//' datei.csv

Der Python-Weg ist der eleganteste, weil er nichts an der Datei ändert: utf-8-sig liest ein vorhandenes BOM und verwirft es, funktioniert aber genauso mit Dateien ohne BOM. Damit läuft dasselbe Skript für beide Varianten.

Das BOM hinzufügen — wenn Excel Umlaute zerstört

Der umgekehrte Fall: Du exportierst eine CSV-Datei, und beim Öffnen in Excel sind alle Umlaute zerschossen. Dann fehlt das BOM, und Excel braucht es.

In Python schreibst du die Datei dafür mit encoding="utf-8-sig" — dieselbe Kodierung, die beim Lesen entfernt, fügt beim Schreiben hinzu. In VS Code wählst du bei Save with Encoding die Variante UTF-8 with BOM.

Alternativ umgehst du das Problem beim Öffnen: DatenAus Text/CSV in Excel, dort die Kodierung ausdrücklich auf 65001: Unicode (UTF-8) stellen. Der Doppelklick auf die Datei nimmt diesen Weg nicht und rät stattdessen.

Zellinhalte prüfen und bereinigen

Nicht jedes CSV-Problem kommt vom BOM. Häufig stecken geschützte Leerzeichen in den Werten selbst, etwa als Tausendertrennzeichen in Zahlen. Füge eine verdächtige Zeile hier ein — die Auswertung zeigt sofort, ob und wie viele auffällige Zeichen enthalten sind:

CSV-Zeile prüfen Noch nichts eingefügt
Nichts wird hochgeladen

Die anderen üblichen CSV-Fallen

Das Trennzeichen

Excel in deutscher Spracheinstellung erwartet das Semikolon als Spaltentrenner, der internationale Standard ist das Komma. Öffnest du eine kommagetrennte Datei per Doppelklick, landet alles in einer einzigen Spalte. Der Umweg über DatenAus Text/CSV löst auch das, weil du dort das Trennzeichen selbst wählst.

Zahlen als Text

Werte wie 1 234,50 mit geschütztem Leerzeichen als Tausendertrennzeichen liest Excel als Text und rechnet nicht damit. Wie du das reparierst, steht ausführlich auf der Excel-Seite.

Führende Nullen verschwinden

Postleitzahlen wie 01067 werden beim Import zu 1067, weil Excel sie als Zahl interpretiert. Das ist kein Zeichenproblem, sondern eine Typumwandlung — im Importdialog lässt sich die Spalte ausdrücklich als Text deklarieren.

Häufige Fragen

Woran erkenne ich, ob eine Datei ein BOM hat?

In VS Code steht es in der Statusleiste unten rechts. Auf der Kommandozeile zeigt file datei.csv unter Linux und macOS den Hinweis „UTF-8 Unicode (with BOM) text". Ein Editor ohne Kodierungsanzeige verrät es nicht — das Zeichen ist unsichtbar.

Soll ich das BOM nun setzen oder nicht?

Das hängt allein davon ab, wer die Datei liest. Landet sie in Excel und wird von Menschen geöffnet: mit BOM. Wird sie von einem Skript, einer Schnittstelle oder einer Datenbank verarbeitet: ohne. Eine allgemein richtige Antwort gibt es nicht, und genau daraus entsteht das ganze Durcheinander.

Meine Datei sieht im Editor sauber aus, das Skript scheitert trotzdem

Dann steckt das Problem in den Werten statt am Dateianfang. Kopiere die betroffene Zeile in das Werkzeug oben. Häufige Kandidaten sind geschützte Leerzeichen in Zahlen und breitenlose Leerzeichen aus kopierten Webinhalten.

Warum macht Excel das überhaupt so kompliziert?

Weil das CSV-Format nie standardisiert wurde. Es gibt keine verbindliche Regel für Kodierung, Trennzeichen oder Zeilenenden — jedes Programm trifft eigene Annahmen. Das BOM ist der Versuch, wenigstens die Kodierungsfrage zu klären, und schafft dabei ein neues Problem an anderer Stelle.

Weiterführend