Excel-Tabellen enthalten oft genau die Daten, die besonders schützenswert sind: Kundenlisten, Mitarbeiterdaten, Bestellungen mit Namen und Adressen, Umsatzzahlen. Wer eine solche .xlsx nach CSV exportiert, etwa um sie in ein anderes System zu importieren, sollte zwei Dinge sicherstellen. Erstens, dass die erzeugte CSV technisch sauber ist, also dem CSV-Standard RFC 4180 folgt und korrekt in UTF-8 kodiert wird, damit Spalten und Umlaute stimmen. Zweitens, dass dabei kein Datenschutzverstoß passiert, weil die sensible Excel-Datei unbedacht auf einen fremden Server hochgeladen wird. Dieser Ratgeber bringt beide Ebenen zusammen.

RFC 4180: der Standard hinter dem CSV-Format

CSV wirkt simpel: Werte, getrennt durch ein Zeichen, eine Zeile pro Datensatz. Genau diese scheinbare Einfachheit erzeugt in der Praxis Probleme, sobald ein Feldwert selbst das Trennzeichen, ein Anführungszeichen oder einen Zeilenumbruch enthält. Damit Programme die exportierte CSV trotzdem einheitlich lesen können, hat die IETF im Jahr 2005 das Dokument RFC 4180 veröffentlicht. Es ist keine bindende Norm, gilt aber als faktische Referenz für das Format und den MIME-Typ text/csv.

Die wichtigsten Regeln aus RFC 4180 in Kurzform: Jeder Datensatz steht in einer eigenen Zeile. Eine optionale Kopfzeile mit den Spaltennamen darf am Anfang stehen, sie entsteht aus der Überschriftenzeile Ihrer Excel-Tabelle. Felder werden durch ein Trennzeichen getrennt. Felder dürfen in doppelte Anführungszeichen gesetzt werden, müssen es aber, wenn sie das Trennzeichen, ein Anführungszeichen oder einen Zeilenumbruch enthalten. Und ein Anführungszeichen innerhalb eines umschlossenen Feldes wird durch Verdoppelung maskiert.

Das sogenannte Quoting ist der Punkt, an dem laienhafte Konverter scheitern und die CSV-Spalten verrutschen lassen. Betrachten Sie eine Excel-Zeile, bei der ein Name selbst ein Komma enthält und eine Notiz Anführungszeichen. Ein RFC-4180-konformer Export schreibt daraus diese CSV:

id,name,notiz
1,"Müller, Anna","Sie sagte ""ja"""
2,"Bjørn Maaß","Zeile mit
Umbruch"

Der Konverter umschließt hier das Feld Müller, Anna mit Anführungszeichen, damit das enthaltene Komma nicht als Spaltentrenner missverstanden wird. Das eingebettete Anführungszeichen wird verdoppelt, und ein Zellinhalt mit Zeilenumbruch bleibt als ein einziges, umschlossenes Feld erhalten. Ein simpler Export, der jeden Wert nur stur mit einem Trennzeichen aneinanderreiht, würde aus Müller, Anna zwei Felder machen und die gesamte Zeile verschieben, sodass Adressen plötzlich unter Notizen stehen. Genau deshalb lohnt sich ein Werkzeug, das das Quoting nach RFC 4180 beherrscht.

Tipp zum Semikolon: RFC 4180 nennt das Komma als Trennzeichen, doch viele Zielsysteme im deutschsprachigen Raum erwarten das Semikolon, weil das Komma hier als Dezimaltrennzeichen belegt ist. Das ist kein Fehler, sondern eine regionale Eigenheit. Wählen Sie beim Excel-Export das passende Trennzeichen passend zum Zielsystem, damit aus mehreren Spalten nicht versehentlich eine wird.

UTF-8, ANSI und das Problem mit dem BOM

CSV ist reiner Text, und Text braucht eine Zeichenkodierung. Die Excel-Datei selbst (.xlsx nach dem ECMA-376-Standard, Office Open XML) speichert Texte intern bereits als UTF-8 nach RFC 3629. UTF-8 hat sich auch im Web als De-facto-Standard durchgesetzt, weil es alle Zeichen darstellen kann, von deutschen Umlauten über das ß bis zu kyrillischer Schrift und Emojis. Beim Schritt von der .xlsx zur CSV entscheidet sich, ob diese Zeichen erhalten bleiben, denn genau an dieser Schnittstelle entstehen die meisten Probleme.

Schreibt ein Export die CSV als ANSI beziehungsweise Windows-1252 oder Latin-1, werden Umlaute bei der späteren Interpretation als UTF-8 falsch dekodiert. Aus Köhler wird dann Köhler, aus Straße wird Straße. Dieses Phänomen ist als Umlaut-Salat oder Mojibake bekannt. Die einzige zuverlässige Abhilfe ist, die CSV von Anfang an als UTF-8 zu schreiben. excel-csv.de liest die UTF-8-Inhalte aus Ihrer .xlsx und gibt sie unverändert als UTF-8-CSV aus, sodass Umlaute korrekt erhalten bleiben.

