Cookies für Statistik und Werbung
Wir setzen Cookies für Statistik und Werbung ein, beides geht an Google. Wenn du ablehnst, ändert sich für dich sichtbar nichts.Zur Datenschutzseite
XLSX kannst du hier kostenlos und ohne Konto in TSV umwandeln: Datei oben ablegen, und ein, zwei Sekunden später steht das Ergebnis zum Herunterladen bereit. Die Umwandlung läuft in deinem eigenen Browser, die Datei wird also nie hochgeladen — das klappt unter Windows, macOS und Linux ebenso wie auf iPhone und Android, und es funktioniert selbst dann noch, wenn du das Netz abschaltest.
Bis zu 100 Dateien auf einmal. Gemischte Formate sind kein Problem.
Sie werden nacheinander umgewandelt und kommen zusammen als ZIP zurück.
XLSX in TSV
An einem Forschungsinstitut kommt eine Messreihe oft als Excel-Tabelle von einem Gerät oder aus einer Auftragsverwaltung, weiterverarbeitet wird sie dann aber auf einem Linux-Server per Shell-Pipeline — cut, awk, sort, join, vielleicht ein R-Skript, das per SSH auf einem gemeinsamen Rechencluster läuft. Diese Werkzeuge lesen kein XLSX, und ein Komma als Trenner würde mit Beschreibungstexten kollidieren, die selbst Kommas enthalten.
Tab ist deshalb die pragmatische Wahl, nicht Geschmackssache: Die Spaltengrenzen bleiben eindeutig, ohne dass irgendein Werkzeug eine Quotierungsregel verstehen müsste. Diese Seite liefert genau das — das erste Tabellenblatt als Tabulator-getrennten Text, gebaut im Browser statt auf einem Server, der die Messdaten sonst irgendwo zwischenspeichern würde.
Der Grund, Tabulatoren dem Komma vorzuziehen, ist eng und praktisch. Adressen enthalten Kommas, Probenbeschreibungen enthalten Kommas, in halb Europa formatierte Zahlen enthalten Kommas. In einer kommagetrennten Datei muss jedes davon in Anführungszeichen stehen, und jedes Werkzeug, das die Datei liest, müsste diese Quotierung korrekt auswerten.
Tabulatoren kommen in den Daten selbst kaum vor, Trenner und Inhalt geraten sich also nicht in die Quere. Eine Zelle mit dem Inhalt „Sensor, Kalibrierung" wird hier genau so geschrieben, ohne ein einziges Anführungszeichen in der Zeile. `cut -f2` findet sie, `awk -F"\t"` findet sie. Nichts muss parsen, es muss nur trennen — der ganze Unterschied zwischen einem Einzeiler in der Shell und einer Bibliothek, die Quotierung, verdoppelte Anführungszeichen und Zeilenumbrüche in Feldern versteht.
Gelegentlich landet ein Tabulator selbst in einer Zelle — beim Einfügen aus einer anderen Quelle, aus Versehen getippt, aus einem Geräte-Export übernommen. Genau diese Zelle wird dann in doppelte Anführungszeichen gesetzt, weil sonst die Zeile still um eine Spalte zu viel wüchse.
Das ist korrekte Ausgabe, aber ausgerechnet die Werkzeuge, für die dieses Format gewählt wird, lesen keine Anführungszeichen: `cut -f` zählt Tabulatoren und weiß nichts von Quotierung, sieht ab dieser Zeile also ein Feld zu viel. Produziert eine Pipeline auf einmal versetzte Ausgaben bei wenigen Zeilen, liegt es fast immer daran. Der Fund gehört im Quelltabellenblatt behoben, nicht nachträglich in der Pipeline geflickt — dasselbe gilt für einen Zeilenumbruch in einem Notizfeld, der dieselbe Quotierung erzwingt. Enthält ein Tabellenblatt viel Freitext, ist NDJSON das robustere Ziel, weil dort beide Zeichen innerhalb des Werts maskiert werden.
Eine Arbeitsmappe kann dreißig Tabellenblätter enthalten. Eine Tabulator-getrennte Datei enthält eine einzige Tabelle mit einer Kopfzeile, ohne Syntax für irgendetwas darüber hinaus. Die Umwandlung nimmt deshalb das erste Blatt und lässt den Rest zurück — das einzige Verhalten, das nicht stillschweigend eine ungewollte Verschmelzung erzeugt.
Steht das gewünschte Blatt nicht an erster Stelle, verschieben und neu umwandeln dauert kürzer, als diesen Absatz zu lesen. Sollen mehrere Blätter in mehrere Dateien, lohnt sich ein Durchgang pro Blatt, die Ergebnisse getrennt gehalten — genau das erwartet eine Pipeline ohnehin: zwei Dateien über einen Schlüssel zu verbinden ist ein Befehl, zwei zusammengefügte Tabellen wieder zu trennen ist keiner.
Eine Tabellenkalkulation speichert intern keine Datumsangabe im Textsinn, sondern eine Zahl mit einem Anzeigeformat darüber — das Format bestimmt, dass „01.01.2024" auf dem Bildschirm steht, nicht die gespeicherte Größe selbst. Die Umwandlung liest, was die Zelle tatsächlich enthält, und je nachdem, wie die Spalte in der Arbeitsmappe formatiert war, kann in der TSV-Datei diese rohe Zahl statt eines lesbaren Datums stehen.
Verlassen sollte man sich auf keine der beiden Formen im Voraus — ein Blick in die erste erzeugte Zeile zeigt, welche Form eine bestimmte Spalte tatsächlich angenommen hat. Steht dort eine nackte Zahl, wo ein Datum erwartet wurde, ist nichts kaputt: Die Tabellenkalkulation hat das Datum nie anders gespeichert, das Anzeigeformat hat es nur überdeckt, und die Umrechnung gehört dann an den Zielort, mit der Datumsfunktion des jeweiligen Werkzeugs, statt vorher in der Tabelle nachformatiert zu werden — ein als Text geschriebenes Datum ist ein neues Parsing-Problem statt eines arithmetischen.
Die Kopfzeile liefert die Spaltennamen, und die Spaltenmenge ist die Vereinigung aller Schlüssel über sämtliche Zeilen, nicht nur die der ersten. Ein Tabellenblatt, dessen unterer Teil ein zusätzliches Feld führt, erzeugt trotzdem eine Datei, die dieses Feld im Kopf trägt.
Leere Zellen bleiben leere Felder statt zu verschwinden, jede Zeile behält also dieselbe Anzahl an Tabulatoren, und die Datei bleibt rechteckig — genau das braucht ein positionsbasiertes Werkzeug. Es bedeutet auch, dass ein leeres Feld zwischen „nicht ausgefüllt" und „nicht zutreffend" nicht unterscheidet, was kein getrenntes Format je konnte und keine Umwandlung erfinden kann.
Ein als Text gespeicherter Code kommt mit seinen Nullen an: 007 bleibt 007, eine Probenkennung mit vorangestellten Nullen bleibt unversehrt. Das ist bemerkenswert, weil das Gegenteil so verbreitet ist — eine CSV-Datei, in Excel geöffnet und erneut gespeichert, macht aus solchen Spalten Zahlen, bevor überhaupt umgewandelt wird.
Was diese Umwandlung nicht reparieren kann, ist ein Schaden, der schon vorher entstanden ist. Stand in der Arbeitsmappe selbst schon eine 7 statt einer 007, bleibt es dabei. Die Zellenausrichtung im Quellblatt verrät es meist vorab — Text steht links, Zahlen stehen rechts, und eine Spalte mit gemischter Ausrichtung ist der ungünstigste Fall, weil die Hälfte der Werte als Text und die andere als Zahl behandelt wird.
Zeilen sind durch einen einzelnen Zeilenumbruch getrennt statt durch das Wagenrücklauf-Paar, der Text ist UTF-8 — genau das, was eine Unix-Pipeline, ein Git-Diff und die meisten modernen Importwerkzeuge erwarten. Ein Windows-Werkzeug, das auf der anderen Konvention besteht, liest die Datei meist trotzdem.
Weil die Ausgabe reiner Text ist, übersteht sie auch das Einfügen statt Hochladen — in einen Datenbankclient, ein Formularfeld, eine Nachricht, einen Editor. Das lohnt sich zu wissen, wenn das Ziel eine Importmaske ist, der man nicht traut, aber ein Einfügefeld schon.
Postgres liest diese Form direkt über COPY, und der Punkt, den man kennen sollte: Im Textformat ist ein leeres Feld eine leere Zeichenkette, kein NULL — nur das Zeichen \N bedeutet NULL. Ist die Zielspalte numerisch und die Tabelle hat Lücken, ist genau das die Fehlermeldung, die dabei entsteht.
R liest die Datei mit `read.delim`, das Tabulatoren bereits voraussetzt, pandas mit `sep="\t"`. In beiden Fällen lohnt es sich, Spaltentypen für alles anzugeben, was ein Bezeichner ist statt einer Menge — sonst wendet jedes der beiden Werkzeuge genau die numerische Vermutung an, die aus 007 schon einmal 7 gemacht hat.
Eine Arbeitsmappe merkt sich, welches Blatt beim letzten Speichern aktiv war, und genau das sieht man beim Öffnen zuerst. Das muss nicht dasselbe Blatt sein, das intern als erstes geführt wird — eine Kollegin kann zuletzt auf dem dritten Reiter gearbeitet und gespeichert haben, und die Umwandlung nimmt trotzdem konsequent das ganz linke.
Bei einer Arbeitsmappe mit mehreren Blättern lohnt sich deshalb ein kurzer Blick auf die Reiterleiste von links nach rechts, bevor umgewandelt wird, statt sich auf das zu verlassen, was beim Öffnen gerade zu sehen war. Ein Blatt an die erste Stelle zu ziehen kostet einen Klick und erspart eine Verwechslung, die sich erst am Ergebnis bemerkbar macht.
Einlesen und Schreiben laufen beide im Browser, es gibt also keinen Upload und keine Warteschlange. Eine Tabelle mit fünfzigtausend Zeilen über sechs Spalten wandelt in einem Moment und ergibt rund 1,8 MB Tabulator-Text, aus einer .xlsx-Datei von etwa 4,3 MB.
Die harte Grenze liegt bei 100 MB je Arbeitsmappe, und bis zu hundert Dateien lassen sich auf einmal ablegen. Eine einzelne Messreihe erreicht das selten; wer regelmäßig größere Exporte hat, ist mit einem streamenden Reader in einem Skript besser bedient, weil der die Datei gar nicht erst vollständig in den Arbeitsspeicher laden muss.
CSV, wenn das Ziel eine Importmaske ist, die den Namen ausdrücklich nennt — ein Werkzeug, das CSV sagt, meint das oft wörtlich und akzeptiert keinen anderen Trenner, so sinnvoll er auch wäre. NDJSON, wenn die Werte ihren Typ über die Reise behalten müssen, weil eine getrennte Datei die Zahl 7 nicht von der Zeichenkette „7" unterscheiden kann.
SQL, wenn die Zeilen in eine bereits bestehende Tabelle sollen, Parquet, wenn sie in ein Analysewerkzeug gehen, das wiederholt abgefragt wird. TSV ist die richtige Antwort für den einen Fall, für den diese Seite gedacht ist: Textwerkzeuge, die an einem Zeichen trennen, das in den Daten selbst nicht vorkommen darf.
| XLSX | TSV | |
|---|---|---|
| Vollständiger Name | Excel-Arbeitsmappe | Tab-Separated Values |
| Dateiendung | .xlsx | .tsv, .tab |
| Medientyp | application/vnd.openxmlformats-officedocument.spreadsheetml.sheet | text/tab-separated-values |
| Erstmals veröffentlicht | 2007 | 1993 |
| Herausgegeben von | Microsoft | — |
| Spezifikation | ECMA-376 | IANA text/tab-separated-values |
| Lizenzlage | Offener Standard | Offener Standard |
| Heutiger Stand | Aktuell | Aktuell |
| Öffnet im Browser | Kein Browser | Kein Browser |
| Stattdessen erwogen | CSV, ODS, Parquet | CSV, JSON |
Microsoft Excel und LibreOffice Calc lesen sowohl XLSX als auch TSV — du kannst das Ergebnis also gegen das Original prüfen, ohne ein zweites Programm zu brauchen.
Die beiden zielen auf verschiedene Arbeit: XLSX auf die Bearbeitung, TSV auf den Austausch zwischen Programmen. Das lohnt sich vorher abzuwägen — der Grund, aus dem es das eine gibt, ist meist der Grund, aus dem das andere unpraktisch ist.
XLSX stammt von Microsoft und wurde 2007 veröffentlicht. Festgehalten ist das in ECMA-376 — lohnt sich zu kennen, wenn die Datei das Programm überleben soll, das sie geschrieben hat.
TSV stammt aus 1993, festgehalten in IANA text/tab-separated-values. Microsoft Excel, LibreOffice Calc und pandas lesen das Format.
Nein. Diese Umwandlung läuft vollständig in deinem Browser, die Datei verlässt dein Gerät also nicht. Du kannst das selbst nachprüfen: Öffne den Netzwerk-Tab der Entwicklerwerkzeuge und wandle etwas um. Zu sehen sind die Seite selbst und die Statistik- und Werbeanfragen, mit denen dieser Dienst bezahlt wird — und keine einzige, die deine Datei trägt. Hinter genau diesem Paar steckt SheetJS, ein Tabellenleser und -schreiber in JavaScript; dein Browser lädt das einmal und behält es dann.
Ja. Kein Konto, kein Wasserzeichen und kein Tageskontingent, das sich verbraucht — es läuft auf deinem eigenen Rechner, du darfst also so oft wiederkommen, wie du willst. Dateien bis 100 MB verarbeitet der Browser, 100 auf einmal. SheetJS wird auf deinen Rechner geladen und läuft dort — deshalb gibt es dafür keine Zählung.
XLSX und TSV beschreiben Inhalte auf grundverschiedene Weise. Die Umwandlung ist deshalb ein Nachbau und keine Kopie: originalgetreu, aber nicht Byte für Byte dasselbe. Nur das erste Blatt wird gelesen, und davon nur die Werte. Formeln, Formatierung, Spaltenbreiten und jedes weitere Blatt bleiben zurück.
Für die Umwandlung selbst nicht — sie läuft in dem Browser, den du ohnehin offen hast. Zum Öffnen brauchst du danach das Programm, das auf deinem Gerät üblicherweise Tab-Separated Values anzeigt.