RFC 4180, UTF-8 und Datenschutz: CSV-Daten rechtssicher zu JSON konvertieren

CSV-Dateien enthalten oft genau die Daten, die besonders schützenswert sind: Kundenlisten, Mitarbeiterdaten, Bestellungen mit Namen und Adressen. Wer solche Daten zu JSON konvertiert, sollte zwei Dinge sicherstellen. Erstens, dass das Ergebnis technisch korrekt ist, also dem CSV-Standard RFC 4180 folgt und sauber in UTF-8 kodiert bleibt. Zweitens, dass dabei kein Datenschutzverstoß passiert, weil sensible Daten unbedacht auf einen fremden Server hochgeladen werden. Dieser Ratgeber bringt beide Ebenen zusammen.

RFC 4180: der Standard hinter dem CSV-Format

CSV wirkt simpel: Werte, getrennt durch Kommas, eine Zeile pro Datensatz. Doch genau diese scheinbare Einfachheit erzeugt in der Praxis Probleme, sobald ein Wert selbst ein Komma, ein Anführungszeichen oder einen Zeilenumbruch enthält. Damit Programme 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, getrennt durch CRLF (Wagenrücklauf und Zeilenvorschub).
• Eine optionale Kopfzeile mit den Spaltennamen darf am Anfang stehen.
• Felder werden durch Kommas getrennt, die letzte Spalte ohne nachfolgendes Komma.
• Felder dürfen in doppelte Anführungszeichen gesetzt werden, müssen es aber, wenn sie ein Komma, ein Anführungszeichen oder einen Zeilenumbruch enthalten.
• Ein Anführungszeichen innerhalb eines umschlossenen Feldes wird durch Verdoppelung maskiert.

Das sogenannte Quoting ist der Punkt, an dem laienhafte Konverter scheitern. Betrachten Sie diesen Datensatz, bei dem ein Name selbst ein Komma enthält und eine Notiz Anführungszeichen:

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

Ein RFC-4180-konformer Parser erkennt hier korrekt drei Spalten und liest den Zeilenumbruch innerhalb des Feldes als Teil des Wertes, nicht als neuen Datensatz. Das Ergebnis als JSON:

[
  { "id": 1, "name": "Müller, Anna", "notiz": "Sie sagte \"ja\"" },
  { "id": 2, "name": "Bjørn Maaß", "notiz": "Zeile mit\nUmbruch" }
]

Ein simpler Konverter, der nur stur an jedem Komma trennt, würde aus "Müller, Anna" zwei Felder machen und die ganze Zeile verschieben. Genau deshalb lohnt sich ein Werkzeug, das das Quoting nach RFC 4180 beherrscht.

UTF-8 und das Problem mit dem BOM

CSV und JSON sind beide reiner Text, und Text braucht eine Zeichenkodierung. Die JSON-Spezifikation (RFC 8259) schreibt UTF-8 für den Datenaustausch zwingend vor. UTF-8 kann alle Zeichen darstellen, von deutschen Umlauten über das ß bis zu Emojis oder kyrillischer Schrift, und ist heute der De-facto-Standard im Web.

Probleme entstehen, wenn eine CSV in einer anderen Kodierung gespeichert wurde. Speichert ein älteres Programm oder Excel die Datei als Windows-1252, werden Umlaute bei der späteren Interpretation als UTF-8 falsch dekodiert. Aus Köhler wird dann Kö�hler oder ein Fragezeichen. Die einzige zuverlässige Abhilfe ist, die Datei von Anfang an als UTF-8 zu speichern.

Ein zweiter, tückischer Stolperstein ist das Byte Order Mark (BOM). Speichert deutsches Excel eine Datei als CSV UTF-8, stellt es drei unsichtbare Bytes (EF BB BF) an den Anfang. Diese Markierung ist im Editor nicht sichtbar, klebt beim Einlesen aber am ersten Spaltennamen. So entsteht aus dem sauberen Schlüssel id der unbrauchbare Schlüssel id, den Sie im Code nicht zuverlässig ansprechen können.