Ein zweiter, tückischer Stolperstein ist das Byte Order Mark (BOM). Stellen manche Programme einer UTF-8-CSV drei unsichtbare Bytes (EF BB BF) an den Anfang, ist diese Markierung im Editor nicht sichtbar, klebt beim Einlesen aber an der ersten Spaltenüberschrift. So entsteht aus der sauberen Überschrift id die unbrauchbare Überschrift id, die beim Zuordnen von Spalten im Zielsystem Ärger macht. Ein guter Konverter schreibt die CSV ohne ein solches störendes BOM, sodass die Kopfzeile direkt verwendbar ist.

Datenschutz: warum lokale Verarbeitung im Browser zählt

Der wichtigste Unterschied zwischen einem datenschutzkonformen und einem riskanten Konverter ist nicht das Aussehen, sondern der Weg, den die Daten nehmen. Viele bekannte Online-Tools laden die hochgeladene Excel-Datei auf einen Server, verarbeiten sie dort und schicken die fertige CSV zurück. Bei öffentlichen Testdaten ist das unproblematisch, bei Kundenlisten, Personaldaten oder Umsatzzahlen aber heikel. Sobald die .xlsx den Rechner verlässt, liegt eine Übermittlung an einen Dritten vor.

excel-csv.de geht den anderen Weg. Die gesamte Umwandlung läuft mit JavaScript direkt in Ihrem Browser. Die Excel-Datei wird lokal auf Ihrem eigenen Gerät zur CSV gerechnet, es gibt keinen Upload, keinen Empfänger und keine Übermittlung an einen Dritten. Aus Datenschutzsicht ist das ein echter Unterschied.

Die Datenschutz-Grundverordnung regelt die Verarbeitung personenbezogener Daten. Wird eine Excel-Datei mit Personenbezug zu einem fremden Server hochgeladen, brauchen Sie nach Art. 28 DSGVO in der Regel einen Auftragsverarbeitungsvertrag (AVV), müssen eine Rechtsgrundlage nachweisen und die Betroffenen über den Empfänger informieren. Liegt der Server außerhalb der EU, kommt die Frage des Drittlandtransfers hinzu. Bei lokaler Verarbeitung entfällt all das, weil schlicht nichts das Gerät verlässt. Das Prinzip der Datenminimierung nach Art. 5 Abs. 1 lit. c DSGVO ist dabei im Idealfall erfüllt, ebenso die von Stellen wie der ENISA und dem BSI empfohlene Datensparsamkeit, personenbezogene Daten gar nicht erst preiszugeben, wo es vermeidbar ist.

Worauf Sie bei Online-Tools achten sollten

Bevor Sie eine sensible Excel-Datei in ein beliebiges Online-Tool ziehen, lohnt ein kurzer Blick auf vier Fragen:

  • Lokale Verarbeitung? Steht in der Datenschutzerklärung ausdrücklich, dass die Umwandlung im Browser passiert, oder bleibt das vage?
  • Upload? Prüfen Sie im Reiter Netzwerk der Entwicklertools, ob beim Umwandeln eine ausgehende Anfrage mit Ihrer Datei erfolgt. Keine Anfrage bedeutet keine Übermittlung.
  • Serverstandort? Falls hochgeladen wird, wo steht der Server? Außerhalb der EU stellt sich die Frage des Drittlandtransfers.
  • Aufbewahrung? Wie lange werden hochgeladene Dateien gespeichert und wann gelöscht? Unklare oder fehlende Angaben sind ein Warnsignal.
Achtung, kostenlos ist nicht gleich risikolos: Viele kostenlose Online-Konverter laden die Excel-Datei auf einen Server, oft im außereuropäischen Ausland. Geht dort etwas schief, kann das bei Personen- oder Geschäftsdaten eine meldepflichtige Datenpanne nach sich ziehen. Prüfen Sie im Zweifel mit den Entwicklertools, ob Daten nach außen gesendet werden, oder wählen Sie von vornherein ein Werkzeug mit ausdrücklich lokaler Verarbeitung.

Lokal im Browser gegenüber Server-Upload im Überblick

Die folgende Tabelle stellt die beiden Verarbeitungswege Kriterium für Kriterium gegenüber. Sie zeigt, warum die lokale Variante bei schützenswerten Daten der ruhigere Weg ist.

Kriterium Lokal im Browser Server-Upload
Datenübermittlung Nein, Daten bleiben auf dem Gerät Ja, Daten verlassen das Gerät
AVV nach Art. 28 DSGVO Nicht erforderlich In der Regel erforderlich
Drittlandtransfer Entfällt Möglich, Serverstandort prüfen
Eignung für sensible Daten Gut geeignet Heikel, sorgfältige Prüfung nötig
Funktion ohne Internet Ja, nach dem Laden der Seite Nein
Verarbeitungstempo Sofort, lokal gerechnet Abhängig von Upload und Server

