CSV-Trennzeichen und Umlaute richtig setzen

Eine CSV-Datei ist im Kern nur Text, doch genau drei Entscheidungen entscheiden darüber, ob das Zielsystem sie sauber liest oder als Datenmüll abweist: das Trennzeichen zwischen den Feldern, die Zeichenkodierung für Umlaute und Sonderzeichen und die Frage, wie Felder mit Sonderfällen maskiert werden. Wer eine Tabelle aus Excel exportiert und sie anschließend in eine Datenbank, einen Shop oder ein anderes Programm überträgt, läuft ohne Kenntnis dieser drei Stellschrauben fast zwangsläufig in verrutschte Spalten oder kaputte Umlaute. Dieser Ratgeber zeigt, welche Einstellung wann die richtige ist.

Trennzeichen: Komma, Semikolon, Tab oder Pipe

Das Comma-Separated-Values-Format trägt das Komma schon im Namen, und tatsächlich nennt der Referenzstandard RFC 4180 das Komma als Trennzeichen. In der deutschen Praxis ist die Lage aber komplizierter, weil das Komma hierzulande als Dezimaltrennzeichen belegt ist. Würde Excel auf einem deutschen System mit Komma trennen, ließe sich eine Zahl wie 1,50 nicht mehr von zwei getrennten Feldern unterscheiden. Microsoft löst das, indem deutsches Excel als Listentrennzeichen das Semikolon verwendet, abgeleitet aus den Regions- und Sprachoptionen von Windows.

Daraus ergibt sich eine klare Faustregel. Soll die Datei mit deutschem Excel oder auf anderen deutschsprachigen Systemen per Doppelklick geöffnet werden, ist das Semikolon das passende Trennzeichen. Geht die Datei dagegen in eine Datenbank, an eine Schnittstelle oder in eine Programmiersprache wie Python, R oder JavaScript, die sich an den internationalen Standard hält, ist das Komma korrekt. Zwei weitere Trennzeichen begegnen einem regelmäßig: der Tabulator und die Pipe.

• Komma: Standard nach RFC 4180, richtig für Datenbanken, APIs und internationale Systeme.
• Semikolon: Standard für deutsches Excel und DE-Systeme, weil das Komma als Dezimaltrennzeichen reserviert ist.
• Tabulator: Häufig als TSV, nützlich wenn die Werte selbst viele Kommas oder Semikolons enthalten, da Tabs in normalem Text selten vorkommen.
• Pipe: Das Zeichen | wird in technischen Exporten und manchen Altsystemen genutzt, gilt als robust, weil es in Fließtext kaum auftaucht.

Wichtig ist nicht, welches Zeichen objektiv das beste ist, sondern dass Export und Import dasselbe Trennzeichen erwarten. Ein verbreiteter Fehler ist eine mit Semikolon erzeugte Datei, die ein nach RFC 4180 trennender Importer am Komma zerlegt. Das Ergebnis: alles steht in einer einzigen Spalte. Ein guter Konverter erkennt das Trennzeichen automatisch oder lässt Sie es explizit wählen.

Zeichenkodierung: UTF-8, ANSI und Latin-1

Text braucht eine Zeichenkodierung, also eine Vorschrift, welche Bytes für welche Zeichen stehen. Heute ist UTF-8 der De-facto-Standard. Es ist in RFC 3629 beschrieben, Teil des Unicode-Standards und kann jedes Zeichen darstellen, von deutschen Umlauten über das ß bis zu kyrillischer und asiatischer Schrift sowie Emojis. Daneben existiert die ältere Familie ANSI, im deutschsprachigen Windows-Umfeld meist Windows-1252 oder das eng verwandte Latin-1 (ISO 8859-1). Diese Kodierungen decken nur einen begrenzten westeuropäischen Zeichenvorrat ab.

