Reiner Text verstehen: TXT, Encoding und Zeilenenden

Eine TXT-Datei wirkt auf den ersten Blick wie das simpelste Dateiformat überhaupt: Du öffnest sie, siehst Buchstaben, fertig. Und im Kern stimmt das auch, denn reiner Text ist tatsächlich nur eine Folge von Zeichen ohne jede Formatierung. Doch genau in dieser scheinbaren Einfachheit stecken drei Dinge, die dich überraschen können, wenn du sie nicht kennst: die Zeichenkodierung, die Zeilenenden und die Grenzen dessen, was reiner Text überhaupt speichern kann.

In diesem Ratgeber gehst du der Frage nach, was reiner Text wirklich ist. Du lernst, wie aus abstrakten Zeichen konkrete Bytes werden, warum Umlaute manchmal als kryptischer Zeichensalat erscheinen, wodurch sich Windows- und Unix-Textdateien unterscheiden und wann du zu TXT greifen solltest, statt zu einem reicheren Format.

Was reiner Text ist: nur Zeichen, keine Formatierung

Reiner Text (auf Englisch plain text) ist eine Aneinanderreihung von Schriftzeichen: Buchstaben, Ziffern, Satzzeichen, Leerzeichen und Zeilenumbrüche. Was reiner Text bewusst nicht enthält, ist jede Form von Auszeichnung. Es gibt keine Schriftart, keine Schriftgröße, kein Fett oder Kursiv, keine Farben, keine Ränder, keine eingebetteten Bilder und keine Tabellen. Eine Überschrift in einer TXT-Datei ist keine echte Überschrift, sondern nur eine Zeile, die du vielleicht mit Großbuchstaben oder Bindestrichen darunter optisch hervorhebst.

Das ist der große Unterschied zu Formaten wie DOCX, PDF oder HTML. Diese sogenannten Rich-Text- oder Dokumentformate speichern neben dem eigentlichen Text noch Anweisungen dazu, wie er aussehen soll. Reiner Text speichert ausschließlich den Inhalt. Wenn du wissen willst, wie sich das im direkten Vergleich auswirkt, hilft dir der Ratgeber zum Unterschied zwischen DOCX und TXT weiter.

Zeichenkodierung: wie aus Zeichen Bytes werden

Ein Computer speichert keine Buchstaben, sondern Zahlen, genauer gesagt Bytes. Damit aus dem Zeichen “A” eine Zahl und aus der Zahl wieder ein “A” wird, braucht es eine vereinbarte Zuordnungstabelle. Diese Zuordnung heißt Zeichenkodierung (englisch character encoding). Wenn Programm A beim Speichern eine andere Tabelle benutzt als Programm B beim Öffnen, passt die Zuordnung nicht mehr, und du siehst falsche Zeichen.

ASCII: der gemeinsame Kern

Am Anfang stand ASCII (American Standard Code for Information Interchange). ASCII belegt die Werte 0 bis 127 und deckt damit das englische Alphabet in Groß- und Kleinschreibung, die Ziffern 0 bis 9, gängige Satzzeichen sowie einige Steuerzeichen ab. Für Englisch reicht das, für Deutsch nicht: ä, ö, ü und ß kommen in ASCII schlicht nicht vor. ASCII ist aber bis heute wichtig, weil fast alle moderneren Kodierungen die ersten 128 Werte identisch übernehmen. Ein reiner ASCII-Text ist deshalb praktisch überall lesbar.

ANSI und Windows-1252: der deutsche Zwischenschritt

Um die fehlenden Zeichen unterzubringen, erweiterten Kodierungen den Bereich auf 256 Werte (also ein volles Byte pro Zeichen). Unter Windows ist die verbreitetste dieser Erweiterungen die Codepage Windows-1252, oft ungenau als “ANSI” bezeichnet. Sie enthält die Werte 128 bis 255 zusätzlich, und dort liegen dann die deutschen Umlaute, das ß, das Euro-Zeichen und weitere westeuropäische Zeichen. Das Problem: Jede Sprachregion hatte ihre eigene Codepage. Was in Windows-1252 ein ä war, konnte in einer anderen Codepage ein völlig anderes Zeichen sein. Ein Byte allein verrät nicht, welche Tabelle gemeint war.

UTF-8: der heutige Standard

