SRT-Untertitelkodierung reparieren, ohne den Originaltext zu verlieren

Wenn Ihre SRT-Untertitel café statt caféanzeigen, speichern Sie die Datei nicht sofort als UTF-8 ab. Behalten Sie zuerst eine unberührte Kopie der Rohdaten, ermitteln Sie eine Dekodierung, die die korrekten Wörter liefert, und schreiben Sie den geprüften Text in eine separate Datei. Wenn Sie falsche Zeichen in einer neuen Kodierung speichern, zementieren Sie nur die Fehler.

Der entscheidende Unterschied liegt zwischen gültiger Kodierung und korrektem Text. Im ursprünglichen Zwei-Zeilen-Experiment unten besteht eine fehlerhafte Datei eine strikte UTF-8-Prüfung und enthält keinerlei Ersetzungszeichen. Ihr französischer Text ist dennoch falsch. Eine andere besteht denselben Test, nachdem sechs Originalzeichen ersetzt wurden durch �.

Dieser Leitfaden bietet ein lokales Python-Tool zur Inspektion und Konvertierung, herunterladbare Quelldateien und einen reproduzierbaren Test. Er deckt die Diagnose auf Dateiebene und die explizite Konvertierung ab – keine automatische Kodierungserkennung, keine Videosynchronisierung und kein Versprechen, bereits verlorene Zeichen wiederherzustellen.

Zuerst feststellen, was wirklich beschädigt ist

Eine .srt -Endung kennzeichnet ein Untertitelformat, garantiert aber keine bestimmte Kodierung. SRT enthält Cue-Nummern, Zeitstempel, Text und Trennzeichen; der SRT-Formatdatensatz der Library of Congress beschreibt es als reinen Text ohne einheitlichen Zeichenkodierungsstandard.

Nutzen Sie das sichtbare Symptom als Anlass zur Überprüfung, nicht als fertige Diagnose:

Zeichen und ihre dargestellten Formen sind zwei verschiedene Dinge. Pythons Unicode-Dokumentation unterscheidet zwischen Codepunkten und von Schriftarten gerenderten Glyphen. Korrekter Text in einem Editor macht ein Problem auf Player-Seite wahrscheinlich; es beweist jedoch nicht, dass die Installation einer bestimmten Schriftart die Lösung ist. Für diesen Artikel wurden keine spezifischen Schriftarten oder Player getestet.

Bytes sichern, dann die Decodierung prüfen

Laden Sie subtitle_encoding.py herunter und legen Sie die Datei neben der SRT-Datei ab, die Sie analysieren möchten. Diese Befehle erfordern eine vorhandene Python-3-Installation und keine zusätzlichen Pakete. Die lokalen Tests hier wurden mit Python 3.14.3 unter macOS durchgeführt. Falls Ihre Windows-Installation den Python-Launcher verwendet, ersetzen Sie py -3 durch python3; diese Umgebung wurde hier nicht getestet.

Öffnen Sie ein Terminal in diesem Ordner. Ersetzen Sie in diesen Beispielen input.srt durch Ihren tatsächlichen Dateinamen. Behalten Sie Anführungszeichen um Pfade mit Leerzeichen bei.

Eine unveränderte Kopie erstellen

python3 subtitle_encoding.py backup "input.srt" "original-bytes.srt"

Das Ziel darf noch nicht existieren. Das Tool kopiert die Bytes ohne vorherige Decodierung, liest die Kopie zur Überprüfung ein und gibt ihren SHA-256-Hash aus. Der Quellpfad wird zudem als Ziel abgelehnt. Behalten Sie dieses Backup auch dann, wenn Sie bereits eine funktionierende Untertiteldatei erstellt haben.

UTF-8 prüfen, ohne etwas zu speichern

python3 subtitle_encoding.py inspect "original-bytes.srt"

Der Bericht enthält strict_utf8, utf8_bom, die gewählte Decodierung und – falls diese erfolgreich ist – eine Textvorschau sowie replacement_characters -Anzahl an. Die Standard-Textansicht verwendet utf-8-sig, was eine führende UTF-8-Signatur korrekt verarbeitet.

