BOM aan ondertitels toevoegen
Of plak ondertiteltekst
Opties
Een BOM bestaat uit drie bytes helemaal aan het begin van het bestand die aangeven in welke codering het is. Hij is onzichtbaar in elke editor en speler, neemt geen ruimte op het scherm in, en aan de ondertitels verandert niets wanneer hij wordt toegevoegd of verwijderd. Twee soorten hulpmiddelen trekken zich er iets van aan: Windows-programma’s die ondertitels schrijven en er standaard een plaatsen, en strikte parsers in build-pipelines die een bestand weigeren dat ermee begint. Deze pagina opent het vak in de stand die haar titel noemt, zodat je het kunt omzetten als je bestand toch anders blijkt te zijn. Een bestand in UTF-16 draagt altijd een BOM, want daaraan ziet een lezer welke van de twee byte-orders hij voor zich heeft — vragen om hem daar te verwijderen laat hem staan.
In welke beeldsnelheid de tijden worden geteld. Op de formaatpagina’s is dit wat MicroDVD nodig heeft, want het slaat tijden op als framenummers. Op de beeldsnelheidspagina’s is het de snelheid waartegen het bestand getimed is — de versie waarvoor de ondertitels gemaakt zijn — en het tweede vak op de pagina neemt de snelheid van de video die je gaat gebruiken. 23,976, 24, 25, 29,97, 30, 50, 59,94 en 60 zijn de gebruikelijke. Een verkeerde waarde verschuift de hele tijdlijn, en op de beeldsnelheidspagina’s verschuift ze die met een verhouding in plaats van met een vast bedrag.
Deze pagina zet een byte-order mark aan het begin van een ondertitelbestand. De BOM is één teken, U+FEFF, dat in UTF-8 als drie bytes wordt geschreven — EF BB BF — en dat een lezer vertelt dat de tekst UTF-8 is nog voordat hij een letter heeft gezien. Het is het kleinste ding dat deze pagina doet en tegelijk het enige dat sommige oudere Windows-editors ervan weerhoudt om een correct bestand als onleesbaar te openen.
De pagina is herhaalbaar. Staat er al een BOM, dan haalt ze hem eerst weg en zet ze er één nieuwe neer, dus twee keer draaien levert precies hetzelfde bestand op als één keer. Dat klinkt als een detail tot je een batch over honderd afleveringen draait waarvan de helft al gemarkeerd binnenkwam: zonder die regel zou de helft met twee BOM’s eindigen en de andere helft met één, en dat verschil zou pas opvallen wanneer een speler de eerste letter van elke regel als rommel toont.
Verder blijft alles precies zoals het was. De regeleinden worden niet aangeraakt, dus een bestand met CRLF komt terug met CRLF; de bloknummers, de tijdcodes en de tekst zijn byte voor byte die van het origineel. De BOM staat voor het bestand, niet in de eerste regel, dus hij verandert niet wat een kijker leest.
Deze pagina is een van de weinige in de tekstcategorie die het document niet aanraken. De parser leest het bestand, maar de uitvoer wordt niet uit de IR opnieuw geschreven — de bytes komen terug met drie extra aan het begin. Dat is bewust: opnieuw serialiseren zou een kans zijn om iets anders te normaliseren, en de vraag was alleen om een markering. Alle twaalf formaten worden geaccepteerd, en niets verlaat je machine.
Voorbeelden
Een SRT-bestand zonder markering
Invoer
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.
Uitvoer
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.
De drie bytes EF BB BF komen voor de eerste `1` te staan, en verder is er niets veranderd: dezelfde tijdcodes, dezelfde twee blokken, dezelfde lege regel ertussen. Een hexweergave laat het verschil in één oogopslag zien, een teksteditor toont vaak niets, en dat is precies waarom deze pagina bestaat — de fout is onzichtbaar tot een programma zich eraan stoort.
Een bestand met CRLF-regeleinden
Invoer
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Uitvoer
1
00:00:01,000 --> 00:00:02,000
The room is dark.
De BOM wordt toegevoegd en de CRLF-regeleinden blijven CRLF. Dat is de tweede helft van de belofte: de pagina voegt één ding toe en normaliseert niets anders. Een tool die tegelijk regeleinden rechtzet, zou een bestand hebben veranderd dat je alleen wilde markeren, en de volgende diff in je versiebeheer zou elke regel als gewijzigd tonen.
Een bestand dat al gemarkeerd is
Invoer
1
00:00:01,000 --> 00:00:02,000
Already marked.
Uitvoer
1
00:00:01,000 --> 00:00:02,000
Already marked.
Het bestand kwam al met een BOM binnen en komt er met precies één BOM uit, niet met twee. De pagina verwijdert eerst wat er staat en zet daarna één markering neer, dus de uitvoer is identiek aan de invoer. Dit is de reden dat de pagina veilig is om op een hele map toe te passen: bestanden die al goed zijn, blijven goed, en je hoeft niet vooraf uit te zoeken welke welke zijn.
Veelgestelde vragen
Wat voegt het toevoegen van een BOM precies aan een ondertitelbestand toe?
Drie bytes, EF BB BF, helemaal aan het begin van het bestand, die samen het teken U+FEFF vormen. Ze staan voor de eerste regel en horen niet bij de tekst, dus een kijker ziet ze nooit en de eerste ondertitel verandert niet. Wat ze doen, is een programma dat het bestand opent vertellen dat de tekst UTF-8 is, wat vooral uitmaakt voor editors die anders moeten raden en soms verkeerd raden.
Wat gebeurt er wanneer een bestand al een BOM heeft?
De pagina haalt de bestaande markering weg en zet er één nieuwe neer, dus het resultaat heeft precies één BOM en verder niets veranderd. Twee keer draaien geeft hetzelfde bestand als één keer. Zonder die regel zou de pagina gewoon bytes toevoegen, en een batch waarin de helft van de bestanden al gemarkeerd was, zou met een mengeling van één en twee markeringen eindigen die niemand had opgemerkt.
Verandert het toevoegen van een BOM de regeleinden of de tijdcodes?
Nee. De pagina raakt alleen de eerste drie bytes aan. Een bestand met CRLF-regeleinden komt terug met CRLF, de bloknummers zijn die van het bestand, en de tijdcodes zijn byte voor byte identiek. Dat is met opzet zo: de uitvoer wordt niet vanuit de tussenliggende representatie opnieuw geschreven, want dat zou een kans zijn om iets anders te normaliseren terwijl de vraag alleen over een markering ging.
Waarom zou ik een BOM aan mijn ondertitels willen toevoegen?
Omdat sommige Windows-programma’s en oudere editors een UTF-8-bestand zonder markering als de systeemcodepage lezen, wat accenten en niet-Latijnse tekens in rommel verandert. Met de markering weten ze het zeker. Het is ook de veilige keuze wanneer je een bestand aan een leverancier of omroep stuurt wiens eigen controle een BOM verwacht — de markering is onzichtbaar voor de kijker en voorkomt een afkeuring die over drie bytes gaat.
Is het toevoegen van een BOM veilig voor elk ondertitelformaat?
Voor de twaalf formaten die deze pagina accepteert wel. De markering staat voor de eerste byte van het bestand, en een parser die UTF-8 verwacht slaat haar over. Bij JSON is het wel de moeite waard om te weten dat de standaard een BOM toestaat maar niet aanraadt, en sommige strikte lezers weigeren haar; bij SRT, WebVTT en de overige tekstformaten is er geen vergelijkbare terughoudendheid. De pagina schrijft de markering en laat de rest van het bestand met rust, dus je kunt het resultaat altijd controleren.
Wordt mijn ondertitelbestand geüpload wanneer ik een BOM toevoeg?
Nee. De pagina draait volledig in je browser en de bytes worden daar gelezen en geschreven. Er gaat geen verzoek met de inhoud van je bestand naar buiten, ook niet als je honderd afleveringen in één keer doet. Dat is dezelfde regel als op de rest van de site: wat je in de tool stopt, blijft op je machine, en de enige netwerkactiviteit is het laden van de pagina zelf.