CSV in Excel öffnen ohne Zeichensalat: BOM, UTF-8 und Semikolon

Eine CSV-Datei ist im Kern simpel: Werte in Zeilen, getrennt durch ein Zeichen. Trotzdem scheitert kaum etwas so zuverlässig wie das Öffnen einer deutschen CSV in Excel. Statt sauberer Spalten landet die ganze Zeile in Spalte A, und aus jedem Umlaut wird ein kryptisches Doppelzeichen. Beide Probleme treten oft gleichzeitig auf, haben aber zwei völlig getrennte Ursachen. Wer sie auseinanderhält, löst das Thema in Minuten und für immer.

Die zwei Probleme im Schnellüberblick

Es lohnt sich, die beiden Fehlerbilder strikt zu trennen. Das eine betrifft die Spaltenaufteilung, das andere die Zeichencodierung. Sie haben nichts miteinander zu tun und brauchen unterschiedliche Eingriffe.

Problem	Ursache	Lösung
Alles in einer Spalte	Excel im deutschen Gebietsschema erwartet Semikolon, Datei nutzt Komma	Mit Semikolon exportieren, sep=;-Zeile voranstellen oder Import-Assistent
ä statt ä, ö statt ö	UTF-8 ohne BOM wird von Excel als Windows-1252 gelesen	UTF-8-BOM voranstellen oder beim Import Codierung 65001 wählen
Zahlen als Text erkannt	Punkt als Dezimaltrennzeichen kollidiert mit deutschem Komma	Spaltentyp im Import-Assistent setzen oder Gebietsschema beachten
Führende Nullen verschwinden	Excel interpretiert Zahlenspalten automatisch	Spalte beim Import als Text deklarieren

Die ersten beiden Zeilen sind die Klassiker. Wer die versteht, hat den Großteil aller Zeichensalat-Fälle abgedeckt.

Warum Excel das Komma nicht mag

CSV steht für Comma-Separated Values, also kommagetrennte Werte. Genau das ist im deutschsprachigen Raum die Falle. In Deutschland, Österreich und der Schweiz ist das Komma das Dezimaltrennzeichen. Ein Betrag wie 1.234,56 nutzt den Punkt als Tausender- und das Komma als Dezimaltrenner. Würde Excel hier das Komma auch noch als Spaltentrenner verwenden, würde jede Zahl mit Nachkommastelle die Tabelle zerreißen.

Microsoft löst das über das sogenannte Listentrennzeichen aus den Windows-Regions- und Sprachoptionen. Im deutschen Gebietsschema ist dieses Listentrennzeichen standardmäßig das Semikolon. Beim Doppelklick auf eine CSV-Datei greift Excel genau auf diesen Wert zurück. Findet es in der Datei kein Semikolon, sieht es schlicht keine Spaltengrenzen und legt die komplette Zeile in eine Zelle.

Das erklärt auch, warum dieselbe Datei auf einem englischsprachigen System mit Komma-Listentrennzeichen sauber öffnet, auf einem deutschen aber nicht. Die Datei ist nicht kaputt, das Gebietsschema entscheidet über die Interpretation.

Lösung 1: Datei mit Semikolon erzeugen

Der direkteste Weg ist, die CSV von vornherein mit Semikolon zu trennen. Dann passt sie zum deutschen Excel-Default und öffnet sich per Doppelklick korrekt in Spalten.

Komma-getrennt (bricht im deutschen Excel):
Name,Ort,Betrag
Müller,Köln,1234.56

Semikolon-getrennt (öffnet sauber):
Name;Ort;Betrag
Müller;Köln;1234,56

Beim Export aus Datenbanken, Webtools oder eigenen Skripten lässt sich das Trennzeichen fast immer einstellen. Wer eine CSV nur für deutsche Excel-Nutzer bereitstellt, fährt mit Semikolon am ruhigsten. Wer die Datei plattformübergreifend braucht, sollte zusätzlich die folgenden Wege kennen.

Lösung 2: Die Steuerzeile sep=;

Es gibt einen Trick, der unabhängig vom Gebietsschema des Empfängers funktioniert. Steht in der allerersten Zeile der Datei ein sep=-Statement, liest Excel daraus das Trennzeichen aus und ignoriert die Windows-Einstellung.

sep=;
Name;Ort;Betrag
Müller;Köln;1234,56

Excel interpretiert die erste Zeile, übernimmt das Semikolon als Trenner und blendet die sep=-Zeile in der Tabelle aus. Das funktioniert auch mit Komma, wenn man bewusst kommagetrennt arbeiten will:

sep=,
Name,Ort,Betrag
Müller,Köln,1234.56

Wichtig ist die Einschränkung: sep= ist eine reine Microsoft-Konvention. Sie ist nicht Teil der CSV-Spezifikation nach RFC 4180. Öffnet jemand dieselbe Datei in Google Sheets, LibreOffice Calc oder einem Texteditor, taucht die Zeile sep=; als ganz normale erste Datenzeile auf und stört. Diese Methode eignet sich also nur, wenn die Datei sicher in Excel landet.

Der Zeichensalat: warum aus ä ein ä wird

Das zweite große Problem ist die Codierung. Moderne Tools exportieren CSV fast immer als UTF-8, weil dieser Standard alle Sprachen und Sonderzeichen abdeckt. UTF-8 kodiert Umlaute nicht als ein Byte, sondern als Folge mehrerer Bytes. Das ä besteht zum Beispiel aus zwei Bytes.

Das Problem entsteht, weil eine reine UTF-8-Datei keinen sichtbaren Hinweis auf ihre Codierung enthält. Excel rät dann. Auf einem deutschen Windows-System lautet die Vermutung standardmäßig Windows-1252, eine 1-Byte-Codierung. Excel liest also die zwei Bytes des ä als zwei einzelne Zeichen und zeigt ä an. Genau das ist der berüchtigte Mojibake-Effekt.

Original (UTF-8 korrekt):   Müller, Köln, Straße
Falsch gelesen (1252):      Müller, Köln, StraÃe

Die Datei selbst ist dabei völlig in Ordnung. Nur die Annahme über ihre Codierung ist falsch.

Lösung: Das UTF-8-BOM

Die Byte Order Mark, kurz BOM, ist eine kleine Bytefolge ganz am Anfang der Datei. Bei UTF-8 sind das die drei Bytes EF BB BF. Sie sind im Text unsichtbar, signalisieren Excel aber eindeutig: Diese Datei ist UTF-8. Sobald das BOM vorhanden ist, liest Excel die Umlaute beim Doppelklick korrekt.

Bytes am Dateianfang mit BOM:
EF BB BF 4E 61 6D 65 3B 4F 72 74
         N  a  m  e  ;  O  r  t

Das BOM ist der pragmatischste Weg, eine CSV per Doppelklick sauber in Excel zu öffnen. Es kombiniert sich gut mit Semikolon-Trennung. Eine Datei, die UTF-8-BOM plus Semikolon nutzt, öffnet im deutschen Excel ohne jeden Zwischenschritt korrekt in Spalten und mit intakten Umlauten.

Ein kleiner Vorbehalt: Manche älteren oder strikt standardkonformen Parser stolpern über das BOM und behandeln es als Teil des ersten Feldwertes. In der Praxis ist das selten geworden, aber bei automatisierten Verarbeitungsketten sollte man es im Hinterkopf behalten. Für Excel-Endnutzer überwiegt der Vorteil klar.

Der saubere Weg: Daten aus Text/CSV importieren

Wer sich nicht auf BOM, Trennzeichen und Gebietsschema verlassen will, nimmt den Import-Assistenten. Er ist der robusteste Weg, weil man jede Annahme manuell überschreibt. Wichtig: Die CSV dafür nicht doppelklicken, sondern aus einer leeren Arbeitsmappe heraus importieren.

1. In Excel eine leere Mappe öffnen und auf das Register Daten wechseln.
2. Auf Daten abrufen oder direkt auf Aus Text/CSV klicken.
3. Die CSV-Datei auswählen. Es öffnet sich ein Vorschaufenster.
4. Im Feld Dateiursprung die Codierung auf 65001: Unicode (UTF-8) stellen. Damit verschwindet der Zeichensalat sofort in der Vorschau.
5. Im Feld Trennzeichen das passende Zeichen wählen, in der Regel Semikolon oder Komma. Die Vorschau zeigt live, ob die Spalten stimmen.
6. Über Daten transformieren lassen sich bei Bedarf Spaltentypen festlegen, etwa eine Artikelnummer als Text, damit führende Nullen erhalten bleiben.
7. Mit Laden die Daten in die Tabelle übernehmen.

Der große Vorteil: Dieser Weg ignoriert das fehlende BOM und das Gebietsschema komplett, weil man Codierung und Trennzeichen explizit angibt. Er funktioniert auch bei Dateien, die man nicht selbst erzeugt hat und nicht ändern kann.