• strict_utf8: false bedeutet, dass die Bytes die UTF-8-Prüfung nicht bestehen. Es verrät nicht , welche andere Kodierung die richtige ist.
• strict_utf8: true bedeutet, dass sie als UTF-8 dekodiert werden können. Es bedeutet nicht , dass die Wörter auch inhaltlich korrekt sind.
• Ein Ersetzungszähler ungleich null bedeutet, dass die gewählte Dekodierung U+FFFD-Zeichen erzeugt hat. Untersuchen Sie diese, bevor Sie eine neue Datei erstellen.

Die Überprüfung gibt ASCII-sicheres JSON aus, damit eine Terminal-Schriftart die Zeichenidentität nicht verschleiern kann: \u00e9 bedeutet é, und \ufffd steht für das Ersetzungszeichen. Um eine verdächtige Zeile im Detail zu untersuchen, fragen Sie deren physische Zeilennummer ab – nicht die Cue-Nummer:

python3 subtitle_encoding.py inspect "original-bytes.srt" --encoding cp1252 --line 3

Dies ist ein schreibgeschützter Test von Windows-1252, Pythons Codec cp1252 . Verwenden Sie ihn, wenn die Exporteinstellungen oder der Ursprung der Datei diese Wahl stützen, und nicht nur, weil in diesem Beispiel zufällig Französisch vorkam. Der Zeilenbericht benennt jedes Zeichen und zeigt dessen Codepoint an; U+20AC ist das Euro-Zeichen.

Wählen Sie die Kodierung anhand von Belegen, nicht nach der ersten lesbaren Vorschau

Fragen Sie den Ersteller der Datei nach der tatsächlichen Exportkodierung, prüfen Sie die Einstellungen des Exportprogramms oder vergleichen Sie den Text mit einem verlässlichen Originaltranskript. Prüfen Sie Namen mit Akzenten, Satzzeichen, Währungszeichen und repräsentative Zeilen in der gesamten Datei. Wenn Sie die Sprache nicht beherrschen, kann ein fehlerfrei durchlaufender Decoder diese Prüfung nicht für Sie übernehmen.

„ANSI“ ist nicht präzise genug, um den Quellcodec auszuwählen. Ebenso wenig sind Windows-1252 und Latin-1 austauschbar. Im bereitgestellten Experiment wird das einzelne Byte 80 unter € zu cp1252dekodiert, unter Latin-1 jedoch zum Steuerzeichen U+0080 unter latin-1. Beide Operationen sind erfolgreich. Nur die bekannte Quelle verrät, welche davon beabsichtigt ist.

Andere Sprachen verwenden möglicherweise andere veraltete Kodierungen, doch ein Sprachname allein legt noch keine Kodierung fest. Wenn der Ursprung unklar ist und die Lesarten der verschiedenen Kandidaten voneinander abweichen, stoppen Sie vor der Konvertierung und beschaffen Sie verlässlichere Nachweise zur Quelle.

Erst konvertieren, wenn der Quelltext lesbar ist

Für eine Quelle, die nachweislich als Windows-1252 kodiert ist, erstellen Sie eine separate UTF-8-Datei:

python3 subtitle_encoding.py convert "original-bytes.srt" "repaired-utf8.srt" --from-encoding cp1252
python3 subtitle_encoding.py inspect "repaired-utf8.srt"

Der Konverter dekodiert die gesamte Quelle strikt, kodiert diesen Text als UTF-8, prüft, ob das erneute Dekodieren der Ausgabe exakt denselben Text liefert, und liest die geschriebenen Bytes zurück. Nummerierungen, Zeitstempel, Dialoge, Tags oder Zeilenenden werden dabei nicht verändert. Die neue Bytefolge kann sich unterscheiden, auch wenn der dekodierte Text völlig identisch bleibt.

Er verweigert ganz bewusst Folgendes:

• eine vorhandene Zieldatei zu überschreiben;
• nach einem strikten Dekodierungsfehler fortzufahren; oder
• Text zu schreiben, der U+FFFD enthält, selbst wenn dieses Zeichen beabsichtigt war.