UTF-8 löst dieses Durcheinander. Es ist eine Kodierung des Unicode-Standards, der praktisch jedes Schriftzeichen der Welt in einer einzigen, gemeinsamen Tabelle vereint, von deutschen Umlauten über kyrillische und arabische Schrift bis zu Emojis. UTF-8 (definiert in RFC 3629) speichert dabei nicht jedes Zeichen mit fester Länge, sondern variabel: ASCII-Zeichen brauchen weiterhin nur ein einziges Byte, seltenere Zeichen zwei bis vier Bytes. Das macht UTF-8 kompakt für lateinische Texte und trotzdem universell.

UTF-8 ist heute aus gutem Grund der De-facto-Standard für Textdateien, Webseiten und Programmierung. Es ist abwärtskompatibel zu ASCII, es kennt keine regionalen Codepage-Konflikte mehr, und es ist eindeutig. Wenn du eine neue TXT-Datei anlegst, ist UTF-8 fast immer die richtige Wahl.

Was bei falschem Encoding passiert: Mojibake

Öffnest du eine Datei mit der falschen Kodierung, entsteht der berüchtigte Zeichensalat, für den es sogar einen Fachbegriff gibt: Mojibake. Ein typisches Beispiel: Du speicherst “Grüße” als UTF-8, jemand öffnet die Datei aber als Windows-1252. Dann erscheint statt des ü plötzlich “Grüße”. Der Grund ist, dass das ü in UTF-8 aus zwei Bytes besteht, die die Windows-1252-Tabelle einzeln als zwei eigenständige Zeichen deutet. Umgekehrt kann eine Windows-1252-Datei, die als UTF-8 gelesen wird, an Umlauten mit einem Ersatzzeichen (oft ein schwarzes Rautezeichen mit Fragezeichen) enden, weil die Byte-Folge in UTF-8 ungültig ist.

Die gute Nachricht: Der Text selbst ist dabei nicht kaputt. Nur die Interpretation der Bytes stimmt nicht. Wählst du beim Öffnen die richtige Kodierung, erscheint alles wieder korrekt.

Umlaute und Sonderzeichen

Für dich als deutschsprachige Nutzerin oder Nutzer sind Umlaute und das ß der häufigste Stolperstein. Solange alle Beteiligten UTF-8 verwenden, gibt es keine Probleme: ä, ö, ü, ß, aber auch é, ñ oder das Euro-Zeichen werden korrekt gespeichert und wieder angezeigt. Kritisch wird es nur an den Übergängen, etwa wenn eine ältere Software eine Datei in Windows-1252 exportiert und ein modernes Programm sie als UTF-8 erwartet.

Genau an dieser Stelle setzt docxtxt.de an: Der Konverter gibt den extrahierten Text konsequent als UTF-8 aus. Deine echten Umlaute bleiben also erhalten und werden nicht in Umschreibungen wie ae oder oe verwandelt. Da die Umwandlung komplett lokal in deinem Browser läuft, verlässt dabei keine Datei dein Gerät.

Zeilenenden: LF, CRLF und CR

Neben der Kodierung gibt es einen zweiten unsichtbaren Faktor: Wie markiert eine Datei das Ende einer Zeile? Auch das ist ein reines Zeichen (oder eine Zeichenfolge), das du normalerweise nicht siehst, das aber je nach Betriebssystem historisch unterschiedlich gehandhabt wird.

Es gibt drei Varianten, die sich aus zwei Steuerzeichen zusammensetzen: dem Wagenrücklauf CR (Carriage Return) und dem Zeilenvorschub LF (Line Feed). Die Begriffe stammen aus der Zeit der Schreibmaschinen, bei denen der Wagen zurücklief und die Walze eine Zeile weiterdrehte.

Variante	Zeichen	Herkunft	typisches System
LF	\n (nur Zeilenvorschub)	Unix-Tradition	Linux, macOS (aktuell)
CRLF	\r\n (beide, in dieser Reihenfolge)	Fernschreiber-Erbe	Windows
CR	\r (nur Wagenrücklauf)	frühe Apple-Systeme	klassisches Mac OS bis Version 9

In der Praxis begegnen dir heute vor allem LF und CRLF. Windows-Programme wie der klassische Editor schreiben traditionell CRLF, während Linux, macOS und die meisten Programmierwerkzeuge LF verwenden. Reines CR ist ein historisches Relikt und kommt kaum noch vor.

Meistens ist der Unterschied harmlos, weil moderne Editoren beide Varianten problemlos anzeigen. Sichtbar wird er nur, wenn ein Programm sich strikt an eine Variante hält. Ein bekanntes Beispiel ist der uralte Windows-Editor, der früher eine reine LF-Datei ohne Zeilenumbrüche als einen einzigen langen Textblock darstellte. Umgekehrt tauchen in manchen Unix-Werkzeugen bei CRLF-Dateien störende ^M-Zeichen am Zeilenende auf. Für Entwicklerinnen und Entwickler kann das konkrete Folgen haben, dazu findest du Details im Ratgeber zu den TXT-Workflows für Entwickler.

