CSV in TSV umwandeln

Ein Kontoauszug-Export aus dem Online-Banking der Sparkasse oder einer Volksbank ist praktisch nie mit Kommas getrennt. Excel schreibt in jeder Region, in der das Komma als Dezimaltrennzeichen dient — also im gesamten deutschsprachigen Raum —, stattdessen Semikolons, weil eine Datei, die das Komma für beides verwenden würde, gar nicht lesbar wäre. Wer eine solche Exportdatei zum ersten Mal in ein Skript lädt, das feste Kommas erwartet, bekommt eine einzige riesige Spalte statt einer Tabelle.

Der Parser hier bestimmt das Trennzeichen, indem er die Datei selbst ansieht, nicht ihren Namen, ein Semikolon-Export wandelt sich also um, ohne dass man ihm etwas mitteilen muss. Das scheitert nur bei einer einspaltigen Datei — ohne ein einziges Trennzeichen irgendwo im Text hat die Erkennung nichts, woran sie sich orientieren könnte. Genau dafür gibt es die Trennzeichen-Einstellung auf dieser Seite, und es ist die einzige Situation, in der sie gebraucht wird.

Ein Komma ist aus einem bestimmten Grund ein schlechtes Trennzeichen: Es kommt in echten Daten ständig vor. Adressen enthalten Kommas. Firmennamen mit einem angehängten „GmbH & Co. KG" enthalten mitunter Kommas. Jedes solche Feld muss in Anführungszeichen gesetzt werden, und jeder, der die Datei liest, muss die Regeln dafür korrekt umsetzen — einschließlich doppelter Anführungszeichen innerhalb eines Felds und Zeilenumbrüchen mitten in einem Feld —, bevor er überhaupt wieder Spaltengrenzen findet.

Tabs kommen in der Art von Daten, die man in Tabellen schreibt, fast nie vor, das Trennzeichen und der Inhalt geraten sich also nicht mehr in die Quere. Nach dieser Umwandlung erscheint das Feld „Berlin, Deutschland" genau so in der Datei, ganz ohne Anführungszeichen in der Zeile, und alles, was auf Tabs aufteilt, bekommt es unverändert zurück. Das ist der eigentliche Nutzen — eine Frage der Zuverlässigkeit, nicht der Größe oder der Geschwindigkeit.

Die Einstellung bietet automatische Erkennung, Komma, Semikolon, Tab und Pipe. Automatisch ist fast immer richtig, weil eine Datei mit mehreren Spalten der Erkennung genug Anhaltspunkte liefert und sie diese zuverlässig liest.

Explizit gesetzt wird das Trennzeichen in zwei Fällen. Erstens bei einer einspaltigen Datei, wo es nichts zu erkennen gibt. Zweitens bei einer Datei, in der ein Feld voller falscher Zeichen steckt — etwa eine Notizspalte voller Semikolons in einem eigentlich mit Komma getrennten Export —, was die Erkennung dazu bringen kann, das häufigere statt des richtigen Zeichens zu wählen. Zeigt die Vorschau eine Spalte, wo sechs erwartet wurden, oder umgekehrt, ist das die erste Einstellung, die zu ändern ist.

Tabs innerhalb von CSV-Feldern kommen vor, meist weil jemand aus einer Webseite oder einer anderen Tabelle in eine Zelle eingefügt hat. In der Quelldatei ist das harmlos — das Trennzeichen ist ein Komma, der Tab also nur ein gewöhnliches Zeichen. In der Ausgabedatei ist er das nicht mehr, und die Umwandlung löst das, indem sie genau dieses Feld in Anführungszeichen setzt.

Das Ergebnis ist korrekt, und ein vollständiger Parser kommt damit zurecht. Das Problem ist, dass TSV meist genau von Leuten gewählt wird, die keinen vollständigen Parser einsetzen — `cut -f` zählt Tab-Zeichen und kennt kein Anführungszeichen, ab dieser Zeile sieht das Skript also ein Feld zu viel, und jede folgende Spalte verschiebt sich um eins. Wenn eine Pipeline bei einer Handvoll Zeilen unter Tausenden falsch ausgerichtete Ergebnisse liefert, ist das fast immer der Grund. Tabs vor der Umwandlung aus der Quelle zu entfernen, ist einfacher, als es später zu flicken.

Ein mit Semikolon getrennter deutscher Export schreibt meist 1234,56, wo eine englischsprachige Datei 1234.56 schreibt. Die Umwandlung übersetzt das nicht, und das ist richtig so: Sie hat keine Möglichkeit zu wissen, ob 1.234 eins und ein bisschen bedeutet oder eintausendzweihundertvierunddreißig, und ein Raten würde jeden Preis in der Datei verfälschen.

Stattdessen bleibt der Wert genau so stehen, wie er geschrieben wurde, und weil er der Erkennung nicht wie eine Zahl vorkommt, bleibt er Text. Eine deutsche Preisspalte kommt also unversehrt durch die TSV, und was die Datei als Nächstes liest, muss über die Dezimalkonvention informiert werden. In R ist das `dec = ","` beim Einlesen, in pandas `decimal=","`. Das ist sicherer, als in der Datei per Suchen-und-Ersetzen selbst umzuschreiben, wobei auch die Tausendertrennzeichen und alle Kommas in Textspalten mit erwischt würden.

