Warum Ihre CSV in Excel falsch dargestellt wird und wie Sie die Kodierung beheben (Anleitung 2026)

Diagnose in 30 Sekunden: Ihre Daten sind nicht beschädigt, sondern werden nur falsch gelesen

Als Erstes sollten Sie klären, ob die Daten beschädigt sind oder nur falsch angezeigt werden, wenn eine CSV-Datei mit wirren Zeichen geöffnet wird, denn die beiden Fälle erfordern sehr unterschiedliche Lösungen, und die falsche Lösung kann aus einem Anzeigeproblem einen echten Datenverlust machen. Hier ist der Test in 30 Sekunden. Öffnen Sie dieselbe Datei in einem einfachen Texteditor, also in Editor unter Windows oder in TextEdit im Nur-Text-Modus auf einem Mac, oder in Google Tabellen über Datei und dann Importieren. Wenn die Zeichen dort korrekt aussehen, sind Ihre Daten intakt und nur die Anzeige in Excel ist falsch. Die Datei auf der Festplatte enthält die richtigen Bytes, und Excel entschlüsselt sie lediglich mit der falschen Kodierung. Das ist der häufige Fall, und jede Lösung in dieser Anleitung geht von ihm aus.

Der zweite Hinweis ist, welche Zeichen falsch sind. Wenn einfacher englischer Text, Zahlen und Satzzeichen korrekt aussehen, aber Akzente, Umlaute, Cedillen, das Eurozeichen und nichtlateinische Schriften falsch aussehen, dann liegt eine Kodierungsabweichung vor, kein Trennzeichenproblem und keine Beschädigung. Ein Trennzeichenproblem packt ganze Zeilen in eine Spalte. Eine Beschädigung verwürfelt alles oder lässt Zeilen verschwinden. Ein Kodierungsproblem ist gezielt: Es beschädigt genau die Zeichen, die in UTF-8 mehr als ein Byte benötigen, und lässt alles andere unberührt. Wenn Ihre Datei José zeigt, wo José stehen sollte, oder München, wo München stehen sollte, dann ist dieses Muster der Fingerabdruck dafür, dass UTF-8-Bytes als ältere Ein-Byte-Kodierung gelesen wurden, und es verrät Ihnen sowohl die Ursache als auch die Lösung.

Die dritte Prüfung entscheidet, ob eine Rettung noch möglich ist. Wenn die verwürfelten Zeichen auch im Texteditor sichtbar sind, wurde die Datei selbst möglicherweise nach dem falschen Lesen erneut gespeichert, und die falschen Zeichen stehen jetzt in der Datei. Geraten Sie noch nicht in Panik, und vor allem speichern Sie das Original nicht erneut darüber. Der Abschnitt zur Rettung weiter unten in dieser Anleitung behandelt genau diesen Fall, einschließlich der einen Situation, in der die Zeichen wirklich nicht wiederherstellbar sind: Wenn ein Zeichen bei einem Speichern durch ein Fragezeichen oder ein Ersatzsymbol ersetzt wurde, ist die ursprüngliche Information aus dieser Kopie verschwunden, und nur die Quelldaten können sie neu erzeugen. Bis Sie geprüft haben, was vorliegt, lassen Sie die Originaldatei unberührt, arbeiten Sie mit einer Kopie, und speichern Sie eine verwürfelte Datei niemals über die gute Datei zurück.

Warum Excel falsch rät: Eine CSV-Datei trägt keine Kodierungsangabe

Um zu verstehen, warum das immer wieder passiert, brauchen Sie eine Tatsache über das CSV-Format: Eine CSV-Datei ist einfacher Text ohne Kopfzeile, die angibt, welche Kodierung sie verwendet. Eine Tabellenkalkulationsdatei bringt ihre Struktur und ihre Textkodierung mit. Eine CSV-Datei bringt beides nicht mit. Sie ist nur Bytes, Kommas und Zeilenumbrüche. Wenn ein Programm sie öffnet, muss das Programm entscheiden, wie es diese Bytes in Zeichen verwandelt, und verschiedene Programme entscheiden unterschiedlich. Moderne Texteditoren und Google Tabellen erkennen UTF-8 in den meisten Fällen automatisch, weshalb dieselbe Datei dort korrekt aussieht. Excel erkennt beim Doppelklick auf eine CSV-Datei nichts. Es nimmt die Standardkodierung Ihres Systems an, die auf vielen Windows-Systemen eine ältere Codeseite wie Windows-1252 ist, und es prüft nicht, ob diese Annahme richtig war.