Solange Daten innerhalb eines einzigen, einheitlich konfigurierten Systems bleiben, fällt der Unterschied kaum auf. Probleme entstehen genau an der Schnittstelle, wenn eine Datei in einer Kodierung gespeichert, aber in einer anderen gelesen wird. Speichert ein älteres Programm die CSV als Windows-1252 und liest ein modernes System sie als UTF-8 ein, werden die Umlaute falsch dekodiert. Für neue Exporte gilt deshalb: immer UTF-8 wählen, denn nur diese Kodierung überträgt Umlaute zuverlässig über Systemgrenzen hinweg.

Der typische Umlaut-Salat und seine Ursache

Das bekannteste Symptom einer Kodierungskollision ist der sogenannte Umlaut-Salat, fachlich Mojibake genannt. Aus Köhler wird Köhler, aus Straße wird Straße, aus für wird für. Die Ursache ist immer dieselbe: Ein als UTF-8 gespeicherter Umlaut belegt mehrere Bytes, und wenn ein System diese Bytes fälschlich als einzelne Windows-1252-Zeichen interpretiert, erscheint pro Umlaut eine kryptische Zeichenfolge. Der umgekehrte Fall, eine Windows-1252-Datei als UTF-8 gelesen, führt oft zu Ersatzzeichen oder Lesefehlern. Die einzige verlässliche Abhilfe ist, Quelle und Ziel auf dieselbe Kodierung zu bringen, im Zweifel auf UTF-8.

Das UTF-8-BOM: Segen und Stolperstein zugleich

Eng mit der Kodierung verbunden ist das Byte Order Mark, kurz BOM. Es handelt sich um eine kurze, unsichtbare Bytefolge (EF BB BF) am Dateianfang, die signalisiert, dass die Datei UTF-8-kodiert ist. Im Editor sieht man davon nichts, technisch steht es aber vor dem allerersten Zeichen der Datei.

Für deutsches Excel ist dieses BOM ein Segen. Speichert man eine Datei ausdrücklich als CSV UTF-8, schreibt Excel das BOM mit und erkennt dieselbe Datei beim späteren Doppelklick zweifelsfrei als UTF-8. Ohne BOM rät deutsches Excel die Kodierung oft falsch und stellt Umlaute kaputt dar, sofern man nicht den Importassistenten bemüht. Wer also möchte, dass ä, ö, ü und ß direkt beim Doppelklick stimmen, ist mit UTF-8 mit BOM gut beraten.

Genau dasselbe BOM ist für andere Systeme aber ein Stolperstein. Ältere Datenbank-Importer, manche Kommandozeilen-Skripte und einfache CSV-Parser kennen das BOM nicht und lesen die drei Bytes als Teil des ersten Feldwertes. So wird aus der sauberen Spaltenüberschrift id die unbrauchbare Überschrift id, und ein Abgleich der Spaltennamen schlägt fehl. Die Konsequenz ist klar: Das BOM ist keine Einstellung, die man pauschal richtig oder falsch macht, sondern eine bewusste Entscheidung je nach Zielsystem.

RFC-4180-Quoting: Felder korrekt maskieren

Die scheinbare Einfachheit von CSV bricht, sobald ein Feldwert selbst das Trennzeichen, ein Anführungszeichen oder einen Zeilenumbruch enthält. RFC 4180 regelt diesen Fall mit klaren Quoting-Regeln. Felder dürfen in doppelte Anführungszeichen gesetzt werden, müssen es aber, wenn sie das Trennzeichen, ein Anführungszeichen oder einen Zeilenumbruch enthalten. Ein Anführungszeichen innerhalb eines umschlossenen Feldes wird durch Verdoppelung maskiert, aus einem Anführungszeichen werden also zwei.

Das folgende Beispiel zeigt eine CSV mit Komma als Trennzeichen, Umlauten und allen drei kritischen Sonderfällen: ein Komma im Wert, eingebettete Anführungszeichen und ein Zeilenumbruch innerhalb eines Feldes.

id,name,notiz
1,"Müller, Anna","Sie sagte ""ja"" zur Lösung"
2,"Bjørn Maaß","Adresse:
Hauptstraße 5, Köln"
3,Schäfer,Kürzel ÄÖÜ ohne Sonderzeichen