Die Umwandlung ist keine reine Ersetzung eines Zeichens durch ein anderes. Die Datei wird in Zeilen zerlegt und neu geschrieben, und dabei werden Werte, die wie Zahlen aussehen, auch als Zahlen gelesen. `1e5` wird zu 100000. `true` und `false` werden zu Wahrheitswerten und als solche in Kleinbuchstaben zurückgeschrieben. Ein leeres Feld wird zu null und als leeres Feld wieder ausgegeben — der einzige Fall, in dem sich sichtbar nichts ändert.

Das Opfer davon ist die führende Null. Eine Postleitzahlenspalte mit 01234 kommt in der TSV als 1234 an, und eine mit Nullen aufgefüllte Artikelnummer verliert diese Auffüllung ohne Warnung. Der Test, ob eine Spalte gefährdet ist: Würde es Sinn ergeben, zwei ihrer Werte zu addieren? Postleitzahlen, Telefonnummern, Kontonummern und Artikelnummern bestehen diesen Test nicht. Solche Spalten lohnt ein Blick in der Ausgabe, bevor sie irgendwo weiterverwendet wird.

Felder werden in der TSV nur dann in Anführungszeichen gesetzt, wenn es nötig ist: bei einem Tab, einem doppelten Anführungszeichen oder einem Zeilenumbruch im Feld. Alles andere steht unmarkiert da. Eine CSV, die grundsätzlich jedes Feld in Anführungszeichen setzt — manche Exportprogramme tun das ohne Bedingung —, kommt danach fast ohne Anführungszeichen aus, was bei einer breiten Tabelle spürbar Platz spart und die Lesbarkeit beim Öffnen deutlich verbessert.

Ein doppeltes Anführungszeichen innerhalb eines Felds, das ohnehin markiert werden muss, wird verdoppelt — dieselbe Konvention wie bei CSV. Das lohnt zu wissen, wenn die Datei irgendwo landet, das naiv aufteilt, denn ein Freitextfeld mit Anführungszeichen ist der andere Fall, der in einem Format ein markiertes Feld erzeugt, wo es niemand erwartet.

Zeilen werden mit einem einzelnen Zeilenumbruch statt einem Wagenrücklauf-Zeilenumbruch-Paar getrennt, der Text ist UTF-8 ohne Byte-Order-Mark. Das erwartet eine Unix-Pipeline ebenso wie ein Git-Diff, R und pandas, und die meisten Windows-Werkzeuge akzeptieren es inzwischen ebenfalls.

Das Fehlen der Byte-Order-Mark hat eine konkrete Folge: Ein Doppelklick auf die Datei zum Öffnen in Excel unter Windows zeigt Umlaute dann als Zeichensalat, weil Excel ohne diese Markierung auf die Systemkodierung zurückfällt. Über Daten, Daten abrufen, Aus Text/CSV und der Auswahl UTF-8 lässt sich das umgehen. Ist Excel das eigentliche Ziel statt eines Skripts, entfällt die Frage ganz, wenn stattdessen nach XLSX umgewandelt wird.

Beide Formate sind reiner Text, beide Leser sind reines JavaScript, die Umwandlung läuft also vollständig auf dieser Seite ab. Keine Anfrage trägt die Datei irgendwohin, es gibt keine Warteschlange und keine Stufe — was zählt, weil ein Kontoauszug oder eine Kundenliste selten eine Datei ist, die man gern zum Hochladen erklären möchte.

Die kostenlose Stufe nimmt Dateien bis 100 MB an, was für einen Kontoauszug oder eine Kundenliste in aller Regel weit reicht. Die Datei wird zeilenweise eingelesen, und die ganze Tabelle liegt vor dem Schreiben vollständig im Speicher vor, weshalb einige Dutzend Megabyte problemlos funktionieren, auch innerhalb dieser Grenze. Für eine Datei, die die 100 MB überschreitet, ist ein streamender Parser in einem Skript das richtige Werkzeug, und das zu sagen ist ehrlicher, als bei einem sehr großen Export mittendrin abzubrechen.

Verlangt ein Importbildschirm ausdrücklich CSV, bleibt die Datei am besten eine CSV. Überraschend viele Uploadformulare meinen das wörtlich und weisen eine tabgetrennte Datei zurück, so sinnvoll die Wahl auch wäre — mit einem Uploadformular zu diskutieren, ist kein Kampf, den man gewinnt.

Eine tabgetrennte Ausgabe zahlt sich aus, wenn etwas die Datei nach einem Zeichen aufteilt statt sie zu parsen: eine Shell-Pipeline, ein R-Skript, ein Einfügen in ein Programm mit tabgetrenntem Import, ein schneller Blick mit `cut`. Sollen die Werte dagegen auf dem ganzen Weg ihren Typ behalten, hilft kein getrenntes Format — ein Text kann die Zahl 7 nicht von der Zeichenkette „7" unterscheiden —, und JSON, NDJSON oder Parquet ist das ehrlichere Ziel.