Die letzte Einschränkung ist bewusst vorsichtig gewählt: Dieses Werkzeug kann nicht entscheiden, was ein Ersetzungszeichen ursprünglich darstellen sollte. Würde man es entfernen, nur damit der Befehl durchläuft, ginge wertvoller Nachweis verloren, anstatt den Text wiederherzustellen. Pythons Dokumentation zu Fehler-Handlern erklärt, warum replace und ignore sich vom strikten Dekodieren unterscheiden: Sie ersetzen oder verwerfen problematische Daten. Keines von beiden gehört in diesen Konvertierungsschritt.

Tritt ein E/A-Fehler auf, verwenden Sie die fehlerhafte Ausgabe nicht. Es kann eine unvollständige neue Datei zurückbleiben; behalten Sie das Original und wählen Sie für einen späteren Versuch einen neuen Zielnamen. Das vollständige Verhalten des Werkzeugs und dessen Verwendung finden Sie in der herunterladbaren README.

Was ist mit UTF-8 mit BOM?

Ein UTF-8-BOM ist die einleitende Bytefolge EF BB BF. Pythons utf-8-sig -Codec verarbeitet diese Signatur beim Dekodieren und fügt sie beim Kodieren hinzu.

Verwenden Sie für eine bestätigte UTF-8-Quelle mit BOM --from-encoding utf-8-sig. Das Tool schreibt UTF-8 normalerweise ohne BOM; fügen Sie --with-bom nur hinzu, wenn die Anforderungen der Zielanwendung dies erfordern. Das Ändern eines BOM kann nicht café in caféverwandeln. Dieses Experiment begründet keine Kompatibilität mit einem bestimmten Player, Editor oder einer bestimmten Upload-Plattform.

Fünf kleine Dateien zeigen, warum reine UTF-8-Gültigkeit nicht ausreicht

Das Experiment verwendet zwei vollständig selbst verfasste französische Untertitel-Cues. Sie stammen weder aus einem Film noch von einem Kunden oder aus einem Übersetzungsprodukt:

1
00:00:01,000 --> 00:00:04,000
Émile dit : « Le prix est de 12,50 €. »

2
00:00:05,000 --> 00:00:08,000
Le café est fermé.

Am 13. September 2026 generierte ein Python-3.14.3-Standardbibliotheks-Skript fünf Byte-Darstellungen und verglich jede einzelne mit dieser bekannten Quelle. Hierbei handelt es sich um deterministische Byte- und String-Prüfungen, nicht um einen Benchmark für die Übersetzungsqualität. Speichern Sie die verlinkten Dateien direkt auf der Festplatte, anstatt deren Browser-Vorschauen zu kopieren: Die unterschiedlichen Bytes machen den Kern des Experiments aus.

Jede Kopie behält dieselben zwei Zeitstempel-Zeichenketten bei. Die korrekt konvertierte Datei ist Byte für Byte identisch mit dem UTF-8-Original. Die beiden beschädigten UTF-8-Dateien belegen einen spezifischeren, aber nützlichen Punkt: Weder eine gültige Zeichenkodierung noch unveränderte Zeitstempel garantieren korrekten Untertiteltext. Übereinstimmende Zeitstempel sagen zudem nichts darüber aus, ob diese erfundene Spur zu einem echten Video passt.

Um die fünf Dateien selbst zu reproduzieren, laden Sie reproduce.py herunter und führen Sie es mit einem Verzeichnisnamen aus, der noch nicht existiert:

python3 reproduce.py encoding-experiment

Das Skript schreibt die Testdaten und eine results.json , die den vollständigen Text, Transformationen, Hashes, die Laufzeitversion und Assertionen enthält. Vergleichen Sie sie mit den aufgezeichneten Experimentergebnissen; der Erstellungszeitstempel wird abweichen. Die Skripte und die originalen Lehrdateien enthalten eine MIT-Lizenz.

Die lokalen Konverterprüfungen testeten zudem die Verweigerung bei bereits vorhandener Ausgabedatei, die Verweigerung ungültiger Quellpfade, Fehler bei inkorrektem Codec, die Verweigerung von U+FFFD, die Beibehaltung von CRLF und die explizite BOM-Ausgabe. Diese Tests verifizieren das Dateiverhalten dieses Tools. Sie testen weder das Rendering in Playern noch das Timing bei echten Medien oder die Übersetzung mit BookTranslator.

Wenn die fehlerhaften Zeichen bereits gespeichert wurden

