Encoding für TXT: UTF-8, BOM, ISO-8859-1, Windows-1252

Was eine TXT-Datei wirklich ist

Eine TXT-Datei wirkt einfach. Du öffnest sie in Notepad, du siehst Text. Aber technisch ist eine TXT-Datei nichts anderes als eine Sequenz von Bytes, deren Interpretation als Text von einer Encoding-Annahme abhängt. Genau diese Annahme ist es, die je nach Wahl entscheidet, ob deine Umlaute richtig oder als Mojibake ankommen.

Wenn du in JavaScript einen String hast, ist der intern UTF-16. Sobald du den String in eine Datei schreibst, musst du ihn in Bytes übersetzen. Diese Uebersetzung heißt Encoding. Die Wahl des Encodings bestimmt, welche Bytes in der Datei landen, und damit, wie ein anderer Editor diese Bytes wieder zu Zeichen zurückliest.

pdftxt.de bietet dafür vier Optionen: UTF-8, UTF-8 mit BOM, ISO-8859-1, Windows-1252. Diese vier Optionen decken praktisch jeden realen Anwendungsfall ab, von modernen Web-Imports bis zu Legacy-Mainframe-Jobs. Hier folgt, was diese vier Optionen technisch bedeuten und wann du welche wählen solltest.

UTF-8: der Default

UTF-8 wurde 1992 von Ken Thompson und Rob Pike (Bell Labs) entworfen und 2003 als RFC 3629 standardisiert. Es ist heute der dominante Encoding-Standard im Web (rund 98 Prozent aller Websites), in Linux-Systemen, in modernen Programmiersprachen und in JSON-/XML-Daten.

Die Grundidee: UTF-8 ist ein variable-length-Encoding, das ASCII-Zeichen (0 bis 127) mit einem Byte kodiert, andere Zeichen mit zwei bis vier Bytes. Das gibt zwei Vorteile: erstens ist UTF-8 ASCII-kompatibel, eine ASCII-Datei ist automatisch eine gültige UTF-8-Datei. Zweitens ist UTF-8 deutlich kompakter als UTF-16 oder UTF-32 für westliche Sprachen, weil die häufigsten Zeichen mit nur einem Byte kodiert werden.

Konkrete Byte-Repräsentationen:

• ‘a’ (U+0061): ein Byte (0x61)
• ‘ü’ (U+00FC): zwei Bytes (0xC3 0xBC)
• ’€’ (U+20AC): drei Bytes (0xE2 0x82 0xAC)
• ’😀’ (U+1F600): vier Bytes (0xF0 0x9F 0x98 0x80)

Wenn du in pdftxt.de UTF-8 als Encoding wählst, schreibt das Tool genau diese Byte-Folgen in die TXT-Datei. Die TextEncoder-API des Browsers macht das für uns, sie unterstützt aber nur UTF-8 (keine Legacy-Encodings), daher implementieren wir Latin-1 und Windows-1252 selbst.

UTF-8 mit BOM: für Excel

UTF-8 mit BOM ist die gleiche Kodierung wie UTF-8, plus einem 3-Byte-Präfix (EF BB BF) am Datei-Anfang. Der Name BOM (Byte Order Mark) ist historisch verwirrend, weil UTF-8 keine Byte-Order hat (das ist nur bei UTF-16 und UTF-32 relevant). Bei UTF-8 dient die BOM ausschließlich als Encoding-Marker: ein Reader, der die Datei öffnet, kann an den ersten drei Bytes erkennen, dass die Datei UTF-8 ist.

In der Praxis brauchst du UTF-8 mit BOM, wenn du die TXT-Datei direkt in Microsoft Excel auf Windows öffnen willst und Umlaute korrekt angezeigt werden sollen. Excel auf Windows hat eine alte Standard-Annahme: TXT-Dateien sind Windows-1252, außer sie haben eine BOM. Ohne BOM interpretiert Excel deine UTF-8-Bytes als Windows-1252 und das deutsche ‘für’ wird zu ‘für’.

