Geschichtsstunde: Was ist eine .txt-Datei? Warum alte Textdateien seltsame Zeichen zeigen

Was ist eine .txt-Datei?

Öffnet man eine .txt-Datei in einem beliebigen Editor, sieht man nur Zeichen: Buchstaben, Ziffern, Satzzeichen, Leerzeichen und Zeilenumbrüche. Das ist das ganze Format. Es gibt keinen Dateikopf, keine Schriftart, kein Fett oder Kursiv, keine Seitengröße und keinen Vermerk zur Sprache des Textes. Tatsächlich enthält die Datei eine Folge von Bytes, also Zahlen von 0 bis 255, und das öffnende Programm muss entscheiden, für welches Zeichen jede Zahl steht. Die Endung „.txt“ sagt Windows nur, welches Programm es anbieten soll; wie die Bytes zu lesen sind, verrät sie nicht. Deshalb ist reiner Text eines der portabelsten Formate überhaupt und zugleich eines der am leichtesten falsch zu lesenden.

Warum zeigt meine .txt-Datei seltsame Zeichen?

Weil das lesende Programm eine andere Zeichenkodierung verwendet als das Programm, das die Datei geschrieben hat. Derselbe Buchstabe kann als unterschiedliche Bytes gespeichert sein: é ist in Windows-1252, der Codepage, die Microsoft als die übliche für Englisch und andere westeuropäische Sprachen beschreibt, das einzelne Byte E9, in UTF-8 aber die zwei Bytes C3 A9. Wird eine UTF-8-Datei als Windows-1252 geöffnet, wird aus jedem é ein é. Der typografische Apostroph ’ (E2 80 99 in UTF-8) wird zu ’. Eine UTF-8-Datei, die mit einer Byte-Reihenfolge-Marke (BOM, weiter unten erklärt) beginnt, startet mit . Umgekehrt, wenn eine Windows-1252-Datei als UTF-8 geöffnet wird, ist das einzelne Byte E9 kein gültiges UTF-8, und das Programm zeigt das Ersatzzeichen �.

Dateien aus der DOS-Zeit gehen anders schief. Beim ursprünglichen IBM PC konnte dasselbe Byte noch ein ganz anderes Zeichen sein: In der Codepage 437, dem DOS-Zeichensatz, ist Byte 82 ein é, und die fünf Bytes C9 CD CD CD BB zeichnen die Oberkante eines Rahmens (╔═══╗). Windows liest sie als Codepage 1252 und zeigt ‚ und ÉÍÍÍ», sodass aus dem Wort café caf‚ wird und aus dem Rahmen eines README-Banners Buchstaben.

Kein Programm kann allein immer richtig liegen. 2007 zeigte Raymond Chen von Microsoft das Dilemma des Editors an einer Datei mit zwei Bytes, D0 AE. Als Windows-1252 gelesen sind es die Zeichen Ю; als UTF-8 gelesen ist es der kyrillische Buchstabe Ю; als UTF-16 (zwei Bytes pro Zeichen) gelesen ist es eine einzelne koreanische Hangul-Silbe, je nach Byte-Reihenfolge eine andere. Er wies darauf hin, dass alle vier Lesarten plausibel sind. Ohne Kennzeichnung in der Datei ist „seltsam“ einfach das Aussehen einer falschen Vermutung.

1963: ASCII gibt 128 Zeichen eine Nummer

Damit reiner Text eine Datei sein konnte, brauchten die Zeichen Nummern, auf die sich verschiedene Maschinen einigten. Die American Standards Association richtete im August 1960 einen Unterausschuss für kodierte Zeichensätze ein und genehmigte am 17. Juni 1963 die Norm X3.4-1963, den American Standard Code for Information Interchange: ASCII. Es war ein 7-Bit-Code mit 128 Werten für Steuerzeichen, Ziffern, Satzzeichen und das englische Alphabet. Die Ausgabe von 1963 war wissentlich unvollständig, große Teile der Tabelle waren noch nicht belegt. Eine Mitteilung von 1967 zur am 7. Juli 1967 genehmigten Überarbeitung X3.4-1967 besagte, die meisten Beteiligten am ASCII-Projekt sähen darin die erste wirkliche Vervollständigung des grundlegenden 7-Bit-Codes.

Sieben Bit passen nicht sauber in ein Byte. Eines der frühesten Dokumente, das sagt, was zu tun ist, ist RFC 20, im Oktober 1969 von Vint Cerf für das frühe ARPANET geschrieben, das Forschungsnetz vor dem Internet. Sie schlug „Standard-7-Bit-ASCII, eingebettet in ein 8-Bit-Byte, dessen höchstwertiges Bit immer 0 ist“ vor. Dieses ungenutzte achte Bit ist die Stelle, an der der Ärger später beginnt: Sobald ein Byte 256 Werte aufnehmen kann, sind die anderen 128 frei für jeden, der sie belegen will.

CR, LF oder beides: wie eine Zeile endet

