Warum dein CSV in Excel Umlaute und Datumsangaben zerlegt
Veröffentlicht am 10.7.2026 · 17 Min. Lesezeit · Datei-Tools
Daniel Okonkwo — Front-end-Entwickler und Tech-Redakteur bei OneKitly
Web-Performance · Dateiformate
Anhand von 5 Quellen geprüft
Drei getrennte Fehler teilen sich eine Klage, und sie zu verwechseln ist der Grund, warum die üblichen Ratschläge scheitern. Erstens die Kodierung: ein CSV in UTF-8 ohne Byte-Reihenfolge-Marke wird auf vielen Rechnern mit der alten System-Codepage gelesen, sodass die zwei Bytes eines Umlauts als zwei Latin-1-Zeichen statt als eines erscheinen — aus Müller wird Müller, aus Straße wird Straße, aus Grüße wird Grüße. Microsofts eigene Anleitung sagt, ein UTF-8-CSV lasse sich normal öffnen, wenn es mit Byte-Reihenfolge-Marke gespeichert wurde, und nennt für alles andere einen Importweg; diese Marke ist drei Byte lang, EF BB BF, und deshalb erzeugen so viele Exporte eine. Zweitens das Trennzeichen: Microsoft dokumentiert, dass Excel das Windows-Listentrennzeichen als Trennzeichen für .csv-Dateien verwendet und dass das Komma die Voreinstellung des US-englischen Gebietsschemas ist. Wo das Komma das Dezimalzeichen ist, ist das Listentrennzeichen ein Semikolon — eine kommagetrennte Datei landet also in einer einzigen Spalte. Drittens, und das kann hinterher niemand rückgängig machen: Excel errät beim Öffnen für jedes Feld einen Typ. Es macht aus 03/04 ein Datum, streicht die führende Null einer Postleitzahl und behält — Microsoft sagt es unmissverständlich — höchstens 15 signifikante Stellen, sodass eine 16-stellige Referenz gerundet und in wissenschaftlicher Schreibweise angezeigt wird. Das Feld in Anführungszeichen zu setzen verhindert nichts davon, denn Anführungszeichen sind in einem CSV strukturell und keine Typangaben. Die einzige verlässliche Abhilfe ist Importieren statt Öffnen: Daten, dann Aus Text/CSV, die Kodierung auf Unicode (UTF-8) stellen, das Trennzeichen setzen und die Spalten, die Text bleiben müssen, vor dem Laden auf Text stellen. Unter Microsoft 365 und Excel 2024 lassen sich mehrere dieser Umwandlungen zudem dauerhaft unter Datei, Optionen, Daten abschalten.
Hinter demselben Satz verbergen sich drei völlig verschiedene Fehler. Einer ist die Kodierung, einer das Trennzeichen, einer Excel, das beim Öffnen Datentypen errät — und jeder hat eine andere Lösung. So unterscheidest du sie in fünf Sekunden.
Drei Fehler, eine Klage
Der Satz, den man schreibt, ist immer derselbe: die CSV ist kaputt. Gemeint ist eines von drei verschiedenen Dingen, und die drei haben außer der Dateiendung nichts gemeinsam. Die Umlaute sind falsch — ein Kodierungsproblem. Alles steht in der ersten Spalte — ein Trennzeichenproblem. Die Werte stimmen, haben aber die falsche Gestalt: aus 03/04 ist ein Datum geworden, eine Postleitzahl hat ihre Null verloren, eine lange Referenz ist zu etwas mit einem E darin geworden. Das ist weder das eine noch das andere, und es geschieht, nachdem die Datei korrekt gelesen wurde.
Sie zu unterscheiden erfordert einen einzigen Handgriff: das CSV in einem einfachen Texteditor statt in einer Tabellenkalkulation öffnen. Notepad, TextEdit, gedit, irgendetwas, das die Bytes als Text zeigt und nicht hilfreich sein will. In diesem Fenster gibt es keine Spalten, keine Zellen und keine Typen — nur Zeilen mit Zeichen zwischen den Feldern. Sehen die Umlaute dort richtig aus, ist die Datei korrekt und der Fehler liegt ganz daran, wie Excel sie liest. Sehen sie auch dort falsch aus, liegt der Fehler weiter oben, bei dem, was die Datei geschrieben hat, und keine Importeinstellung repariert ihn.
Die Umlaute: drei fehlende Bytes am Dateianfang
In UTF-8 belegt ein Buchstabe ohne Umlaut ein Byte, einer mit zwei. Das ist der ganze Mechanismus. Liest ein Programm eine UTF-8-Datei, hält sie aber für eine alte Ein-Byte-Codepage, zeigt es jedes dieser zwei Bytes als eigenes Zeichen, und die entstehende Verstümmelung ist vollkommen berechenbar. Aus Müller wird Müller, aus Köln wird Köln, aus Übung wird Übung, aus Straße wird Straße und aus Grüße wird Grüße. Jeder Umlaut wächst um genau ein Zeichen, und das erste des Paares ist fast immer ein à — daher das so wiedererkennbare Bild des Schadens.
Die Abhilfe, auf die sich die ganze Branche geeinigt hat, sind drei Bytes ganz am Anfang der Datei: EF BB BF, die UTF-8-Byte-Reihenfolge-Marke. Sie kodiert kein Zeichen und druckt nichts; sie existiert allein, damit ein Leser weiß, was er vor sich hat. Microsofts eigene Seite dazu sagt es in einer Zeile — ein UTF-8-CSV öffnet sich normal, wenn es mit Byte-Reihenfolge-Marke gespeichert wurde — und nennt für Dateien ohne eine solche einen Importweg. Dieser eine Satz erklärt, warum fast jeder Exportknopf, den du je gedrückt hast, eine Datei erzeugt, die mit drei unsichtbaren Bytes beginnt.
Der Konverter dieser Seite fügt keine hinzu. Das CSV, das du bekommst, ist UTF-8 ohne Byte-Reihenfolge-Marke, und das erste Byte der Datei ist das erste Zeichen deiner ersten Spaltenüberschrift. Nach dem Standard ist das genau richtig — RFC 4180 definiert das Format und erwähnt nie eine Marke — und auf einem europäischen Windows-Rechner genau das Falsche zum Doppelklicken. Der Rest dieses Artikels handelt großenteils davon, was mit dieser Tatsache anzufangen ist, und die Kurzfassung lautet: importiere die Datei, statt sie zu öffnen.
Das Trennzeichen: dein Betriebssystem entscheidet, nicht die Datei
Der Name kommagetrennte Werte legt nahe, das Komma gehöre zum Format, und RFC 4180 definiert es auch so. Excel liest nicht das Format, es liest eine Einstellung. Microsofts eigene Fehlersuchseite sagt es ohne Umschweife: das Listentrennzeichen in den Windows-Regionseinstellungen zu ändern wirkt sich auf das Trennzeichen aus, das beim Öffnen oder Speichern einer kommagetrennten Wertedatei verwendet wird, denn Excel nutzt das Windows-Listentrennzeichen als Trennzeichen für .csv-Dateien. Sie ergänzt, dass das Komma die Voreinstellung des US-englischen Gebietsschemas ist.
Dass die Einstellung nicht überall ein Komma ist, ist Arithmetik und keine Vorliebe. Wo das Komma das Dezimalzeichen ist, kann es nicht zusätzlich Felder trennen, ohne Mehrdeutigkeit zu erzeugen: eine Zeile mit einem Preis von tausendzweihundertvierunddreißig Komma fünf wäre von zwei Feldern nicht zu unterscheiden. Windows liefert deshalb in den französischen, deutschen, spanischen, italienischen und portugiesischen Gebietsschemata ein Semikolon als Listentrennzeichen und in den englischen ein Komma. Das ist die ganze Wasserscheide, und deshalb kommt ein von einem amerikanischen Dienst geschriebener Export, in Lyon, Leipzig, León, Livorno oder Lissabon geöffnet, als eine einzige sehr breite Spalte an.
Daraus folgen zwei Dinge, die oft falsch verstanden werden. Erstens: das Windows-Listentrennzeichen zu ändern, um eine Datei zu reparieren, ist eine globale Änderung, die jede Anwendung auf dem Rechner betrifft, und Microsofts eigene Dokumentation warnt davor; es ist kein Mittel pro Datei, und du wirst vergessen, dass du es getan hast. Zweitens: das Trennzeichen ist eine Eigenschaft der Datei, die Einstellung eine Eigenschaft des Lesers — eine Datei ist also nie im Abstrakten richtig oder falsch, sie ist richtig für einen Leser, dem du die Wahrheit gesagt hast. Der Importdialog existiert genau dafür, sie ihm zu sagen.
Die Typen: Excel rät, und es rät beim Öffnen
Ein CSV hat keine Typen. Jedes Feld ist Text, und RFC 4180 gibt Anführungszeichen genau eine Aufgabe: ein Feld zu schützen, das ein Komma, ein Anführungszeichen oder einen Zeilenumbruch enthält. Nirgends im Format lässt sich sagen: dies ist eine Zeichenkette, lass sie in Ruhe. Eine Tabellenkalkulation, die eines öffnet, muss also Feld für Feld raten, und die Vermutungen sind auf den Normalfall zugeschnitten, nicht auf deinen. Ein Feld mit 03/04 sieht nach einem Datum aus und wird eines. Ein Feld mit 01234 sieht nach einer Zahl aus und verliert seine Null. Ein Feld mit sechzehn Stellen sieht nach einer sehr großen Zahl aus, und Microsofts eigene Seite nennt die Grenze ungeschönt: Excel hat eine maximale Genauigkeit von 15 signifikanten Stellen, sodass bei jeder Zahl mit 16 oder mehr Stellen alles nach der fünfzehnten auf null gerundet und der Wert in wissenschaftlicher Schreibweise angezeigt wird.
Der Datumsfall verdient einen eigenen Absatz wegen der Art, wie er scheitert. Ein Feld mit 02/03/2026 ist in Berlin der 2. März und in Chicago der 3. Februar, und beide Lesarten sind legitim — nichts in der Datei sagt, welche gemeint war. Ein Feld mit 13/03/2026 hat dagegen keinen dreizehnten Monat, ein Leser, der den Monat zuerst erwartet, kann es nicht als Datum deuten und lässt es als Text stehen. Schick ein ganzes Jahr an Daten hindurch, und knapp zwei von fünf sind mehrdeutig: 144 der 365 Tage fallen auf den zwölften des Monats oder früher. Die herauskommende Spalte besteht also teils aus stillschweigend vertauschten Daten, teils aus linksbündigem Text — und nirgends eine Fehlermeldung. Das ist der teuerste stille Fehler der Büroarbeit.
Ein Teil des Schadens entsteht, bevor Excel überhaupt beteiligt ist, und dieser Konverter ist daran nicht unschuldig. Eine Tabellenzelle ist ein Rohwert plus ein Anzeigeformat, und das CSV kann nur eines von beiden tragen: geschrieben wird der formatierte Text. Schick denselben 2. März 2026 mit einem Tag-zuerst-Format hindurch, und die Datei bekommt 02/03/2026; schick denselben Wert mit einem Monat-zuerst-Format, und die Datei bekommt 3/2/26. Schlimmer noch: eine sechzehnstellige Kennung in einer Spalte mit Standardformat verlässt die Arbeitsmappe bereits als 1.23457E+15 geschrieben, weil die Mappe sie so anzeigte. Die Kennung hat das Format zerstört, nicht der Leser. Flussabwärts kann sie niemand zurückholen.
Was jeden Fall wirklich behebt
Importieren statt öffnen. Diese eine Änderung behebt die ersten beiden Probleme sofort und gibt dir das Werkzeug für das dritte. Daten, dann Aus Text/CSV, öffnet eine Vorschau, in der Dateiursprung und Trennzeichen beide sichtbar und beide änderbar sind, und die Vorschau zeichnet sich bei jeder Änderung neu: du siehst die Umlaute sich richten und die Spalten sich teilen, bevor du dich festlegst. Daten transformieren statt Laden erlaubt dann, den Datentyp einer Spalte auf Text zu setzen — Microsofts eigene Anleitung zum Erhalten führender Nullen verweist genau auf diesen Weg — und eine als Text typisierte Spalte behält ihre Nullen, behält alle sechzehn Stellen und wird nicht zum Datum.
Es gibt einen neueren und dauerhafteren Hebel, den viel zu wenige kennen. Unter Microsoft 365 und Excel 2024, auf Windows wie auf Mac, enthält Datei, Optionen, Daten einen Abschnitt namens Automatische Datenkonvertierung mit vier Kontrollkästchen: führende Nullen entfernen und in eine Zahl umwandeln; die ersten 15 Stellen langer Zahlen behalten und bei Bedarf in wissenschaftlicher Schreibweise anzeigen; Ziffern rund um den Buchstaben E in wissenschaftliche Schreibweise umwandeln; und datumsähnliche Kombinationen aus Buchstaben und Ziffern in ein Datum umwandeln. Die ersten beiden abzuschalten sind die wertvollsten zehn Sekunden, die jemand mit Referenzdaten in Excel verbringen kann, denn es stoppt die Zerstörung an der Quelle, statt jedes Mal ein Importritual zu verlangen.
Was nicht funktioniert, gehört ebenfalls aufgezählt, denn genau das wird man dir raten. Ein Feld in Anführungszeichen zu setzen hält die Umwandlung nicht auf: Anführungszeichen sind strukturell, sie sagen, wo das Feld endet, und Excel entfernt sie, bevor es zu raten beginnt. Die Datei umzubenennen, damit sie kein .csv mehr ist, ändert den Codepfad, der sie öffnet — ein realer, aber brüchiger Effekt, auf den man sich stützt. Die Spalte nach dem Öffnen als Text zu formatieren bewirkt nichts, denn die Stellen gingen beim Laden verloren, und Microsoft sagt es auch: ein Textformat wirkt nur auf das, was du danach eingibst. Und ein Gleichheitszeichen vor einen in Anführungszeichen gesetzten Wert zu stellen erzwingt zwar Text, macht das Feld aber zu einer Formel statt zu einem Wert, erscheint in jedem anderen Programm, das die Datei liest, als wörtliche Zeichenfolge, und ein führendes Gleichheitszeichen ist der klassische Vektor für Formel-Injektion in Tabellenkalkulationen. Schick das niemandem.
Was dieser Konverter in die Datei schreibt
Aus dem Quelltext gelesen statt aus der Werbung: das Werkzeug Excel in CSV liest deine Arbeitsmappe im Browser, lässt dich ein Blatt wählen und schreibt dieses Blatt mit einem Komma zwischen den Feldern, in UTF-8 und ohne Byte-Reihenfolge-Marke. Felder werden nur dann in Anführungszeichen gesetzt, wenn es nötig ist — wenn sie ein Komma, ein doppeltes Anführungszeichen oder einen Zeilenumbruch enthalten — genau das, was RFC 4180 verlangt, und nicht mehr. Ein Feld mit einem Anführungszeichen bekommt es nach derselben Regel verdoppelt. Nichts wird hochgeladen: die Arbeitsmappe wird auf deinem Rechner geparst, und das CSV verlässt ihn nie.
Zwei dieser Entscheidungen beißen den europäischen Leser, der das Ergebnis doppelklickt, und du solltest wissen, welche. Das Komma packt auf einem Rechner mit Semikolon als Listentrennzeichen alles in Spalte A. Die fehlende Byte-Reihenfolge-Marke zerlegt auf einem Rechner, der auf eine alte Codepage zurückfällt, die Umlaute. Beides heilt dieselbe Importprozedur, und nichts davon heilt es, sich über die Datei zu beklagen, die dem Standard entspricht. Schickst du das CSV an einen Menschen und nicht an ein Programm, nenne Trennzeichen und Kodierung — eine Zeile in der Mail spart einen Nachmittag.
Eine Gewohnheit ist mehr wert als jede Einstellung in diesem Artikel: bring die Arbeitsmappe vor dem Export in Ordnung, nicht das CSV danach. Stelle die Kennungsspalten in der Tabelle auf Text, damit Postleitzahlen und Kontonummern zum Zeitpunkt der Umwandlung schon Zeichenketten sind. Stelle die Datumsspalten auf ein eindeutiges Format — das Jahr zuerst, vierstellig, dann Monat, dann Tag — damit der exportierte Text sich in keinem Gebietsschema der Welt auf zwei Arten lesen lässt. Tu das einmal, und jeder Export aus dieser Mappe ist für jeden Leser sauber, für immer, egal welche Regionseinstellungen er hat.
| Was du siehst | Wirkliche Ursache | Hilft nicht | Hilft |
|---|---|---|---|
| Umlaute als zwei Zeichen dargestellt | UTF-8-Datei als alte Codepage gelesen; keine Byte-Reihenfolge-Marke, die es richtigstellt | Suchen und Ersetzen an den verstümmelten Paaren — das vervielfacht den Schaden | Mit Dateiursprung Unicode (UTF-8) importieren oder mit Byte-Reihenfolge-Marke neu exportieren |
| Jede Zeile steht in Spalte A | Das Trennzeichen der Datei weicht vom Windows-Listentrennzeichen ab, das Excel benutzt | Die Spalte jedes Mal von Hand teilen, wenn die Datei kommt | Importieren und das Trennzeichen in der Vorschau wählen; die Windows-Einstellung zu ändern wirkt global |
| Aus 03/04 ist ein Datum geworden | Excel errät beim Öffnen je Feld einen Typ; ein CSV trägt keine Typen | Das Feld in Anführungszeichen setzen — sie sind strukturell und werden zuerst entfernt | Importieren, die Spalte auf Text stellen; oder Daten als Jahr, Monat, Tag exportieren |
| Eine Postleitzahl hat ihre führende Null verloren | Es sah nach einer Zahl aus, also machte Excel eine daraus | Die Spalte nach dem Laden als Text formatieren — die Nullen sind schon weg | Als Text importieren oder Führende Nullen entfernen unter Datei, Optionen, Daten abschalten |
| Eine 16-stellige Referenz endet auf Nullen oder zeigt ein E | Excel behält 15 signifikante Stellen; der Rest wird auf null gerundet | Die Spalte verbreitern oder das Zahlenformat ändern — die Stellen sind verloren, nicht versteckt | Die Spalte überall als Text führen: eine Kennung ist eine Zeichenkette, keine Zahl |
| Eine Zahl erscheint als 1,234.50 und lässt sich nicht addieren | Das Anzeigeformat der Zelle wurde mitexportiert, samt Trennzeichen | Die Werte im Ziel von Hand neu eintippen | Die Zahlenformate in der Arbeitsmappe vor dem Export entfernen |
Häufige Fragen
- Ich habe die Datei geöffnet und jede Zeile steht in Spalte A. Ist die CSV kaputt?
- Mit ziemlicher Sicherheit nicht. Du siehst Excel, das an einem Zeichen trennt, das deine Datei gar nicht verwendet. Microsoft dokumentiert, dass Excel das Trennzeichen für .csv-Dateien aus dem Windows-Listentrennzeichen nimmt — eine kommagetrennte Datei auf einem Rechner mit Semikolon findet also kein Semikolon und schließt daraus, dass jede Zeile ein einziges riesiges Feld ist. Öffne die Datei in einem Texteditor und sieh dir die erste Zeile an: das Zeichen zwischen den Überschriften ist das wahre Trennzeichen. Schließe sie, geh auf Daten und Aus Text/CSV und wähle dieses Zeichen in der Vorschau. Zwei Dinge lieber nicht: teile die Spalte nicht von Hand, denn nächsten Monat machst du es wieder; und überlege zweimal, bevor du das Windows-Listentrennzeichen änderst, denn Microsofts eigene Dokumentation warnt, dass dies eine globale Änderung für jede Anwendung auf dem Rechner ist.
- Warum verhindert es nicht, dass Excel ein Feld in ein Datum verwandelt, wenn ich es in Anführungszeichen setze?
- Weil Anführungszeichen in einem CSV Interpunktion sind und keine Anmerkung. RFC 4180 gibt ihnen genau eine Aufgabe: zu markieren, wo ein Feld beginnt und endet, wenn das Feld selbst ein Komma, ein doppeltes Anführungszeichen oder einen Zeilenumbruch enthält. Sie tragen keine Information darüber, was das Feld bedeutet, und das Format bietet auch sonst keinen Ort für solche Information — ein CSV kennt tatsächlich keinen Typbegriff. Der Leser entfernt die Anführungszeichen also beim Parsen, genau wie vorgesehen, und beginnt erst danach zu raten, was er da hält. Deshalb liegen alle von Microsoft veröffentlichten Abhilfen auf der Lese- und nicht auf der Schreibseite: die Spalte als Text importieren oder die automatischen Umwandlungen abschalten. Nichts, was du in die Datei schreibst, wird das Raten einschränken.
- Soll ich einfach sep=; in die erste Zeile schreiben, damit Excel es richtig macht?
- In Excel funktioniert es, überall sonst ist es eine Falle. Diese erste Zeile ist eine Excel-eigene Erweiterung: RFC 4180, der das CSV-Format definiert, erwähnt sie nicht, und kein konformer Parser muss sie verstehen. Die Datei wird also für ein Programm leichter und für alle anderen schwerer — ein Skript, ein Datenbankimport, eine Buchhaltungssoftware oder ein Kollege am Mac lesen die Zeile als Datenzeile mit einem Feld namens sep=; und scheitern entweder oder importieren stillschweigend einen Müllsatz an den Kopf deiner Tabelle. Geht die Datei an einen Menschen, der sie in Excel und sonst nirgends öffnet, ist es eine vernünftige Bequemlichkeit. Geht sie in eine Verarbeitungskette oder an jemanden, dessen Werkzeuge du nicht kennst, lass es: schick die Datei sauber und nenne in einem Satz Trennzeichen und Kodierung.
- Meine 16-stellige Referenznummer endet jetzt auf Nullen. Wo sind die Stellen hin?
- Sie wurden weggerundet und sind aus dieser Datei nicht wiederherstellbar. Microsoft nennt die Regel direkt: Excel hat eine maximale Genauigkeit von 15 signifikanten Stellen, und bei jeder Zahl mit 16 oder mehr Stellen wird alles nach der fünfzehnten auf null gerundet. Der Wert erscheint danach in wissenschaftlicher Schreibweise, weil er nicht mehr sinnvoll in die Spalte passt. Wichtig ist: das ist kein Anzeigeproblem — die Spalte zu verbreitern oder das Zahlenformat zu ändern holt die Stellen nicht zurück, denn sie fehlen im gespeicherten Wert. Geh zur Originalquelle zurück, importiere die Spalte als Text, und lass eine Referenznummer, eine Kontonummer, eine Kartennummer oder einen langen Artikelcode nirgends in der Kette als Zahl existieren. Unter Microsoft 365 und Excel 2024 lässt sich die Umwandlung auch ganz abschalten: Datei, Optionen, Daten, und die Option zum Behalten der ersten 15 Stellen langer Zahlen abwählen.
- Komma oder Semikolon — welches ist eigentlich richtig?
- Nach dem Standard das Komma. RFC 4180 definiert das Format mit Kommas zwischen den Feldern, einem Wagenrücklauf plus Zeilenvorschub am Ende jedes Datensatzes und doppelten Anführungszeichen um jedes Feld, das eines davon enthält. Jede Programmiersprache, jede Datenbank und jedes Datenwerkzeug folgt dem — für alles, was eine Maschine liest, ist also das Komma richtig. In der Praxis erwartet eine Tabellenkalkulation in weiten Teilen Kontinentaleuropas jedoch das Semikolon, aus dem arithmetischen Grund, dass das Komma dort schon das Dezimalzeichen ist. Die brauchbare Regel lautet, nach Ziel statt nach Prinzip zu entscheiden: Komma für Maschinen und für alles, was eine Grenze überquert, Semikolon, wenn die Datei direkt in das Excel einer Kollegin geht, deren Regionseinstellungen du kennst. Und was immer du wählst, sag es: eine Zeile mit Trennzeichen und Kodierung verhindert die ganze Problemklasse, um die es in diesem Artikel geht.
Artikel, die dich interessieren könnten
Alle Ratgeber →Ähnliche Tools
Das hier beschriebene Verhalten der Werkzeuge dieser Seite wurde am 13. August 2026 aus ihrem Quelltext gelesen und an den mitgelieferten Bibliotheken gemessen. Das Verhalten einer Tabellenkalkulation hängt von Version, Build und den Regionseinstellungen des Rechners vor dir ab — Microsoft hat mehrere dieser Voreinstellungen geändert. Prüfe also deine eigenen, statt einem Artikel zu glauben, auch diesem nicht.
Quellen
- Microsoft Support — Opening CSV UTF-8 files correctly in Excel — a UTF-8 CSV opens normally if it was saved with a byte order mark, otherwise use the import route
- Microsoft Learn — Formula errors when list separator isn't set correctly — Excel uses the Windows list separator as the delimiter for .csv files; the comma is the US-English default
- Microsoft Support — Keeping leading zeros and large numbers — the 15-significant-digit precision limit, and importing a column as Text through Data, From Text/CSV
- Microsoft Support — Set automatic data conversions — File, Options, Data on Microsoft 365 and Excel 2024, with switches for leading zeros, long numbers, E-notation and date-like text
- IETF — RFC 4180 — the CSV format: comma separators, CRLF records, quoting rules, and the text/csv media type
Hast du einen Fehler in diesem Artikel entdeckt?