Diese Annahme ist das ganze Problem. UTF-8 stellt ein Zeichen wie é als zwei Bytes dar und ein Zeichen wie € als drei Bytes. Eine ältere Ein-Byte-Kodierung liest jedes Byte als eigenes Zeichen, sodass aus einem é zwei falsche Zeichen werden, nämlich é, und aus einem € drei, nämlich €. Die Datei hat sich nicht verändert. Der Leser hat die Bedeutung der Bytes verändert. Deshalb folgt das Problem auch einem Muster nach Region und nach Rechner. Eine Kollegin auf einem System, dessen Standardkodierung zur Datei passt, sieht sie korrekt, während Sie wirre Zeichen sehen, und dieselbe Datei kann auf einem Rechner korrekt und auf einem anderen defekt aussehen. Kein Rechner ist defekt, und die Datei ist nicht beschädigt. Die beiden Leser sind sich nur uneinig darüber, was die Bytes bedeuten, und Excel vertraut beim Doppelklick seiner eigenen Voreinstellung, ohne zu fragen.

Das erklärt auch, warum dieses Problem so oft bei Dateien auftritt, die aus JSON umgewandelt wurden. JSON ist per Definition UTF-8, sodass eine Umwandlung von JSON in CSV naturgemäß eine UTF-8-CSV erzeugt, einschließlich aller Akzente in Namen, Städten und Währungssymbolen aus den Quelldaten. Die Umwandlung ist korrekt. Das Öffnen ist nicht passend. Der Konverter auf dieser Seite lädt zum Beispiel einfaches UTF-8 ohne Byte-Order-Mark herunter, was die richtige Wahl für Web-Uploads, Datenbanken, Google Tabellen und Python ist, aber es bedeutet, dass ein Doppelklick in Excel unter Windows möglicherweise die falsche Kodierung rät. Wenn Sie wissen, dass die Abweichung beim Öffnen liegt und nicht bei der Umwandlung, wissen Sie auch, wo Sie sie beheben: beim Import oder mit einer BOM, wie die nächsten Abschnitte zeigen.

Die wirren Zeichen lesen: Was die seltsamen Zeichen verraten

Verwurschtelter Text ist nicht zufällig, und wenn Sie lernen, ihn zu lesen, verrät er Ihnen das ursprüngliche Zeichen und bestätigt die Diagnose, bevor Sie irgendetwas anfassen. Das kennzeichnende Muster ist Ã, gefolgt von einem weiteren Zeichen. Immer wenn Sie é, ä, ü oder ç sehen, betrachten Sie ein UTF-8-Zeichen, das als Windows-1252 gelesen wurde. Das à ist das erste Byte der UTF-8-Folge, das als eigenes Zeichen falsch gelesen wurde, und das zweite Zeichen ist das zweite Byte, das ebenfalls falsch gelesen wurde. Wenn Sie das Muster einmal kennen, können Sie die wirren Zeichen im Kopf entschlüsseln: Aus é wurde é, aus ü wurde ü, aus ç wurde ç, aus ão wurde ão, wie bei São Paulo, das als São Paulo erscheint. Das Eurozeichen ist der dramatischste Fall: € besteht in UTF-8 aus drei Bytes, sodass es als die drei Zeichen € erscheint. Ein Gedankenstrich erscheint als â€, und ein geschweiftes Apostroph erscheint als ’.