Die Nummer 65001 ist dabei die Windows-Codepage für UTF-8. Wer sie in der Auswahlliste sieht und wählt, hat das Umlautproblem für diese Datei sicher gelöst, ganz ohne die Datei selbst anzufassen.

Import in Google Sheets

Google Sheets verhält sich entspannter, weil es UTF-8 als Standard annimmt und kein BOM benötigt. Der Weg ist trotzdem ein bewusster Import statt eines blinden Öffnens.

1. In Google Sheets auf Datei und dann Importieren klicken.
2. Die CSV hochladen oder aus Google Drive wählen.
3. Bei Trennzeichen die Option Erkennen, Komma oder Semikolon wählen. Für deutsche Dateien meist Semikolon.
4. Importieren bestätigen.

Zwei Dinge sind hier anders als bei Excel. Erstens braucht Google Sheets kein UTF-8-BOM, die Umlaute kommen ohnehin korrekt an. Zweitens versteht Google Sheets die sep=;-Zeile nicht. Enthält die Datei diese Microsoft-Steuerzeile, erscheint sie als erste Datenzeile und muss nachträglich gelöscht werden. Wer eine CSV sowohl für Excel als auch für Google Sheets ausliefert, steht damit vor einem Zielkonflikt: sep= hilft Excel, stört aber Sheets. In diesem Fall ist die Kombination UTF-8-BOM plus Semikolon ohne sep=-Zeile der beste Kompromiss, weil beide Programme damit zurechtkommen.

Was beim Export richtig eingestellt sein sollte

Die meisten Zeichensalat-Probleme entstehen nicht beim Öffnen, sondern beim Erzeugen der Datei. Wer eine CSV für deutsche Excel-Nutzer exportiert, sollte drei Stellschrauben kennen:

• Codierung auf UTF-8 mit BOM, damit Umlaute beim Doppelklick intakt bleiben.
• Trennzeichen auf Semikolon, passend zum deutschen Gebietsschema.
• Zahlenformat im Blick behalten, also Komma als Dezimaltrenner, wenn die Datei für deutsches Excel gedacht ist.

Das Tool json-csv.de erzeugt CSV-Dateien clientseitig im Browser, ohne dass Daten an einen Server gehen. Beim Export lassen sich Codierung und Trennzeichen passend setzen, sodass die Ausgabe als UTF-8 mit dem richtigen Trennzeichen direkt in Excel landet, ohne den Umweg über den Import-Assistenten. Wer regelmäßig JSON-Strukturen für die Weiterverarbeitung in Tabellen braucht, spart sich damit die nachträgliche Reparatur.

Schnelldiagnose im Alltag

Wenn eine CSV nicht sauber öffnet, hilft eine kurze Prüfreihenfolge. Erst die Spalten, dann die Zeichen.

Stimmen die Spalten nicht, ist das Trennzeichen die Ursache. Datei in einem Texteditor öffnen und nachsehen, ob Komma oder Semikolon genutzt wird. Passt es nicht zum deutschen Excel, hilft Semikolon-Export, eine sep=-Zeile oder der Import-Assistent.

Sind die Umlaute kaputt, ist die Codierung schuld. Hier hilft ein BOM beim Export oder die Codierung 65001 im Import. Ein guter Texteditor zeigt die Codierung in der Statusleiste an und kann eine Datei mit wenigen Klicks als UTF-8 mit BOM neu speichern.

Diese zwei Fragen, getrennt gestellt, führen praktisch immer zur richtigen Lösung. Die Verwirrung entsteht meist nur, weil beide Symptome gleichzeitig auftreten und wie ein einziges großes Problem wirken.

Worauf es ankommt

Der Zeichensalat in Excel hat zwei klar getrennte Ursachen. Die kaputten Spalten kommen vom Trennzeichen, weil deutsches Excel Semikolon erwartet und Komma als Dezimaltrenner reserviert. Die kaputten Umlaute kommen von der Codierung, weil UTF-8 ohne BOM als Windows-1252 fehlinterpretiert wird. Wer eine CSV als UTF-8 mit BOM und Semikolon-Trennung erzeugt, öffnet sie per Doppelklick sauber. Wer die Datei nicht ändern kann, nimmt den Import über Daten aus Text/CSV und stellt Codierung 65001 sowie das Trennzeichen explizit ein. Für Google Sheets gilt: kein BOM nötig, aber keine sep=-Zeile verwenden. Mit diesem Wissen wird aus einem wiederkehrenden Ärgernis eine Sache von Sekunden.