ASCII kodierte auch die Mechanik des Fernschreibers. Wie Chen erklärt, brachte der Wagenrücklauf (CR) den Druckkopf zurück in Spalte 0, ohne das Papier vorzuschieben, und der Zeilenvorschub (LF) schob das Papier eine Zeile vor, ohne den Kopf zu bewegen; für eine neue Zeile brauchte es also beides. Die Ausgabe von ASCII aus dem Jahr 1968, wiedergegeben in RFC 20, lässt LF „Neue Zeile“ bedeuten, fügt aber hinzu, dass dies „eine Vereinbarung zwischen Sender und Empfänger der Daten erfordert“. Diese Vereinbarung kam nie ganz zustande. RFC 20 selbst hält fest, dass die ersten ARPANET-Standorte uneins waren: SRI verwendete einen Punkt als Zeilenendezeichen, UCLA den Wagenrücklauf.

CP/M, MS-DOS und Windows behielten beide Zeichen bei, CRLF (die Bytes 0D 0A). Unix begnügte sich mit einem einzelnen LF (0A). Microsofts Ankündigung des neuen Notepad-Verhaltens von 2018 nennt die drei Konventionen, die es jetzt beherrscht: Unix/Linux-Zeilenenden (LF), Macintosh-Zeilenenden (CR) und Windows-Zeilenenden (CRLF). Bis dahin, hieß es, konnte Notepad nur Windows-Zeilenenden korrekt anzeigen, sodass eine unter Unix oder Linux erstellte Textdatei wirr aussah. Die Korrektur erreichte im Mai 2018 die Insider-Builds von Windows 10.

1981: Die anderen 128 Werte gehen eigene Wege

Der IBM PC erschien 1981 mit 8-Bit-Bytes und einem 7-Bit-Standard. David Bradley, einer seiner Ingenieure, erinnerte sich später, der PC habe „den ASCII-Zeichensatz verwendet, eine radikale Änderung für ein IBM-Produkt“ (frühere IBM-Produkte nutzten EBCDIC) und das Team habe die 128 neuen Plätze mit fremdsprachigen Buchstaben, Blockgrafiken sowie mathematischen und griechischen Symbolen gefüllt. Er sagte, er beschreibe den Zeichensatz gern als entwickelt in „einem Treffen von drei Personen und vier Stunden“. Das Ergebnis ist die Codepage 437, die Microsoft die übliche OEM-Codepage (DOS) für Englisch nennt: Ihre obere Hälfte enthält Buchstaben mit Akzenten, Linienzeichen und Symbole.

Windows baute dann eigene Codepages. Laut Microsoft-Dokumentation beruhte die Windows-Codepage 1252 ursprünglich auf einem Entwurf des American National Standards Institute (ANSI), der schließlich zu ISO 8859-1 wurde, wurde aber umgesetzt, bevor der Standard fertig war, und ist nicht ganz identisch. Windows-Codepages heißen bis heute häufig „ANSI-Codepages“, obwohl sie Microsofts eigene sind. Alle stimmen für die Werte 0 bis 127 mit ASCII überein und weichen darüber ab: Das Byte E9 ist é in Codepage 1252, й in der kyrillischen Codepage 1251 und ι in der griechischen Codepage 1253. Japanisch und Chinesisch nutzten Doppelbyte-Codepages, in denen manche Bytes nur zusammen mit dem folgenden Byte etwas bedeuten. Microsoft weist darauf hin, dass keine einzelne Codepage alles abdeckt, was Unicode abdeckt.

1992: Unicode und ein Tischset in einem Diner in New Jersey

Unicode wählte den entgegengesetzten Ansatz: eine Nummer für jedes Zeichen, kein Jonglieren mehr mit Codepages. In seiner ersten Version, von 1991 bis 1995, war es eine 16-Bit-Kodierung; seit Unicode 2.0 im Juli 1996 umfasst es den Bereich U+0000 bis U+10FFFF. Aber eine Nummer ist keine Datei. 16-Bit-Werte direkt in Dateien zu speichern kollidierte mit der damaligen Unix-Software, die sich auf ASCII-Bytes wie das Nullbyte und den Schrägstrich stützte, und 1992 erwog ein X/Open-Komitee eine Unix-taugliche Möglichkeit, Unicode zu speichern.

Rob Pike, damals bei den Bell Labs, schrieb 2003, UTF-8 sei „vor meinen Augen auf einem Tischset in einem Diner in New Jersey in einer Nacht im September oder so 1992 entworfen“ worden. Komiteemitglieder hatten ihn und Ken Thompson gebeten, ihren Vorschlag zu prüfen. Die beiden gingen essen, Thompson erarbeitete die Bitpackung, und danach riefen sie das Komitee an. Pike sagt, Thompson habe den Pack- und Entpackcode noch in der Nacht geschrieben, und bis Freitag habe ihr Betriebssystem Plan 9 nur noch mit dem gearbeitet, was später UTF-8 heißen sollte. Mailarchive, die sein Kollege Russ Cox ausgegraben hat, datieren den Vorschlag auf Anfang September 1992.

