Tilføj BOM til undertekster
Eller indsæt underteksttekst
Indstillinger
Et BOM er tre bytes helt i begyndelsen af filen, som angiver, hvilken tegnkodning den er i. Det er usynligt i alle editorer og afspillere, det optager ingen plads på skærmen, og intet i underteksterne ændres, når det tilføjes eller fjernes. To slags værktøjer bekymrer sig om det: Windows-programmer, der skriver undertekster, som sætter et ind som standard, og strenge parsere i byggepipelines, som afviser en fil, der starter med et. Denne side åbner boksen i den tilstand, dens titel nævner, så du kan vende den, hvis din fil viser sig at være den anden vej rundt. En fil i UTF-16 har altid et BOM, fordi det er sådan en læser ved, hvilken af de to byteordener den ser på – at bede om at fjerne et der lader det blive.
Hvilken billedhastighed tiderne tælles i. På formatsiderne er det, hvad MicroDVD har brug for, fordi formatet gemmer tider som billednummer. På siderne om billedhastighed er det den hastighed, filen blev timet efter – den version, underteksterne blev lavet til – og sidens anden boks tager hastigheden for den video, du skal bruge dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 og 60 er de almindelige. Tager man fejl, forskydes hele tidslinjen, og på siderne om billedhastighed forskydes den med et forhold i stedet for et fast beløb.
Et byte order mark er ét tegn — U+FEFF — der står foran alt andet i filen. I UTF-8 er det tre byte, EF BB BF, og det er det første, en læser ser. Intet i denne sides output ser anderledes ud: samme tekstblokke, samme tidsstempler, samme linjeskift og et mærke foran det første.
Grunden til, at nogen vil have det der, er, at mærket er måden, en fil siger »jeg er UTF-8« på uden at sige det. Et program, der åbner en undertekstfil, må gætte, hvilken tegnkodning den er i, og en stor del af dem — ældre Windows-afspillere, værktøjer til disc-authoring, scripts der læser den første linje — afgør det ved at se på de første byte i stedet for at parse hele filen. Giv dem mærket, og et navn med accent, et krøllet citationstegn eller et græsk bogstav kommer ud som sig selv. Lad det være, og samme fil kan blive læst som systemets lokale kodebog, hvor de tegn bliver noget helt andet.
Den anden retning er den, folk oftest møder først: en fil med et mærke, åbnet af et værktøj, der ikke forventer et. Værktøjet læser de tre byte som tre tegn og viser dem i begyndelsen af den første linje, og det er der, den lille blok af symboler øverst i nogens undertekstfil kommer fra. Er det, du ser på, dette, er det den forkerte side — mærket skal fjernes i stedet for tilføjes, og siden, der gør det, er linket nedenfor.
Det, siden ikke gør, er at omformatere din fil undervejs. Den rører ikke CRLF-linjeskift, tekstbloknumre, tider eller teksten i nogen tekstblok, og den afgør ikke din fils tegnkodning for dig: en fil, der ikke er UTF-8, er et andet problem, og der er en side til det også. Det, den gør, er at tilføje ét tegn helt foran, og hvis tegnet allerede er der, lader den filen være i stedet for at tilføje et mere, så at køre siden to gange giver samme fil som at køre den én gang.
Mærket føjes til den fil, du downloader. De to ruder på siden kan derfor være identiske for øjet — et usynligt tegn er præcis, hvad et usynligt tegn ser ud som — og den ærlige måde at kontrollere resultatet på er at se på de første tre byte i en hex-viser eller på filens tegnkodning i editorens statuslinje. Alle tolv undertekstformater på siden kan bære et mærke, fordi et mærke er en egenskab ved filens åbningsbyte og intet ved tekstblokke. Intet uploades på noget tidspunkt: filen læses, ændres og skrives i din browser.
Eksempler
En ASCII-undertekstfil med et mærke foran
Input
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.
Resultat
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.
Den forventede tekst begynder med et usynligt tegn: U+FEFF, de tre byte EF BB BF, før 1-tallet i det første tekstbloknummer. De to ruder vil se ens ud for dig, og det er ikke en gengivelsesfejl — forskellen mellem filerne er tre byte lang, og ingen af dem har en form. Download resultatet og åbn det i en editor, der viser tegnkodningen, eller se de første byte i en hex-viser, og det er det første, du ser.
En Windows-fil, hvor mærket tilføjes og carriage return bevares
Input
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Resultat
1
00:00:01,000 --> 00:00:02,000
The room is dark.
De to ting, et Windows-undertekstværktøj skriver, er et mærke og CRLF-linjeskift, og derfor bliver de slået sammen — men de er adskilte, og denne side skriver kun det første. Hvert carriage return i den forventede fil er inputtets eget, og mærket tilføjes foran dem. En side, der også skrev linjeskiftene om, ville stille og roligt omformatere enhver fil, den fik, og det er netop den slags ændring, ingen bemærker, før et værktøj længere fremme i kæden går op i det.
En fil, der allerede bærer et mærke
Input
1
00:00:01,000 --> 00:00:02,000
Already marked.
Resultat
1
00:00:01,000 --> 00:00:02,000
Already marked.
Inputtet har allerede et mærke, så outputtet er inputtet byte for byte — filen beholder præcis ét. Den naive version af denne side, som sætter et mærke på uden først at fjerne det, der er der, laver en fil med to, og et fordoblet mærke er usynligt i enhver editor, mens det er en anden fil for alt, der læser åbningsbytene. At køre siden på en allerede markeret fil skal være noget, du kan gøre uden at tænke over det.
Ofte stillede spørgsmål
Hvad ændrer det egentlig, når jeg tilføjer et byte order mark til en SRT-fil?
Ét tegn helt foran i filen: U+FEFF, skrevet som de tre byte EF BB BF i UTF-8. Ingen tekstblok tilføjes, fjernes eller redigeres, intet tidsstempel flytter sig, tekstbloknumre og linjeskift kommer ud, som de gik ind, og teksten på hver linje er urørt. Diffier du de to filer, er den eneste linje, der afviger, den første, og den afviger med tre byte i sin begyndelse.
Hvorfor ser de to ruder på denne BOM-side identiske ud?
Fordi det tegn, der tilføjes, ikke har nogen form. U+FEFF er et nulbredt hårdt mellemrum, så en rude, der gengiver tekst, som din afspiller ville gøre, viser det samme før og efter. Ændringen er virkelig og findes i den fil, du downloader: forskellen er de første tre byte. Din editors tegnkodningsindikator eller en hex-viser, der viser EF BB BF i begyndelsen, er der, du skal lede, ikke i teksten.
Er det sikkert at køre BOM-værktøjet to gange på samme undertekstfil?
Ja. Siden fjerner ethvert mærke, der allerede findes, før den skriver sit eget, så en fil, der allerede bærer et, kommer uændret tilbage, og en fil uden får præcis ét. To kørsler giver samme fil som én. Det betyder også, at en fil, der har været gennem denne side og derefter gennem et værktøj, der tilføjede endnu et mærke, kan ryddes ved at sende den gennem siden én gang, fordi kun ét overlever.
Beholdes mærket, hvis jeg bagefter konverterer filen til VTT?
Ikke af konverteringssiderne her, som skriver ren UTF-8 uden mærke, så et mærke tilføjet her føres ikke med gennem et formatskift. Planlæg arbejdet derefter: konverter først, og tilføj mærket som det sidste trin før levering. Det er også den mere fornuftige rækkefølge generelt, fordi mærket er en egenskab ved den færdige fil og ikke ved undertekstindholdet.
Ændrer et BOM på en undertekstfil dens CRLF-linjeskift?
Nej. Et UTF-8-mærke er ét tegn placeret før filens første byte og har ingen virkning på det, der følger. En Windows-fil fuld af CRLF forbliver fuld af CRLF, en Unix-fil bliver på LF, og en fil med blandede linjeskift kommer ud med samme blanding, som den ankom med. At ændre linjeskift er en anden side, og det er en dårlig idé at lade én side stiltiende gøre begge ting.
Hvilke undertekstformater kan få et byte order mark?
Alle tolv på siden: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON og CSV. Mærket handler om filens åbningsbyte og ikke om undertekstformatet, så der er intet formatspecifikt at ramme — selv en ren teksttransskription, som slet ikke har nogen tidslinje, kan bære et.