Das Muster ändert sich mit der Schrift, und diese Änderung ist ebenfalls ein Diagnosehinweis. Lateinische Namen erzeugen das Ã-Muster von oben. Japanische, koreanische und andere nichtlateinische Schriften erzeugen längere wirre Zeichen, denn jedes Zeichen besteht in UTF-8 aus drei Bytes, sodass aus einem Zeichen drei falsche werden: Tokio, geschrieben als 東京, erscheint als eine Folge von Zeichen wie æ±äº¬, und ein koreanischer Name wird zu einer ähnlichen Folge. Wenn Sie solche langen wirren Zeichen sehen, ist die Diagnose dieselbe, nämlich UTF-8, gelesen als Ein-Byte-Kodierung, nur dass die beteiligten Zeichen Drei-Byte-Zeichen sind. Wenn Sie stattdessen Fragezeichen oder schwarze rautenförmige Ersatzsymbole sehen, wo Zeichen stehen sollten, ist die Diagnose eine andere: Diese Symbole bedeuten, dass Informationen bereits bei einem Speichern verloren gegangen sind und nicht nur bei der Anzeige falsch gelesen wurden, und der Abschnitt zur Rettung behandelt dann, was zu tun ist.

Der Codeblock unten zeigt die genauen Falschlesungen, die erzeugt wurden, indem korrekter UTF-8-Text als Windows-1252 entschlüsselt wurde, so wie Excel es beim Doppelklick tut. Das sind keine erfundenen Beispiele. Jedes Paar wurde mechanisch erzeugt, sodass Sie Ihre eigene Datei damit abgleichen und die Diagnose bestätigen können, bevor Sie irgendetwas beheben. Wenn Ihre Datei die linke Seite eines dieser Paare zeigt, wo die rechte Seite stehen sollte, liegt eine Kodierungsabweichung vor, und die Importlösung im nächsten Abschnitt repariert die Anzeige, ohne die Datei zu verändern.

Correct text  ->  What Excel shows\nJosé García  ->  José GarcÃ\u00ada\nMünchen      ->  München\nFrançois     ->  François\nSão Paulo    ->  São Paulo\n€50,000      ->  €50,000\ncafé — ok    ->  café — ok\n東京 (Tokyo)  ->  æ\u00b1京\n김민준        ->  김민준

Beachten Sie, was die Tabelle beweist: Es fehlt nichts. Jedes falsche Zeichen entspricht einem echten Byte des Originals, nur mit der falschen Tabelle entschlüsselt. Deshalb funktioniert die Importlösung so vollständig. Wenn Sie Excel sagen, dass die Datei UTF-8 ist, entschlüsselt es dieselben Bytes mit der richtigen Tabelle, und jedes Zeichen springt zu sich selbst zurück, ohne Bearbeiten, ohne Suchen und Ersetzen und ohne Dateneingabe. Wenn Ihre Datei zu diesem Muster passt, überspringen Sie den Abschnitt zur Rettung und gehen Sie direkt zur Importlösung. Sie haben keine beschädigte Datei. Sie haben eine falsch gelesene Datei.

Lösung 1: Die Datei importieren und Excel sagen, dass sie UTF-8 ist

Das ist die Lösung, die Sie zuerst versuchen sollten, denn sie verändert nichts an Ihrem System, nichts an der Datei, und sie funktioniert bei jeder UTF-8-CSV, unabhängig vom Trennzeichen. Statt auf die Datei zu doppelklicken, öffnen Sie zuerst Excel und importieren die Datei dann über den geführten Import, bei dem Sie die Kodierung selbst wählen. Die Vorschau im Importdialog zeigt Ihnen sofort, ob Sie richtig gewählt haben: Die Zeichen werden in der Vorschau genau so korrekt angezeigt, wie sie später auf dem Blatt stehen. Wenn die Vorschau weiterhin wirre Zeichen zeigt, haben Sie noch nichts verändert, und Sie können vor dem Laden eine andere Dateiherkunft ausprobieren.

