Was ist eine TXT-Datei?

TXT ist ein reines Textformat, das sich in jedem Editor öffnen lässt. Eingesetzt wird es für den Austausch zwischen Programmen und die Archivierung.

Die Endung lautet .txt, der volle Name Plain Text. Beides sagt weniger aus als das, was die Datei halten kann — und davon handelt der Rest dieser Seite.

Es geht auf 1963 zurück. Die Spezifikation ist Unicode.

Einem Format, das so lange lesbar geblieben ist, kann man etwas anvertrauen, das man in zehn Jahren wiederhaben will.

Sie ist vollständig veröffentlicht, das Format lässt sich also aus dem Dokument umsetzen statt durch Nachsehen. Deshalb taucht es in so vielen Programmen auf, und deshalb gehen Dateien von vor zwanzig Jahren heute noch auf. Veröffentlicht heißt allerdings nicht lizenzfrei: Wo ein Format einen Codec einpackt, ist die Patentfrage eine eigene, die der Standard nicht mitbeantwortet.

TXT speichert seinen Inhalt exakt. Erneutes Speichern ändert nichts, es lässt sich also beliebig oft öffnen, bearbeiten und wieder ablegen, ohne dass sich Schaden ansammelt — genau das macht es zu einem Arbeitsformat und nicht zu einem Ausgabeformat.

Notepad, TextEdit und Visual Studio Code lesen es, und die meisten Programme derselben Art ebenfalls.

Wenn eine Datei nicht aufgeht, liegt es selten am Format — häufiger daran, dass das Programm älter ist als das Format. Die Umwandlung in etwas Älteres ist der verlässliche Weg daran vorbei, und dafür gibt es den Rest dieser Website.

Jeder aktuelle Browser liest es.

Damit lässt es sich bedenkenlos auf eine Seite stellen oder an eine Nachricht hängen, ohne sich zu fragen, was die Gegenseite installiert hat.

TXT ist zum Öffnen und Ändern gedacht. Behalte die Datei in diesem Format, solange die Arbeit läuft, und exportiere daraus, wann immer eine fertige Fassung gebraucht wird.

Eine TXT-Datei ist eine Folge von Zeichen. Es gibt keinen Kopf, keine Struktur, keine Formatierung, keine Metadaten und keine Version — nichts, das veralten kann, und nichts, das ein Programm zum Verstehen braucht. Das ist die gesamte Spezifikation, und deshalb öffnet sich eine 1970 geschriebene Textdatei heute in praktisch allem und wird sich in fünfzig Jahren in dem öffnen, was diese Programme dann abgelöst hat.

Alles andere auf dieser Site ist ein Format im eigentlichen Sinn: Bytes so angeordnet, dass ein bestimmtes Programm daraus etwas rekonstruieren kann. Reiner Text verlangt nichts. Er ist der Boden, auf dem jedes andere Format aufbaut — HTML, CSV, JSON, Markdown, SRT und SVG sind darunter alle Textdateien mit übergelegten Konventionen.

Zeichen müssen als Zahlen gespeichert werden, und welche Zahl welches Zeichen meint, ist die Kodierung. UTF-8 ist heute überall die Antwort, mit der nützlichen Eigenschaft, dass reiner englischer Text bytegleich mit dem ASCII von vor fünfzig Jahren ist.

Ältere Dateien sind es oft nicht, und nichts in der Datei sagt das. Unter Windows im deutschsprachigen Raum gespeicherter Text ist häufig „ANSI" — in Wahrheit Windows-1252, eine Variante von Latin-1. Wird eine solche Datei als UTF-8 gelesen, wird aus „für" ein „für" und aus „groß" ein „groß" — die klassischen deutschen Mojibake-Zeichenketten, die jeder schon einmal in einer E-Mail oder CSV-Datei gesehen hat. Die Bytes sind unversehrt, nur die Leseannahme ist falsch, und jeder anständige Editor lässt die Datei mit einer anderen Kodierung erneut öffnen, was das Problem sofort behebt, ohne dass irgendetwas neu getippt werden muss.

Manche Editoren schreiben drei unsichtbare Bytes an den Anfang einer UTF-8-Datei, um deren Kodierung zu erklären. Unter Windows ist das üblich; fast überall sonst gilt es als Fehler.