UTF-8 speichert jedes Zeichen in ein bis vier Bytes. Die 128 ASCII-Zeichen behalten ihren Ein-Byte-Wert, und kein Byte eines anderen Zeichens sieht aus wie ASCII, sodass eine reine ASCII-Datei bereits gültiges UTF-8 ist. Alles andere braucht zwei bis vier Bytes, mit führenden Bits, die dem Leser die Länge der Folge anzeigen: é wird zu C3 A9. François Yergeaus RFC 3629 (November 2003) machte es zum Internetstandard, und die Unicode-FAQ nennt es „die bevorzugte Form für Unicode-Textdateien“.

Der BOM, und warum der Editor raten musste

UTF-16 speichert Zeichen in 16-Bit-Einheiten, der Leser muss also auch die Byte-Reihenfolge kennen. Unicodes Antwort ist ein Zeichen, U+FEFF, ganz am Dateianfang als Signatur: die Byte-Reihenfolge-Marke. In UTF-8 erscheint sie als die Bytes EF BB BF, und die Unicode-FAQ stellt klar, dass sie dort nichts mit der Byte-Reihenfolge zu tun hat, sondern die Datei nur als UTF-8 kennzeichnet. Die FAQ fügt hinzu, dass manche Programme sie nicht erwarten (die erste Zeile eines Unix-Shellskripts, die mit #! beginnt, ist ein Beispiel) und dass ein Protokoll wie die „Microsoft-Konventionen für .txt-Dateien“ sie verlangen kann. Eine .txt-Datei kann also mit einem BOM beginnen oder nicht, und wenn nicht, muss das Programm raten.

Chens Beitrag von 2007 über „das Kodierungsproblem von Notepad-Dateien“ erklärt, warum Raten nie gut ausgeht. Dateien mit BOM sind einfach. Ohne BOM waren die meisten Textdateien in freier Wildbahn 8-Bit-ANSI, einige UTF-8- und UTF-16-Dateien hatten ebenfalls keinen BOM, und jede Regel, die er ausprobierte, begünstigte eine Gruppe und brach eine andere. Sein Beispiel: Der Befehl cmd /u /c dir >results.txt schreibt eine UTF-16-Datei ohne BOM.

Microsoft änderte Notepad in zwei Schritten. 2018 lernte es Unix- und Mac-Zeilenenden. Dann fügte Microsoft im Windows-10-Insider-Build 18298 am 10. Dezember 2018 die Option hinzu, UTF-8 ohne BOM zu speichern, machte es zum Standard für neue Dateien und zeigte die Kodierung in der Statusleiste an; UTF-8 ohne BOM sei abwärtskompatibel zu ASCII und funktioniere besser mit dem Web, „wo UTF-8 zur Standardkodierung geworden ist“. Die Änderung erreichte alle mit Windows 10 Version 1903, dem Mai-2019-Update. Zuvor verwendete eine neue Notepad-Datei standardmäßig ANSI.

2007 und danach: UTF-8 übernimmt das Web

Google meldete, dass im Dezember 2007 Unicode erstmals die häufigste Kodierung auf den von ihm indexierten Webseiten wurde und ASCII und die westeuropäischen Kodierungen im Abstand von zehn Tagen überholte. W3Techs meldet heute UTF-8 auf 99,1 % der Websites, deren Kodierung es erkennen kann (November 2026). Das ist eine Statistik über Websites. Textdateien auf alten Datenträgern waren nie Teil dieser Verschiebung, und niemand ging zurück und kodierte sie neu.

Warum .txt-Dateien von alten Datenträgern 2026 immer noch unleserlich aussehen

Heutige Software setzt UTF-8 voraus, aber viel Text wurde früher geschrieben: DOS-READMEs, frühe Windows-Notizen, Exporte aus Programmen, die nicht mehr laufen, sowie als Text gespeicherte Mails oder Protokolle. Sie liegen in der Codepage des PCs, der sie erzeugt hat, je nach dessen Sprache und Windows-Version, und tragen keine Kennzeichnung. Kommen Zeilenenden eines anderen Systems und gelegentlich eine UTF-16-Datei ohne BOM hinzu, verbirgt dieselbe Endung .txt mehrere voneinander unabhängige Formate. Viele davon sind Legacy-Dateien, bei denen niemand das ursprüngliche Programm mehr fragen kann.

Legacy File Converter führt reinen Text (.txt) unter den Dokumenten auf seiner Seite Unterstützte Dateitypen auf und wandelt sie auf Ihrem eigenen Windows-PC in moderne Formate wie DOCX, PDF, Markdown oder HTML um; es wird nichts hochgeladen. Vergleichen Sie danach Buchstaben mit Akzenten, Anführungszeichen und Symbole mit dem Original und behalten Sie die Originaldatei. Zu anderen Formaten, die im Kern vor allem Text sind, siehe die Geschichtsstunde: Was ist eine .csv-Datei?, bei der ein fehlender BOM Excel stolpern lässt, und die Geschichtsstunde: Was ist eine .rtf-Datei?.