• ▸Öffnen Sie in Excel Daten und dann Aus Text/CSV, und wählen Sie Ihre Datei.
• ▸Setzen Sie im Vorschaudialog die Dateiherkunft auf 65001: Unicode (UTF-8). In älteren Excel-Versionen erscheint dieselbe Option als Unicode (UTF-8) im Textimport-Assistenten.
• ▸Prüfen Sie die Vorschau. Wenn die Zeichen jetzt korrekt gelesen werden, fahren Sie fort. Wenn sie weiterhin falsch aussehen, ist die Datei möglicherweise gar kein UTF-8, also probieren Sie die anderen Herkünfte in der Liste nacheinander aus und beobachten Sie die Vorschau.
• ▸Setzen Sie das Trennzeichen auf das Zeichen, das die Datei verwendet, also Komma, Semikolon, Tabulator oder Pipe, und prüfen Sie, ob die Spalten in derselben Vorschau korrekt getrennt werden.
• ▸Klicken Sie auf Laden. Für Spalten, die als Text bleiben müssen, wie Codes mit führenden Nullen, stellen Sie diese Spalten im Importschritt auf Text ein, bevor Sie laden.

Machen Sie dies zu Ihrer Standardmethode zum Öffnen von CSV-Dateien und nicht nur zu Ihrem Rettungsschritt. Ein Doppelklick ist eine Vermutung über Trennzeichen und Kodierung zugleich. Ein Import ist eine Entscheidung über beides, und die Entscheidung dauert etwa zehn Sekunden länger. Dieselbe Lösung funktioniert auf einem Mac, wo der Importweg ebenfalls der zuverlässige ist: Öffnen Sie eine leere Arbeitsmappe, gehen Sie zu Daten und dann Aus Text, wählen Sie die Datei, wählen Sie Unicode (UTF-8) als Dateiherkunft und schließen Sie ab. Google Tabellen braucht in den meisten Fällen überhaupt keine Lösung, denn Datei und dann Importieren erkennt UTF-8 automatisch, weshalb eine Datei, die in Excel defekt aussieht, in Tabellen oft perfekt aussieht. Dieser Unterschied ist selbst eine Diagnose: Wenn Tabellen sie richtig zeigt und Excel sie falsch zeigt, ist die Datei in Ordnung und Excel hat falsch geraten.

Lösung 2: Eine BOM hinzufügen, damit der Doppelklick funktioniert

Wenn Sie jeden Tag dieselbe Art von Datei öffnen, wird das jedesmalige Importieren lästig, und die dauerhafte Lösung ist, Excel den Hinweis zu geben, den es beim Doppelklick braucht. Dieser Hinweis ist eine BOM, eine Byte-Order-Mark: drei unsichtbare Bytes ganz am Anfang der Datei, die sagen, dass diese Datei UTF-8 ist. Excel prüft auf eine BOM, bevor es rät, sodass eine UTF-8-Datei mit BOM auch auf einem Windows-System, dessen Standardkodierung Windows-1252 ist, beim Doppelklick korrekt geöffnet wird. Die BOM ist in Excel und in den meisten Editoren unsichtbar, und sie verändert keine Datenzeile. Sie betrifft nur die ersten drei Bytes der Datei.

Der einfachste Weg, eine hinzuzufügen, braucht keinen Code. Öffnen Sie die Datei in Editor, gehen Sie zu Datei und dann Speichern unter, und stellen Sie das Kodierungsmenü auf UTF-8 mit BOM ein, dann speichern Sie. Die Datei wird jetzt beim Doppelklick in Excel korrekt geöffnet. Wenn Sie Dateien aus einem Skript erzeugen, fügen Sie die BOM stattdessen beim Schreiben hinzu, anstatt Dateien nachträglich zu korrigieren. In Python ist das ein Wort: Öffnen Sie die Datei mit der Kodierung utf-8-sig statt utf-8, und Python schreibt die BOM für Sie. Das Snippet unten zeigt es, und die Bytes, die es erzeugt, wurden geprüft: Die Datei beginnt mit den drei BOM-Bytes, gefolgt von den Daten in einfachem UTF-8.