Checkliste: Excel korrekt und rechtssicher nach CSV

Wer die folgenden Punkte beachtet, vermeidet die häufigsten technischen Fehler und bleibt auf der datenschutzrechtlich sicheren Seite:

  • Lokale Verarbeitung wählen: Bei personenbezogenen Daten ein Werkzeug nutzen, das die .xlsx im Browser umwandelt und nichts hochlädt.
  • Kodierung auf UTF-8 setzen: Die CSV als UTF-8 ausgeben, damit Umlaute und das ß im Zielsystem erhalten bleiben.
  • BOM vermeiden: Sicherstellen, dass die CSV ohne störendes UTF-8-BOM am Dateianfang geschrieben wird.
  • Richtiges Trennzeichen: Komma oder Semikolon bewusst und passend zum Zielsystem wählen.
  • Quoting prüfen: Ein Werkzeug verwenden, das Felder mit Komma, Anführungszeichen oder Umbruch nach RFC 4180 korrekt umschließt.
  • Ergebnis validieren: Stichprobenartig kontrollieren, ob Spaltenzahl, Überschriften und Sonderzeichen stimmen.

Häufige Fragen

Was ist RFC 4180 und warum ist es beim Excel-Export wichtig?

RFC 4180 ist die 2005 von der IETF veröffentlichte Referenzbeschreibung des CSV-Formats. Sie legt fest, dass Felder mit doppelten Anführungszeichen umschlossen werden, wenn sie selbst ein Trennzeichen, einen Zeilenumbruch oder ein Anführungszeichen enthalten, und dass ein Anführungszeichen im Feld durch Verdoppelung maskiert wird. Wandelt der Konverter Ihre Excel-Tabelle nach diesen Regeln um, landet ein Wert wie Müller, Anna sauber in einem einzigen CSV-Feld und die Spalten verrutschen nicht.

Warum erscheinen meine Umlaute in der CSV als kryptische Zeichen?

Das ist fast immer ein Encoding-Problem. Schreibt der Export die CSV in der älteren Windows-Kodierung Windows-1252 oder Latin-1, liest das Zielprogramm sie aber als UTF-8 (oder umgekehrt), werden ä, ö, ü und ß falsch dekodiert. Aus ä wird dann der bekannte Umlaut-Salat ä. excel-csv.de schreibt die CSV durchgängig als UTF-8, sodass Umlaute aus Ihrer .xlsx erhalten bleiben.

Ist es DSGVO-konform, eine Excel-Datei mit Kundendaten in CSV umzuwandeln?

Das hängt davon ab, wohin die Daten gehen. Laden Sie die .xlsx zu einem Online-Konverter hoch, verlässt sie Ihren Rechner und wird auf einem fremden Server verarbeitet. Das ist eine Übermittlung an einen Dritten, die eine Rechtsgrundlage und in der Regel einen Auftragsverarbeitungsvertrag erfordert. Findet die Umwandlung dagegen vollständig lokal im Browser statt, verlassen die Daten Ihr Gerät nie. Es gibt keinen Empfänger, das ist der datenschutzrechtlich sauberste Weg.

Was ist ein UTF-8-BOM und warum kann es beim CSV-Import stören?

Das Byte Order Mark (BOM) ist eine unsichtbare Bytefolge (EF BB BF) am Dateianfang, die manche Programme einer UTF-8-CSV voranstellen. Beim erneuten Einlesen klebt dieses BOM am ersten Spaltennamen, sodass aus der Überschrift id plötzlich id wird. In manchen Import-Tools führt das zu einer kaputten ersten Spaltenüberschrift. Der Konverter schreibt die CSV ohne störendes BOM, sodass die Kopfzeile sauber bleibt.

Brauche ich für einen lokalen Browser-Konverter einen Auftragsverarbeitungsvertrag?

Nein. Ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO ist nur erforderlich, wenn ein Dienstleister personenbezogene Daten in Ihrem Auftrag verarbeitet, also die Daten an ihn übermittelt werden. Bei reiner Client-seitiger Verarbeitung im Browser werden keine Daten an den Anbieter gesendet, es findet keine Auftragsverarbeitung statt und somit ist auch kein AVV nötig.

Wie erkenne ich, ob ein Online-Tool meine Excel-Datei wirklich nur lokal verarbeitet?

Ein verlässliches Indiz liefert der Reiter Netzwerk in den Entwicklertools des Browsers. Findet beim Umwandeln keine ausgehende Anfrage mit Ihrer Datei statt, bleibt die Verarbeitung lokal. Zusätzlich können Sie die Datenschutzerklärung prüfen und testweise die Internetverbindung trennen: Funktioniert das Tool weiterhin, läuft die Logik im Browser und nicht auf einem Server.

Quellen

Verwandte Artikel

Jetzt Excel sicher in CSV umwandeln

RFC-4180-konformes Quoting, UTF-8 inklusive Umlauten und ohne störendes BOM. Komplett lokal im Browser, ohne Upload und ohne Anmeldung.

Zum Konverter