Lokale Verarbeitung gegenüber Upload: der entscheidende Unterschied

Der wichtigste Unterschied zwischen einem datenschutzkonformen und einem riskanten Konverter ist nicht das Aussehen, sondern der Weg, den die Daten nehmen. Entweder bleiben sie im Browser, oder sie werden zu einem Server hochgeladen.

Warum lokale Verarbeitung DSGVO-konform ist

Die Datenschutz-Grundverordnung (DSGVO) regelt die Verarbeitung personenbezogener Daten. Sobald eine CSV mit Namen, Adressen oder anderen Personenbezügen zu einem Online-Tool hochgeladen wird, geschieht zweierlei: Die Daten werden an einen Empfänger übermittelt, und dieser verarbeitet sie auf seinem Server. Damit greifen die zentralen Pflichten der Verordnung.

Verarbeitet ein Dienstleister diese Daten in Ihrem Auftrag, brauchen Sie nach Artikel 28 DSGVO einen Auftragsverarbeitungsvertrag (AVV). Sie müssen außerdem eine Rechtsgrundlage nach Artikel 6 nachweisen und die Betroffenen über den Empfänger informieren. Liegt der Server außerhalb der EU, kommt die Frage des Drittlandtransfers hinzu. Für eine schnelle Konvertierung ist das ein erheblicher Aufwand, und bei sensiblen Daten ein echtes Risiko.

Findet die Umwandlung dagegen vollständig im Browser statt, sieht die Lage grundlegend anders aus. Die CSV wird lokal von JavaScript auf Ihrem eigenen Gerät verarbeitet. Es gibt keinen Upload, keinen Empfänger und keine Übermittlung an einen Dritten. Das deutsche BSI empfiehlt nach dem Prinzip der Datensparsamkeit, personenbezogene Daten gar nicht erst preiszugeben, wo es vermeidbar ist. Eine reine Client-seitige Verarbeitung erfüllt dieses Prinzip im Idealfall, weil schlicht nichts das Gerät verlässt.

Genau diesen Weg geht unser CSV zu JSON Converter: Die gesamte Logik läuft im Browser, Ihre Daten werden zu keinem Zeitpunkt an einen Server gesendet. Für sensible Personen- oder Geschäftsdaten ist das der sauberste und einfachste Weg, weil weder AVV noch Drittlandprüfung anfallen.

Online-Upload gegenüber lokaler Verarbeitung im Überblick

Checkliste: CSV rechtssicher und korrekt zu JSON

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 im Browser rechnet und nichts hochlädt.
• Kodierung auf UTF-8 setzen: Die CSV als UTF-8 speichern, damit Umlaute und das ß erhalten bleiben.
• BOM entfernen lassen: Sicherstellen, dass ein eventuelles UTF-8-BOM am Dateianfang automatisch entfernt wird.
• Richtiges Trennzeichen: Komma oder Semikolon bewusst wählen, besonders bei deutschen Excel-Exporten.
• Quoting prüfen: Ein Werkzeug verwenden, das umschlossene Felder nach RFC 4180 korrekt verarbeitet.
• Ergebnis validieren: Stichprobenartig kontrollieren, ob Spaltenzahl, Typen und Sonderzeichen stimmen.

Häufig gestellte Fragen

Quellen und Standards

• IETF: RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files
• IETF: RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format
• EUR-Lex: Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), insbesondere Art. 6 und Art. 28
• The Unicode Consortium: FAQ zu UTF-8, UTF-16 und dem Byte Order Mark (BOM)
• BSI: Bundesamt für Sicherheit in der Informationstechnik, Hinweise zur Datensicherheit
• MDN Web Docs: UTF-8 als Standard-Zeichenkodierung im Web

Verwandte Artikel