with open("customers.csv", "w", encoding="utf-8-sig", newline="") as f:\n    f.write("name,city\n")\n    f.write("José García,München\n")\n# First bytes of the file: EF BB BF, then the UTF-8 data.\n# Excel now opens it correctly on double-click.

Zwei Warnhinweise, bevor Sie überall eine BOM hinzufügen. Erstens behandeln manche Werkzeuge eine BOM als Daten und nicht als Markierung. Ein strenger CSV-Parser liest die erste Kopfzeile möglicherweise als BOM plus Name statt als Name, was eine Suche nach der Kopfzeile scheitern lässt. Der Konverter auf dieser Seite lädt aus genau diesem Grund bewusst ohne BOM herunter: Einfaches UTF-8 ist korrekt für Web-Uploads, Datenbanken und Python, und die BOM ist nur eine Bequemlichkeit für den Excel-Doppelklick. Fügen Sie also eine BOM zu Kopien hinzu, die für Excel bestimmt sind, und nicht zur Hauptdatei, die andere Werkzeuge speist. Zweitens repariert eine BOM keine Datei, die kein UTF-8 ist. Wenn die Datei in Windows-1252 geschrieben wurde, macht eine darüber gelegte BOM alles schlimmer, denn Excel entschlüsselt dann Ein-Byte-Daten als UTF-8 und erzeugt neue wirre Zeichen. Fügen Sie eine BOM nur zu einer Datei hinzu, von der Sie wissen, dass sie UTF-8 ist, was Sie mit dem Texteditor-Test aus dem Diagnoseabschnitt bestätigen können.

Eine Datei retten, die bereits wirr aussieht

Bisher ging jede Lösung davon aus, dass die Datei auf der Festplatte noch korrekt ist und nur die Anzeige falsch ist. Aber manchmal wurde die verwürfelte Version bereits gespeichert, und die Frage ist, ob die ursprünglichen Zeichen aus der gespeicherten Kopie noch wiederhergestellt werden können. Die Antwort hängt davon ab, was genau das Speichern getan hat, und es gibt zwei Fälle, die man unterscheiden muss. Im ersten Fall enthält die Datei auf der Festplatte noch die ursprünglichen UTF-8-Bytes, und nur die Excel-Anzeige ist falsch. Das ist der Fall, den der Texteditor-Test erkennt: Der Editor zeigt die Zeichen korrekt, also ist nichts verloren, und Lösung 1 repariert die Anzeige. Im zweiten Fall enthält die Datei auf der Festplatte jetzt die falschen Zeichen selbst, denn jemand hat sie in Excel geöffnet, die wirren Zeichen gesehen und sie zurück in CSV gespeichert, wodurch die falsch gelesenen Zeichen in die Datei geschrieben wurden.

Der zweite Fall ist oft noch wiederherstellbar, und der Test ist, ob die wirren Zeichen dem Ã-Muster aus dem Abschnitt zum Entschlüsseln folgen. Wenn die gespeicherte Datei buchstäblich die Zeichen é enthält, wo é stehen sollte, ist die Wiederherstellung eine erneute Kodierung: Lesen Sie die Datei so, als wäre sie Windows-1252, was die ursprünglichen UTF-8-Bytes zurückgewinnt, und entschlüsseln Sie diese Bytes dann als UTF-8, was die ursprünglichen Zeichen zurückgewinnt. Das Snippet unten tut genau das, und es wurde an einer echten Datei geprüft: Ein Name, der als José geschrieben, als José falsch gelesen wurde, kam nach dem Hin- und Rückweg Byte für Byte als José zurück. Arbeiten Sie mit einer Kopie und niemals mit der einzigen Version, und prüfen Sie das Ergebnis in einem Texteditor, bevor Sie es in Excel erneut öffnen.

with open("mangled.csv", "r", encoding="cp1252") as f:\n    text = f.read()\n# Encode back to the bytes Excel misread, then decode as UTF-8.\nfixed = text.encode("cp1252").decode("utf-8")\nwith open("fixed.csv", "w", encoding="utf-8") as f:\n    f.write(fixed)\n# Verified: José -> José, München -> München.

