BOM zu Untertiteln hinzufügen
Oder Untertiteltext einfügen
Optionen
Ein BOM sind drei Bytes ganz am Anfang der Datei, die angeben, in welcher Kodierung sie vorliegt. Er ist in jedem Editor und Player unsichtbar, nimmt auf dem Bildschirm keinen Platz ein, und an den Untertiteln ändert sich nichts, wenn er hinzugefügt oder entfernt wird. Zwei Arten von Werkzeugen kümmern sich darum: Windows-Programme, die Untertitel schreiben und standardmäßig eines setzen, und strenge Parser in Build-Pipelines, die eine Datei ablehnen, die damit beginnt. Diese Seite öffnet das Feld in dem Zustand, den ihr Titel nennt, sodass Sie es umschalten können, wenn Ihre Datei sich als umgekehrt herausstellt. Eine Datei in UTF-16 trägt immer ein BOM, denn so erkennt ein Leser, welche der beiden Byte-Reihenfolgen er vor sich hat — das Entfernen an dieser Stelle lässt es stehen.
In welcher Bildrate die Zeitangaben gezählt werden. Auf den Formatseiten ist das, was MicroDVD braucht, denn es speichert Zeitangaben als Bildnummern. Auf den Bildraten-Seiten ist es die Rate, gegen die die Datei getaktet wurde — die Fassung, für die die Untertitel erstellt wurden —, und das zweite Feld der Seite nimmt die Rate des Videos auf, mit dem Sie sie verwenden wollen. 23,976, 24, 25, 29,97, 30, 50, 59,94 und 60 sind die üblichen. Ein falscher Wert verschiebt die gesamte Zeitachse, und auf den Bildraten-Seiten verschiebt er sie um einen Faktor statt um einen festen Betrag.
Eine Byte Order Mark ist ein einziges Zeichen – U+FEFF –, das vor allem anderen in der Datei steht. In UTF-8 sind das drei Bytes, EF BB BF, und es ist das Erste, was ein Leser sieht. Am Ergebnis dieser Seite sieht nichts anders aus: dieselben Blöcke, dieselben Zeitcodes, dieselben Zeilenenden und eine Markierung vor dem ersten davon.
Warum man sie haben will, liegt darin, dass die Markierung die Art ist, wie eine Datei „ich bin UTF-8“ sagt, ohne es zu sagen. Ein Programm, das eine Untertiteldatei öffnet, muss raten, in welcher Kodierung sie vorliegt, und sehr viele tun das – ältere Windows-Player, Authoring-Werkzeuge für Datenträger, Skripte, die die erste Zeile lesen –, indem sie die ersten Bytes ansehen, statt die ganze Datei zu parsen. Mit der Markierung kommen ein akzentuierter Name, ein typografisches Anführungszeichen oder ein griechischer Buchstabe als sie selbst heraus. Ohne sie kann dieselbe Datei als lokale Codepage des Systems gelesen werden, in der diese Zeichen zu etwas völlig anderem werden.
Die andere Richtung begegnet den meisten zuerst: eine Datei mit Markierung, geöffnet von einem Werkzeug, das keine erwartet. Es liest die drei Bytes als drei Zeichen und zeigt sie am Anfang der ersten Zeile – daher kommt der kleine Symbolblock oben in so mancher Untertiteldatei. Wenn Sie das vor sich haben, ist dies die falsche Seite: Die Markierung muss entfernt und nicht hinzugefügt werden, und die Seite dafür ist unten verlinkt.
Was die Seite nicht tut, ist die Datei unterwegs neu zu formatieren. Sie berührt keine CRLF-Zeilenenden, keine Blocknummern, keine Zeiten und keinen Text eines Blocks, und sie entscheidet die Kodierung Ihrer Datei nicht für Sie: Eine Datei, die nicht UTF-8 ist, ist ein anderes Problem, und auch dafür gibt es eine Seite. Sie fügt ein Zeichen ganz vorne hinzu, und ist es bereits da, lässt sie die Datei in Ruhe, statt ein zweites anzuhängen – zweimal laufen lassen ergibt also dieselbe Datei wie einmal.
Die Markierung wird der Datei hinzugefügt, die Sie herunterladen. Die beiden Vorschaufenster können deshalb mit dem Auge identisch sein – ein unsichtbares Zeichen sieht genau so aus, wie ein unsichtbares Zeichen aussieht –, und der ehrliche Weg, das Ergebnis zu prüfen, sind die ersten drei Bytes in einem Hex-Viewer oder die Kodierungsanzeige der Statusleiste Ihres Editors. Alle zwölf Untertitelformate dieser Website können eine Markierung tragen, denn sie ist eine Eigenschaft der ersten Bytes einer Datei und weiß nichts von Blöcken. Nichts wird hochgeladen: Die Datei wird im Browser gelesen, geändert und geschrieben.
Beispiele
Eine ASCII-Untertiteldatei mit Markierung davor
Eingabe
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
Ausgabe
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
Der erwartete Text beginnt mit einem unsichtbaren Zeichen: U+FEFF, den drei Bytes EF BB BF, vor der 1 der ersten Blocknummer. Beide Fenster sehen für Sie gleich aus, und das ist kein Darstellungsfehler – der Unterschied zwischen diesen Dateien ist drei Bytes lang, und keines davon hat eine Form. Laden Sie das Ergebnis herunter und öffnen Sie es in einem Editor, der die Kodierung zeigt, oder sehen Sie sich die ersten Bytes im Hex-Viewer an: Es ist das Erste, was auffällt.
Eine Windows-Datei, Markierung ergänzt und Wagenrückläufe erhalten
Eingabe
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Ausgabe
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Die zwei Dinge, die ein Windows-Untertitelwerkzeug schreibt, sind eine Markierung und CRLF-Zeilenenden, weshalb sie oft verwechselt werden – sie sind aber getrennt, und diese Seite schreibt nur das erste. Jeder Wagenrücklauf in der erwarteten Datei stammt aus der Eingabe, und die Markierung kommt davor. Eine Seite, die auch die Zeilenenden neu schriebe, würde jede ihr übergebene Datei still umformatieren, und genau solche Änderungen bemerkt niemand, bis ein Werkzeug dahinter sie braucht.
Eine Datei, die bereits eine Markierung trägt
Eingabe
1
00:00:01,000 --> 00:00:02,000
Already marked.
Ausgabe
1
00:00:01,000 --> 00:00:02,000
Already marked.
Die Eingabe hat schon eine Markierung, die Ausgabe ist deshalb Byte für Byte die Eingabe – die Datei behält genau eine. Die naive Fassung dieser Seite, die eine Markierung anhängt, ohne das Vorhandene zuerst zu entfernen, erzeugt eine Datei mit zwei; eine doppelte Markierung ist in jedem Editor unsichtbar und für alles, was die ersten Bytes liest, eine andere Datei. Die Seite auf eine bereits markierte Datei anzuwenden, sollte ohne Nachdenken möglich sein.
Häufige Fragen
Was ändert das Anhängen einer Byte Order Mark an eine Untertiteldatei tatsächlich?
Ein Zeichen ganz vorne in der Datei: U+FEFF, in UTF-8 als die drei Bytes EF BB BF geschrieben. Kein Block wird ergänzt, entfernt oder bearbeitet, kein Zeitcode verschiebt sich, Blocknummern und Zeilenenden kommen heraus, wie sie hineingingen, und der Text jeder Zeile bleibt unangetastet. Vergleicht man beide Dateien, unterscheidet sich nur die erste Zeile, und zwar um drei Bytes an ihrem Anfang.
Warum sehen die beiden Vorschaufenster dieser BOM-Seite identisch aus?
Weil das hinzugefügte Zeichen keine Form hat. U+FEFF ist ein Zero-Width No-Break Space, ein Fenster, das Text so darstellt wie Ihr Player, zeigt also vorher und nachher dasselbe. Die Änderung ist real und steckt in der heruntergeladenen Datei: Der Unterschied sind die ersten drei Bytes. Die Kodierungsanzeige Ihres Editors oder ein Hex-Viewer mit EF BB BF am Anfang ist der Ort, an dem man nachsieht, nicht der Text.
Kann man das BOM-Werkzeug bedenkenlos zweimal auf dieselbe Datei anwenden?
Ja. Die Seite entfernt jede vorhandene Markierung, bevor sie ihre eigene schreibt; eine bereits markierte Datei kommt also unverändert zurück, eine unmarkierte bekommt genau eine. Zwei Läufe ergeben dieselbe Datei wie einer. Das bedeutet auch, dass eine Datei, die durch diese Seite und danach durch ein Werkzeug mit zweiter Markierung gegangen ist, mit einem einzigen weiteren Lauf bereinigt werden kann, weil nur eine überlebt.
Bleibt die Markierung erhalten, wenn ich die Datei anschließend in ein anderes Format konvertiere?
Nicht bei den Konvertierungsseiten dieser Website, die schlichtes UTF-8 ohne Markierung schreiben; eine hier hinzugefügte Markierung überlebt einen Formatwechsel also nicht. Ordnen Sie die Arbeit entsprechend: zuerst konvertieren, dann die Markierung als letzten Schritt vor der Abgabe setzen. Das ist ohnehin die vernünftigere Reihenfolge, denn die Markierung gehört zur fertigen Datei und nicht zum Untertitelinhalt.
Ändert eine Markierung die Zeilenenden einer Untertiteldatei?
Nein. Eine UTF-8-Markierung ist ein Zeichen vor dem ersten Byte der Datei und hat keine Wirkung auf das, was folgt. Eine Windows-Datei voller CRLF bleibt voller CRLF, eine Unix-Datei bleibt bei LF, und eine Datei mit gemischten Enden kommt mit derselben Mischung zurück, mit der sie ankam. Zeilenenden zu ändern ist eine andere Seite, und es ist keine gute Idee, eine Seite beides still erledigen zu lassen.
Welche Untertitelformate können eine Byte Order Mark bekommen?
Alle zwölf, die diese Website verarbeitet: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON und CSV. Die Markierung betrifft die ersten Bytes der Datei und nicht das Untertitelformat, es gibt also nichts Formatspezifisches zu beachten – selbst ein schlichtes Text-Transkript ohne jede Zeitachse kann eine tragen.