Die BOM: eine unsichtbare Markierung am Anfang

Ein verwandtes Thema ist die sogenannte Byte Order Mark, kurz BOM. Das ist eine kurze, unsichtbare Byte-Folge, die manche Programme ganz an den Anfang einer UTF-8-Datei setzen, um zu signalisieren “diese Datei ist UTF-8”. Gedacht ist das als Hilfe, doch in der Praxis sorgt die BOM oft für Ärger. Viele Werkzeuge, gerade in der Entwicklung, erwarten keine BOM und behandeln die drei zusätzlichen Bytes als sichtbaren Inhalt am Zeilenanfang oder stolpern beim Einlesen von Konfigurationsdateien darüber.

Die allgemeine Empfehlung für UTF-8 lautet deshalb: BOM weglassen, außer ein bestimmtes Programm verlangt sie ausdrücklich. UTF-8 ist auch ohne BOM eindeutig erkennbar, sie ist also technisch nicht nötig.

Die Vorteile von reinem Text

Trotz oder gerade wegen seiner Schlichtheit hat reiner Text starke Vorzüge, die ihn seit Jahrzehnten unverzichtbar machen.

Universell lesbar. Es gibt kein Betriebssystem und praktisch kein Programm, das keine TXT-Datei öffnen kann. Du brauchst keine spezielle Software, kein Office-Paket und keine Lizenz. Ein einfacher Editor genügt.

Langlebig. Weil das Format so simpel und offen dokumentiert ist, wirst du eine heute geschriebene TXT-Datei auch in zwanzig Jahren noch problemlos öffnen können. Bei proprietären Formaten ist das keineswegs sicher, denn dort können sich Programmversionen und Standards ändern.

Diff-bar und versionierbar. Da reiner Text zeilenweise aufgebaut ist, lassen sich Änderungen zwischen zwei Versionen exakt anzeigen. Versionsverwaltungen wie Git zeigen dir bei Textdateien genau, welche Zeile sich geändert hat. Bei Binärformaten sehen solche Werkzeuge nur “Datei hat sich geändert”, ohne Details.

Klein und schlank. Ohne Formatierungsdaten, ohne eingebettete Objekte und ohne Overhead ist reiner Text extrem kompakt. Ein Dokument, das als DOCX mehrere hundert Kilobyte wiegt, schrumpft als reiner Text oft auf wenige Kilobyte.

Die Grenzen von reinem Text

Dieselbe Schlichtheit ist zugleich die Grenze. Alles, was über die reine Zeichenfolge hinausgeht, kann reiner Text nicht abbilden.

Es gibt keine Formatierung: kein Fett, kein Kursiv, keine Überschriften-Hierarchie, keine Farben und keine Schriftarten. Es gibt keine Bilder, keine Diagramme und keine eingebetteten Objekte. Echte Tabellen sind ebenfalls nicht möglich, du kannst sie höchstens mit Leerzeichen oder Tabulatoren optisch nachbauen, was aber schnell zerbricht, sobald sich Schriftart oder Spaltenbreite ändern. Und es gibt keine Metadaten wie Autor, Erstellungsdatum oder Kommentare innerhalb des Dokuments.

Wenn du also ein formatiertes Dokument nach TXT umwandelst, bleibt der reine Inhalt erhalten, das visuelle Layout geht jedoch verloren. Ob das ein Verlust oder ein Gewinn ist, hängt vom Zweck ab. Wann sich der Wechsel zu reinem Text lohnt und wann nicht, beleuchtet der Ratgeber Wann TXT statt DOCX sinnvoll ist.

Fazit

Reiner Text ist mächtiger und zugleich anspruchsvoller, als sein einfaches Äußeres vermuten lässt. Wenn du die drei zentralen Aspekte im Kopf behältst, bist du auf der sicheren Seite: Nutze UTF-8 als Kodierung, damit deine Umlaute überall stimmen, sei dir der Zeilenenden LF und CRLF bewusst, wenn du zwischen Systemen wechselst, und wisse, dass reiner Text bewusst keine Formatierung speichert. Genau diese Reduktion auf den reinen Inhalt macht TXT universell, langlebig und leicht weiterzuverarbeiten.

Hast du einen Fehler entdeckt oder einen Quellen-Hinweis für uns? Schreib gern an info@akara-solutions.de.