BOM uit ondertitels verwijderen
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 haalt de byte-order mark van het begin van een ondertitelbestand weg. De markering is één teken, U+FEFF, dat in UTF-8 drie bytes inneemt en dat sommige programma’s nodig hebben om te weten dat een bestand UTF-8 is, en dat andere programma’s als rommel aan het begin van de eerste regel tonen. Is je bestand bij een leverancier afgekeurd of zie je een vreemd teken voor de eerste ondertitel, dan is dit de pagina.
Alle markeringen aan het begin worden verwijderd, niet alleen de eerste, dus een bestand dat per ongeluk twee of drie keer gemarkeerd is geraakt, komt schoon terug. Verder blijft alles staan. De CRLF-regeleinden blijven CRLF, de tijdcodes en de tekst zijn byte voor byte die van het origineel, en de blokstructuur wordt niet opnieuw opgebouwd.
Een bestand zonder markering komt er byte voor byte identiek uit. Dat is de eigenschap die deze pagina veilig maakt om over een hele map te draaien: je hoeft niet vooraf uit te zoeken welke bestanden gemarkeerd zijn, want de niet-gemarkeerde worden niet herschreven en de gemarkeerde verliezen precies de drie bytes die je kwijt wilde.
Er is één uitzondering, en die is structureel in plaats van cosmetisch. Een bestand dat werkelijk in UTF-16 is opgeslagen, heeft de markering nodig om te kunnen worden gelezen: zonder haar is het onduidelijk of de bytes groot- of klein-endian zijn, en de eerste letter zou onleesbaar worden. Zulke bestanden houden daarom hun structurele markering. Dat is geen fout in de pagina maar de reden dat de pagina de codering niet blindweg aanpast — het verwijderen van een BOM is alleen veilig zolang je weet dat de rest van het bestand UTF-8 is. Alle twaalf formaten worden geaccepteerd, en er wordt niets geüpload.
Voorbeelden
Een SRT-bestand met een BOM
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 drie bytes EF BB BF verdwijnen en de eerste regel begint weer met `1`. De rest van het bestand is niet aangeraakt: dezelfde twee blokken, dezelfde tijdcode, dezelfde lege regel ertussen. In een editor die de markering toonde, verdwijnt het vreemde teken voor de eerste ondertitel; in een editor die haar verborg, verandert er zichtbaar niets en is het bestand toch schoon.
Een bestand met CRLF en een markering
Invoer
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Uitvoer
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
De markering gaat weg en de CRLF-regeleinden blijven CRLF. Dit is de helft die mensen vergeten: een tool die de regeleinden normaliseert terwijl je alleen een markering wilde verwijderen, verandert elke regel in de diff van je versiebeheer en kan een leverancier die CRLF eist alsnog laten afkeuren. Deze pagina raakt alleen de eerste drie bytes aan.
Een bestand zonder markering
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.
Invoer en uitvoer zijn identiek, byte voor byte. Er valt niets te verwijderen en de pagina herschrijft het bestand niet om te bewijzen dat ze heeft gekeken. Daarom kun je deze pagina op een map met gemengde bestanden loslaten: de bestanden die al goed zijn komen onveranderd terug, en alleen de gemarkeerde verliezen iets.
Veelgestelde vragen
Wat verwijdert het verwijderen van een BOM uit een ondertitelbestand?
De bytes EF BB BF aan het begin van het bestand, die samen het teken U+FEFF vormen, en verder niets. Ze staan voor de eerste regel en horen niet bij de tekst, dus het verwijderen verandert geen letter van je ondertitels. Wat je mogelijk wel ziet veranderen, is het eerste teken in een editor die de markering als een zichtbaar teken toonde, en dat is precies het teken dat je kwijt wilde.
Wordt mijn bestand herschreven als het geen BOM had?
Nee. De pagina leest de eerste bytes, ziet dat er niets te verwijderen is en geeft het bestand byte voor byte terug. Er is geen normalisatie van regeleinden, geen herserialisatie van tijdcodes en geen nieuwe codering. Daardoor kun je deze pagina over een hele map draaien zonder eerst uit te zoeken welke bestanden gemarkeerd zijn: de niet-gemarkeerde blijven precies zoals ze waren.
Waarom heeft mijn UTF-16-bestand zijn BOM nog na deze bewerking?
Omdat de markering daar structureel is in plaats van cosmetisch. Bij UTF-16 vertelt ze ook of de bytes groot- of klein-endian zijn; haal je haar weg, dan wordt de eerste letter onleesbaar en kan een lezer het bestand niet meer openen. De pagina herkent dat geval en laat de markering staan. Wil je naar gewone UTF-8 met of zonder markering, gebruik dan de pagina die de tekencodering omzet, want dat is een ander werk met een ander gevolg.
Wat gebeurt er met meerdere BOM’s achter elkaar?
Ze worden allemaal verwijderd, niet alleen de eerste. Een bestand dat per ongeluk een paar keer door een markeringstool is gegaan, kan er meer dan één hebben, en de eerste weghalen zou de volgende als eerste teken van de tekst achterlaten. De pagina blijft bytes aan het begin weghalen zolang ze een BOM vormen, en houdt op bij de eerste byte die dat niet doet.
Verandert het verwijderen van een BOM de regeleinden van mijn ondertitel?
Nee. Een bestand met CRLF-regeleinden komt terug met CRLF, een bestand met LF blijft LF, en een bestand met gemengde regeleinden blijft gemengd. De pagina raakt alleen de eerste bytes aan. Dat is een bewuste beperking: deze pagina doet één ding, en wanneer je ook regeleinden wilt rechtzetten of de codering wilt wijzigen, zijn daar aparte pagina’s voor met een eigen, zichtbaar gevolg.
Wordt mijn ondertitelbestand geüpload wanneer ik een BOM verwijder?
Nee. Het bestand wordt in je browser gelezen en de uitvoer wordt daar gemaakt. Er gaat geen inhoud naar een server, ook niet bij een grote batch. Dat geldt voor alle pagina’s in deze categorie: de enige netwerkactiviteit is het laden van de pagina zelf, en je kunt de tool met een verbroken verbinding blijven gebruiken zodra ze geladen is.