Der Trick mit der erneuten Kodierung hat eine harte Grenze, und es ist wichtig, sie zu beachten. Er funktioniert nur, wenn die falsch gelesenen Zeichen das Speichern intakt überstanden haben, als é und seine Begleiter. Wenn das Speichern Zeichen durch Fragezeichen oder durch das schwarze rautenförmige Ersatzsymbol ersetzt hat, ist die ursprüngliche Information aus dieser Kopie verschwunden. Keine Entschlüsselung kann ein Zeichen wiederherstellen, das durch einen Platzhalter ersetzt wurde, denn der Platzhalter trägt keine Information darüber, welches Zeichen er ersetzt hat. In diesem Fall hören Sie auf, die Kopie zu reparieren, und erzeugen die Datei aus ihrer Quelle neu: Exportieren Sie sie erneut aus der Datenbank, dem Werkzeug oder dem JSON, aus dem sie kam, und öffnen Sie sie diesmal mit Lösung 1 oder geben Sie ihr mit Lösung 2 eine BOM. Und was auch immer Sie tun, legen Sie die beschädigte Kopie beiseite, bis die neu erzeugte Datei geprüft ist. Die einzige Kopie zu löschen, bevor der Ersatz geprüft wurde, ist der Weg, wie aus einem behebbaren Problem ein verlorener Datensatz wird.

Was das für Dateien aus dem Konverter auf dieser Seite bedeutet

Der Konverter auf dieser Seite erzeugt genau die Art von Datei, um die es in dieser Anleitung geht, sodass es sich lohnt, sein Verhalten offen darzustellen. Der Download ist einfaches UTF-8 ohne BOM. Das wurde anhand des echten Codes geprüft und nicht angenommen: Der Download erzeugt ein text/csv-Blob mit charset=utf-8 und schreibt keine führende Markierung, und die Umwandlungs-Engine selbst wurde mit einer Probe ausgeführt, die José García, München, François, Łódź, São Paulo, einen Eurobetrag, Tokio auf Japanisch und koreanische Namen enthielt, und sie erzeugte jedes Zeichen byte-identisch, ohne BOM am Anfang der Ausgabe. Wenn Ihre umgewandelte Datei also in Excel wirre Zeichen zeigt, hat die Umwandlung nichts beschädigt. Die Datei ist korrektes UTF-8, und Excel hat beim Doppelklick die falsche Kodierung geraten.

Daraus ergeben sich zwei saubere Optionen für umgewandelte Dateien. Die erste ist der Importweg: Öffnen Sie die heruntergeladene Datei mit Daten und dann Aus Text/CSV, setzen Sie die Dateiherkunft auf 65001: Unicode (UTF-8) und laden Sie. Die Zeichen werden korrekt gelesen, und Sie haben nichts an der Datei verändert, sodass sie für jedes andere Werkzeug gültig bleibt. Die zweite ist der BOM-Weg: Öffnen Sie die heruntergeladene Datei in Editor, speichern Sie sie als UTF-8 mit BOM, und behalten Sie diese Kopie für Excel, während Sie den ursprünglichen Download für alles andere behalten. Wandeln Sie die Daten nicht erneut um, um ein Anzeigeproblem bei der Kodierung zu beheben, und fügen Sie die umgewandelte Ausgabe nicht über eine Tabellenkalkulation ein und speichern Sie sie nicht zurück, denn dieser Umweg kann genau die Trennzeichen- und Kodierungsabweichungen einführen, zu deren Verhinderung diese Anleitung existiert. Beheben Sie das Öffnen und nicht die Daten.