Ein RFC-4180-konformer Parser liest hier drei Spalten und vier Datensätze korrekt aus. Das Komma in Müller, Anna bleibt Teil des Namens, weil das Feld umschlossen ist. Die verdoppelten Anführungszeichen werden wieder zu einfachen, sodass im Ziel Sie sagte "ja" zur Lösung steht. Der Zeilenumbruch in der Adresse bleibt als Teil eines einzigen Feldes erhalten und reißt die Tabelle nicht auseinander. Felder ohne Sonderzeichen wie Schäfer brauchen keine Anführungszeichen. Ein simpler Konverter, der stur an jedem Komma trennt, würde dagegen Spalten und Zeilen durcheinanderwerfen.

Dezimaltrennzeichen: Komma oder Punkt

Ein eigener Stolperstein ist das Dezimaltrennzeichen innerhalb der Zahlen. Deutsches Excel schreibt Dezimalzahlen mit Komma, also 1.234,50 mit Punkt als Tausendertrennung. Datenbanken, Programmiersprachen und internationale Systeme erwarten dagegen den Punkt als Dezimaltrennzeichen, also 1234.50, meist ganz ohne Tausendertrennung. Wird eine deutsche Zahl unverändert in ein internationales System gegeben, wird aus 1.234,50 schnell ein unbrauchbarer Text oder eine falsch interpretierte Zahl.

Heikel wird es, wenn das Dezimalkomma mit dem Komma als Feldtrennzeichen zusammentrifft. Dann gibt es zwei saubere Wege: entweder das Semikolon als Feldtrennzeichen wählen, sodass das Dezimalkomma unverwechselbar bleibt, oder die Zahlenfelder in doppelte Anführungszeichen setzen. Für den Export in technische Zielsysteme empfiehlt sich, Zahlen gleich mit Punkt als Dezimaltrennzeichen und ohne Tausenderpunkt zu schreiben, weil das die meisten Parser ohne Sonderbehandlung verarbeiten.

Trennzeichen und Encoding je Zielsystem

Die folgende Tabelle fasst zusammen, welche Kombination aus Trennzeichen und Kodierung für die häufigsten Zielsysteme die richtige ist. Sie ersetzt kein Lesen der jeweiligen Importvorgaben, gibt aber eine verlässliche Ausgangslage.

Checkliste: Trennzeichen und Umlaute richtig setzen

Wer die folgenden Punkte abarbeitet, vermeidet die häufigsten Fehler beim CSV-Export und beim anschließenden Import:

• Zielsystem zuerst klären: Erst entscheiden, wohin die Datei geht, dann Trennzeichen und Kodierung danach ausrichten.
• Trennzeichen passend wählen: Semikolon für deutsches Excel, Komma für Datenbanken und internationale Systeme.
• UTF-8 als Kodierung: Für neue Exporte immer UTF-8 nutzen, nicht ANSI oder Latin-1.
• BOM bewusst setzen: Für den Excel-Doppelklick mit BOM, für Datenbank-Importer und Skripte ohne BOM.
• Quoting beachten: Felder mit Trennzeichen, Anführungszeichen oder Zeilenumbruch nach RFC 4180 umschließen und Anführungszeichen verdoppeln.
• Dezimaltrennzeichen prüfen: Komma für deutsches Excel, Punkt für technische Zielsysteme, Kollision mit dem Feldtrennzeichen vermeiden.
• Stichprobe machen: Nach dem Export eine Zeile mit Umlauten und Sonderzeichen im Zielsystem kontrollieren.

Häufige Fragen

Quellen

• RFC 4180: Common Format and MIME Type for CSV Files, IETF
• RFC 3629: UTF-8, a transformation format of ISO 10646, IETF
• The Unicode Standard, Unicode Consortium
• Listentrennzeichen in Excel ändern, Microsoft Learn

Verwandte Artikel