Gespeichertes Mojibake: die genaue Vorgeschichte ermitteln

Unsere Mojibake-Kopie entstand durch eine bekannte Kette: Die ursprünglichen UTF-8-Bytes wurden als Windows-1252 dekodiert, und diese falschen Zeichen wurden anschließend als UTF-8 gespeichert. Das Ergebnis enthält café und die fehlerhafte Euro-Sequenz €.

Da bei dieser speziellen Transformation keine Bytes verloren gingen, kann das Reproduktionsskript sie umkehren: Kodieren Sie den fehlerhaften Text zurück mit cp1252und dekodieren Sie die resultierenden Bytes anschließend als UTF-8. Es gleicht den wiederhergestellten Text mit dem Original ab.

Das ist ein Beleg für diese bekannte Kette, keine Anweisung, pauschal eine „Mojibake-Reparatur“ auf jede SRT-Datei anzuwenden. Eine Datei kann legitime Zeichen, gemischte Entstehungsgeschichten oder Text enthalten, der bereits durch einen früheren Reparaturversuch verändert wurde. Bevorzugen Sie stets die unberührte Quelle und den regulären Konvertierungspfad. Wenn nur noch das gespeicherte Mojibake vorliegt, sichern Sie es und klären Sie, wie es entstanden ist, bevor Sie eine inverse Transformation an einer Kopie versuchen.

Gespeicherte Ersetzungszeichen: Der fehlende Buchstabe ist dort nicht mehr kodiert

Das Verlustbeispiel entstand, indem Windows-1252-Bytes mit aktivierter Ersetzung als UTF-8 dekodiert und das Ergebnis anschließend gespeichert wurde. Unterschiedliche Originalzeichen wurden dabei zum selben � -Zeichen. Das gespeicherte Ersetzungszeichen enthält nicht mehr genügend Informationen, um festzustellen, welches ursprüngliche Zeichen an dieser Stelle stand.

Verwechseln Sie dies nicht damit, bloß � in einer App zu sehen. Solange die Original-Bytes unberührt geblieben sind, kann eine korrekte Dekodierung den Text noch retten – genau wie bei unserer Windows-1252-Quelldatei. Prüfen Sie diese Quelle, bevor Sie den Text als verloren abstempeln.

Wenn in der einzig verbliebenen Kopie fehlender Text tatsächlich durch U+FFFD oder buchstäbliche Fragezeichen ersetzt wurde, sollten Sie die Datei neu exportieren, eine saubere Quelle beschaffen oder eine manuelle Transkription anhand verlässlicher Vorlagen abgleichen. Ein normales Fragezeichen kann zudem ein legitimes Satzzeichen sein; sein bloßes Vorhandensein beweist noch nichts. Eine plausible Textergänzung durch ein KI-Modell ist lediglich eine Vermutung, keine Wiederherstellung der ursprünglichen Dateidaten.

Ziel ist eine lesbare Quelle – nicht nur ein fehlerfreier Befehl

Bevor Sie die reparierte Datei übernehmen, sollten Sie repräsentative Wörter und Sonderzeichen mit der verlässlichen Vorlage abgleichen, sicherstellen, dass Cue-Nummern und Zeitstempelzeilen unverändert geblieben sind, und die neue Datei in der Zielanwendung öffnen. Das Skript sichert dekodierten Text; es ersetzt weder eine SRT-Syntaxprüfung noch einen Abnahmetest beim Abspielen.

Wenn Sie die Untertitel jetzt problemlos lesen können und keine weitere Sprache benötigen, ist die Arbeit getan. Falls Sie ein praktisches Video-Review oder zusätzliche Bearbeitungsschritte planen, stellt der Vergleich von Untertitel-Software die verschiedenen Werkzeuge und deren Aufgaben vor.

Erst wenn der Quelltext verlässlich ist – und Sie tatsächlich eine Übersetzung benötigen –, sollten Sie zu BookTranslators Untertitel-Übersetzer und dem Workflow für KI-Untertitelübersetzungübergehen. Betrachten Sie die Reparatur der Zeichenkodierung, die Übersetzung und die abschließende Wiedergabeprüfung als getrennte Schritte. Keiner davon garantiert automatisch den Erfolg der anderen.