Für Menschen ist sie unsichtbar, für Programme sehr sichtbar. Eine Konfigurationsdatei mit BOM lässt sich nicht parsen. Eine CSV mit BOM hat einen ersten Spaltenkopf, der zu nichts passt. Ein Skript mit BOM verweigert mit einer wenig hilfreichen Fehlermeldung den Start. Weist etwas eine Textdatei ohne erkennbaren Grund zurück, ist das der erste Punkt zum Prüfen — „UTF-8 ohne BOM" ist die gesuchte Einstellung.

Windows beendet eine Zeile mit zwei Zeichen, Carriage Return und Line Feed. Alles andere nutzt nur eines, den Line Feed allein. Beides ist legitim, und die Datei verrät nicht, welches sie verwendet.

Die sichtbaren Symptome sind alt, aber nicht ausgestorben: eine Unix-Datei, die im alten Windows-Notepad als eine einzige riesige Zeile erscheint, oder eine Windows-Datei mit einem störenden Zeichen am Ende jeder Zeile in einem Unix-Werkzeug. Moderne Editoren behandeln beides klaglos und können umwandeln. Zum Problem wird es weiterhin in der Versionsverwaltung, wenn eine ganze Datei geändert erscheint, weil ein Editor jede Zeile neu geschrieben hat, und in Skripten, wo ein überzähliges Carriage Return zum Teil eines Dateinamens wird und nichts mehr funktioniert.

Zuerst Langlebigkeit. Muss etwas in dreißig Jahren lesbar sein, ohne Annahmen über verfügbare Software, sollte es Text sein. Das gilt für Notizen, Protokolle, Transkripte, Konfiguration, Datenexporte und alles, wofür ein Archivar später dankbar sein wird.

Dann Werkzeugunterstützung. Text lässt sich durchsuchen, filtern, sortieren, vergleichen und bearbeiten von einer riesigen Zahl an Programmen, die von den eigenen Daten nichts wissen müssen. Ein Diff zwischen zwei Versionen ist aussagekräftig, eine Versionsverwaltung kann die Änderungen zweier Personen zusammenführen. Nichts davon ist mit einem binären Dokument möglich, und das ist der Grund, warum so viel technische Arbeit in Textformaten stattfindet, die neben den Alternativen unscheinbar wirken.

Logs und Exporte erreichen Gigabytegröße, und die meisten Editoren versuchen, alles ins Gedächtnis zu laden. Eine Textverarbeitung verweigert das schlicht, ein allgemeiner Editor kann den Rechner zum Stocken bringen.

Werkzeuge, die damit umgehen, lesen in Abschnitten — ein richtiger Code-Editor, ein Pager, oder die dafür gebauten Kommandozeilenwerkzeuge. Auf jedem System beantworten die ersten und letzten fünfzig Zeilen einer großen Datei die meisten Fragen, ohne sie zu öffnen: Oben steht, was die Datei ist, unten steht, ob der Prozess, der sie geschrieben hat, fertig wurde.

Ein PDF nach TXT umzuwandeln behält die Wörter und wirft alles andere weg — Schriften, Layout, Bilder, Tabellen, Überschriften. Manchmal ist genau das der Zweck: den Text herausziehen, um ihn zu zitieren, zu durchsuchen oder weiterzuverarbeiten. Das funktioniert nur, wenn das PDF eine echte Textebene trägt; ein eingescanntes Dokument hat keine, kommt also leer heraus und braucht stattdessen eine Texterkennung. Wichtig zu wissen: Eine als reiner Text umgewandelte Tabelle wird meist unlesbar, weil die Ausrichtung, die sie zur Tabelle machte, Formatierung war, kein Inhalt.

In die andere Richtung ist Text nach PDF umwandeln ein Wechsel des Behälters, nicht des Inhalts. Es fixiert das Erscheinungsbild, macht die Datei druckbar und liefert etwas, das sich für alle gleich öffnet. Die Textdatei bleibt die Version, die sich noch bearbeiten, durchsuchen und vergleichen lässt — deshalb ist es meist richtig, beide zu behalten.