Ein weiteres Detail zum Konverter ist hier wichtig. Der Konverter lässt Sie das Trennzeichen vor dem Herunterladen wählen, und diese Wahl ist unabhängig von der Kodierung. Eine Datei kann gleichzeitig das richtige Trennzeichen und eine falsche Kodierungsanzeige haben, oder die richtige Kodierung und das falsche Trennzeichen, oder beides falsch auf einmal. Wenn Ihre umgewandelte Datei in einer Spalte geöffnet wird und die Zeichen falsch aussehen, beheben Sie beide Einstellungen im selben Import: Wählen Sie das Trennzeichen, das Sie bei der Umwandlung gewählt haben, und setzen Sie die Dateiherkunft auf 65001. Die Begleitanleitung zum Ein-Spalten-Problem behandelt die Trennzeichenhälfte im Detail, und sie ist in den verwandten Anleitungen unten verlinkt.

Checkliste zur Vorbeugung: Richtig exportieren, damit niemand etwas reparieren muss

Kodierungsprobleme sind eine Abweichung zwischen Schreiber und Leser, sodass Vorbeugung bedeutet, den Schreiber das, was er geschrieben hat, auf eine Weise erklären zu lassen, die der Leser beachtet. Gehen Sie diese Checkliste durch, wenn Sie eine CSV erzeugen, und die nächste Person, die sie öffnet, braucht diese Anleitung nicht. Erstens kennen Sie Ihre Kodierung zum Zeitpunkt des Exports. Wenn Ihre Daten irgendetwas über einfaches ASCII hinaus enthalten, exportieren Sie als UTF-8, und sagen Sie das im Dateinamen oder in der Notiz, die mit der Datei reist, denn eine CSV-Datei kann es nicht selbst sagen. Zweitens fügen Sie, wenn das Publikum Excel unter Windows ist, eine BOM zur Excel-Kopie hinzu, oder exportieren Sie mit dem Format CSV UTF-8 aus Speichern unter in Excel, das eine BOM für Sie schreibt. Drittens behalten Sie, wenn die Datei auch andere Werkzeuge speist, eine einfache UTF-8-Kopie ohne BOM für diese, denn manche Parser behandeln eine BOM als Teil der ersten Kopfzeile.

Viertens speichern Sie eine gerettete Datei niemals über das Original zurück, bis Sie die Rettung in einem Texteditor geprüft haben. Ein Speichern aus Excel schreibt sowohl das Trennzeichen als auch die Kodierung mit den eigenen Voreinstellungen von Excel neu, was die Abweichung für den nächsten Leser wieder einführen kann oder aus einem Anzeigeproblem einen echten Datenverlust macht. Fünftens öffnen Sie, wenn Sie eine Datei erhalten, sie zuerst in einem Texteditor, falls irgendetwas merkwürdig aussieht, und bestätigen Sie die Kodierung, bevor Sie irgendeine Tabellenkalkulation darüber speichern lassen. Und sechstens behalten Sie die Quelldaten. Eine CSV ist eine abgeflachte Momentaufnahme und nicht die Daten selbst, sodass die Quelle Sie bei einer fehlgeschlagenen Rettung sauber erneut exportieren lässt, statt eine beschädigte Kopie zu reparieren. Die meisten Kodierungs-Horrorgeschichten enden damit, dass jemand zu spät entdeckt, dass die beschädigte CSV die einzige Kopie war. Lassen Sie das nicht Ihre Datei sein.

Verwandte Anleitungen

• CSV in einer Spalte: Warum Ihre CSV in Excel in einer Spalte landet und wie Sie das beheben (Anleitung 2026) →
• Wie kann ich eine JSON-Datei online in CSV umwandeln? (Anleitung 2026) →
• Welche Möglichkeiten gibt es, JSON lokal in CSV umzuwandeln? 6 Methoden im Vergleich (Anleitung 2026) →
• Warum Excel die führenden Nullen Ihrer CSV-Codes entfernt und wie Sie sie behalten (Anleitung 2026) →
• Excel ändert Datum in CSV: Tag und Monat vertauscht – so bleiben Ihre Daten richtig (Anleitung 2026) →
• Warum Excel Ihre CSV beim Speichern verändert und wie Sie das Original schützen (Anleitung 2026) →
• CSV-Datei zu groß für Excel: Warum Excel Ihre große CSV-Datei nicht öffnet und was Sie stattdessen tun (Anleitung 2026) →

Häufig gestellte Fragen