Excel auf macOS verhält sich anders und erkennt UTF-8 oft auch ohne BOM. Trotzdem ist UTF-8 mit BOM die robusteste Wahl, wenn du nicht weisst, mit welchem Excel-Build der Empfänger arbeitet. Andere Tools (Notepad, VSCode, jeder moderne Editor) erkennen UTF-8 sowieso, die BOM stört dort nicht.

ISO-8859-1 (Latin-1): der ISO-Klassiker

ISO-8859-1, umgangssprachlich Latin-1, ist ein 8-Bit-Encoding, das Anfang der 1990er Jahre als westeuropäischer Encoding-Standard etabliert wurde. Es kodiert 256 Zeichen, davon 128 ASCII (0 bis 127) und 128 westeuropäische Erweiterungen (128 bis 255).

Latin-1 deckt deutsch (Umlaute), französisch (Akzente), spanisch, italienisch, niederländisch ab. Was nicht in Latin-1 ist:

• Euro-Symbol €
• Typographische Anführungszeichen („”, «», ’)
• Lange Striche (— und –)
• Cyrillisch, Griechisch, Arabisch
• Asiatische Schriften
• Emojis

Wer eine TXT-Datei in Latin-1 schreibt und ein Euro-Zeichen drin hat, hat ein Problem. pdftxt.de löst das durch eine Replacement-Char-Strategie: nicht-kodierbare Zeichen werden durch ein Fragezeichen ? ersetzt, und ein Warning in der UI informiert den Nutzer über den Verlust.

function encodeLatin1(text: string): { bytes: Uint8Array; warning: string | null } {
  const bytes = new Uint8Array(text.length);
  let replaced = 0;
  for (let i = 0; i < text.length; i++) {
    const code = text.charCodeAt(i);
    if (code <= 255) {
      bytes[i] = code;
    } else {
      bytes[i] = 0x3F; // Fragezeichen
      replaced++;
    }
  }
  const warning = replaced > 0
    ? `${replaced} nicht-kodierbare Zeichen wurden durch ? ersetzt.`
    : null;
  return { bytes, warning };
}

Diese Funktion ist absichtlich einfach, weil Latin-1 ein direkter 1:1-Mapping zwischen Unicode-Codepoint und Byte ist (für die Bereiche 0 bis 255). Codepoints darüber werden zum Fragezeichen.

Windows-1252 (CP1252): die Microsoft-Erweiterung

Windows-1252 ist die Microsoft-Variante von Latin-1. Der Unterschied: im Bereich 0x80 bis 0x9F definiert Latin-1 (ISO 8859-1) Steuerzeichen, die kaum genutzt werden. Microsoft hat diesen Bereich umfunktioniert und 27 zusätzliche Zeichen definiert, darunter:

• 0x80: Euro-Symbol €
• 0x82: einfaches Anführungszeichen unten ‚
• 0x83: Florin f
• 0x84: doppeltes Anführungszeichen unten „
• 0x85: Auslassungspunkte …
• 0x91-0x94: typographische Anführungszeichen
• 0x96: kurzer Gedankenstrich, - 0x97: langer Gedankenstrich, Windows-1252 ist deshalb nützlicher als Latin-1, wenn du typographische Anführungszeichen oder das Euro-Symbol behalten willst. Im übrigen ist es Latin-1 identisch.

Die Verwechslung zwischen Latin-1 und Windows-1252 ist so verbreitet, dass viele moderne Tools (Browser, HTML-Parser) bei einer ISO-8859-1-Deklaration tatsächlich Windows-1252 lesen. Der HTML5-Standard schreibt das sogar explizit vor (https://html.spec.whatwg.org/multipage/parsing.html#charset). pdftxt.de implementiert die beiden Encodings strikt nach Standard, ohne diese Verwechslung.

const cp1252Specials: Record<number, number> = {
  0x20AC: 0x80, // €
  0x201A: 0x82, // ‚
  0x0192: 0x83, // ƒ
  0x201E: 0x84, // „
  0x2026: 0x85, // …
  // ... (vollständige Tabelle in der Engine)
};

function encodeCp1252(text: string): { bytes: Uint8Array; warning: string | null } {
  const bytes = new Uint8Array(text.length);
  let replaced = 0;
  for (let i = 0; i < text.length; i++) {
    const code = text.charCodeAt(i);
    if (code <= 0x7F) {
      bytes[i] = code;
    } else if (cp1252Specials[code] !== undefined) {
      bytes[i] = cp1252Specials[code];
    } else if (code >= 0xA0 && code <= 0xFF) {
      bytes[i] = code; // identisch zu Latin-1
    } else {
      bytes[i] = 0x3F;
      replaced++;
    }
  }
  return { bytes, warning: replaced > 0 ? `${replaced} Zeichen ersetzt.` : null };
}

Wann welche Wahl

<rect class="box" x="280" y="50" width="160" height="50"/>
<text class="label" x="360" y="73">Start</text>
<text class="small" x="360" y="89">TXT-Datei aus PDF?</text>

<line class="arrow" x1="360" y1="100" x2="360" y2="125"/>

<rect class="box-alt" x="240" y="125" width="240" height="50"/>
<text class="label" x="360" y="148">Wer öffnet die Datei?</text>

<line class="arrow" x1="280" y1="175" x2="120" y2="220"/>
<line class="arrow" x1="360" y1="175" x2="360" y2="220"/>
<line class="arrow" x1="440" y1="175" x2="600" y2="220"/>

<rect class="box" x="20" y="220" width="200" height="50"/>
<text class="label" x="120" y="240">Excel auf Windows</text>
<text class="small" x="120" y="258">UTF-8 mit BOM</text>

<rect class="box" x="260" y="220" width="200" height="50"/>
<text class="label" x="360" y="240">Moderner Editor</text>
<text class="small" x="360" y="258">UTF-8 (ohne BOM)</text>

<rect class="box" x="500" y="220" width="200" height="50"/>
<text class="label" x="600" y="240">Legacy-System</text>
<text class="small" x="600" y="258">Windows-1252</text>

In der Praxis:

• Default: UTF-8 ohne BOM. Funktioniert für alle modernen Tools und Programmiersprachen.
• Excel-Import: UTF-8 mit BOM. Excel erkennt die BOM und liest UTF-8 korrekt, Umlaute kommen richtig an.
• Legacy-System: Windows-1252. Falls dir ein Tool oder Mainframe-Job sagt es will Latin-1 oder Windows-1252, nimm Windows-1252. Es ist die robustere Variante.
• DATEV / Banking-Software: oft explizit ISO-8859-1, aber meist auch mit Windows-1252 lauffähig. In der Doku des Empfänger-Systems nachschauen.

Was bleibt von der Encoding-Wahl

Encoding ist eines dieser Themen, die in 95 Prozent der Fälle der Default richtig macht, aber in 5 Prozent der Fälle stundenlang Debugging-Sessions kosten. UTF-8 ist heute der Standard, alle modernen Werkzeuge unterstützen es nativ, und alle modernen Datenformate (JSON, XML, HTML, CSS, MD) verwenden es als Default. Legacy-Encodings (Latin-1, Windows-1252) existieren noch, weil alte Mainframe-Jobs und alte DATEV-Importer es weiter erwarten.

pdftxt.de gibt dir die Wahl, weil Encoding ein bewusster Entscheidungspunkt ist, kein Detail. Der Warning bei Replacement-Chars sorgt dafür, dass du nicht stillschweigend Zeichen verlierst. Im Zweifel: UTF-8. Bei Excel-Imports: UTF-8 mit BOM. Bei Legacy-Systemen: das Encoding, das die Doku des Empfängers nennt.