Legg til BOM i undertekster
Eller lim inn underteksttekst
Innstillinger
Et BOM er tre byte helt i starten av filen som sier hvilken tegnkoding den er i. Det er usynlig i hver editor og spiller, det tar ingen plass på skjermen, og ingenting i undertekstene endres når det legges til eller fjernes. To slags verktøy bryr seg om det: Windows-programmer som skriver undertekster, og som legger inn ett som standard, og strenge lesere i byggeprosesser, som avviser en fil som starter med ett. Denne siden åpner boksen i tilstanden tittelen navngir, så du kan snu den hvis filen din viser seg å være motsatt vei. En fil i UTF-16 har alltid et BOM, fordi det er slik en leser vet hvilken av de to byteordenes rekkefølger den ser på — å be om å fjerne ett der lar det stå.
Hvilken bildefrekvens tidene telles i. På formatsidene er det dette MicroDVD trenger, fordi det lagrer tid som bildenummer. På sidene for bildefrekvens er det frekvensen filen ble tidsstyrt mot — versjonen undertekstene ble laget for — og sidens andre boks tar frekvensen til videoen du skal bruke dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 og 60 er de vanlige. Tar du feil, forskyves hele tidslinjen, og på bildefrekvenssidene forskyves den med et forhold i stedet for et fast beløp.
Et byteordensmerke er ett tegn — U+FEFF — som står foran alt annet i filen. I UTF-8 er det tre byte, EF BB BF, og det er det første en leser ser. Ingenting i utdataene fra denne siden ser annerledes ut: de samme blokkene, de samme timekodene, de samme linjesluttene, og et merke foran det første av dem.
Grunnen til at noen vil ha det der, er at merket er måten en fil sier «jeg er UTF-8» uten å si det. Et program som åpner en undertekstfil, må gjette hvilken tegnkoding den er i, og svært mange av dem — eldre Windows-avspillere, verktøy for plateutgivelser, skript som leser første linje — avgjør ved å se på de første bytene framfor å prøve å tolke hele filen. Gir du dem merket, kommer et navn med aksent, et typografisk anførselstegn eller en gresk bokstav ut som seg selv. Lar du det være, kan den samme filen bli lest som systemets lokale koding, der tegnene blir noe helt annet.
Den andre retningen er den folk oftest møter først: en fil som har et merke, åpnet av et verktøy som ikke forventer det. Det verktøyet leser de tre bytene som tre tegn og viser dem i starten av første linje, som er der den lille klumpen med symboler øverst i noens undertekstfil kommer fra. Er det du ser på, er dette feil side — merket skal fjernes og ikke legges til, og siden som gjør det, er lenket nedenfor.
Det siden ikke gjør, er å omformatere filen på veien. Den rører ikke CRLF-linjeslutt, blokknumre, tider eller teksten i noen blokk, og den avgjør ikke filens tegnkoding for deg: en fil som ikke er UTF-8, er et annet problem, og det finnes en side for det også. Det den gjør, er å legge til ett tegn helt fremst, og hvis tegnet allerede er der, lar den filen stå i fred framfor å legge til et andre, så å kjøre siden to ganger gir samme fil som å kjøre den én gang.
Merket legges til filen du laster ned. De to rutene på denne siden kan derfor være identiske for øyet — et usynlig tegn er nøyaktig det et usynlig tegn ser ut som — og den ærlige måten å kontrollere resultatet på, er å se på de tre første bytene i en hex-viser eller på filens koding i statuslinjen i editoren. Alle tolv undertekstformatene dette nettstedet håndterer, kan bære et merke, fordi et merke er en egenskap ved filens første byte og ikke vet noe om blokker. Ingenting lastes opp på noe tidspunkt: filen leses, endres og skrives inne i nettleseren din.
Eksempler
En ASCII-undertekstfil med et merke foran
Inndata
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.
Forventet tekst begynner med et usynlig tegn: U+FEFF, de tre bytene EF BB BF, foran 1 i det første blokknummeret. De to rutene vil se like ut for deg, og det er ingen gjengivelsesfeil — forskjellen mellom disse filene er tre byte lang, og ingen av dem har en form. Last ned resultatet og åpne det i en editor som viser kodingen, eller se på de første bytene i en hex-viser, så er det det første du ser.
En Windows-fil, merke lagt til og vognreturer beholdt
Inndata
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 tingene et Windows-undertekstverktøy skriver, er et merke og CRLF-linjeslutt, som er hvorfor de blir blandet sammen — men de er atskilte, og denne siden skriver bare det første. Hver vognretur i forventet fil er inndataens egen, og merket legges foran dem. En side som skrev om linjesluttene også, ville stille omformatert hver fil den fikk, som er nettopp den slags endring ingen merker før et verktøy lenger ned i kjeden bryr seg.
En fil som allerede bærer et merke
Inndata
1
00:00:01,000 --> 00:00:02,000
Already marked.
Resultat
1
00:00:01,000 --> 00:00:02,000
Already marked.
Inndataene har allerede et merke, så utdataene er inndataene byte for byte — filen beholder nøyaktig ett. Den naive versjonen av denne siden, som limer på et merke uten først å fjerne det som er der, lager en fil med to, og et doblet merke er usynlig i alle editorer mens det er en annen fil for alt som leser de første bytene. Å kjøre siden på en fil som allerede er merket, bør være noe du kan gjøre uten å tenke over det.
Ofte stilte spørsmål
Hva endrer det egentlig å legge et byteordensmerke til en undertekstfil?
Ett tegn helt fremst i filen: U+FEFF, skrevet som de tre bytene EF BB BF i UTF-8. Ingen blokk legges til, fjernes eller redigeres, ingen timekode flytter seg, blokknumrene og linjesluttene kommer ut som de kom inn, og teksten i hver linje er urørt. Differ du de to filene, er den eneste linjen som skiller seg, den første, og den skiller seg med tre byte i starten.
Hvorfor ser de to rutene på denne BOM-siden identiske ut?
Fordi tegnet som legges til, ikke har noen form. U+FEFF er et breddeløst hardt mellomrom, så en rute som gjengir tekst slik avspilleren din ville gjort, viser det samme før og etter. Endringen er reell og ligger i filen du laster ned: forskjellen er de tre første bytene. Kodingsviseren i editoren din, eller en hex-viser som viser EF BB BF i starten, er der du skal se etter den, ikke i teksten.
Er det trygt å kjøre denne BOM-siden to ganger på samme fil?
Ja. Siden fjerner ethvert merke som allerede finnes, før den skriver sitt eget, så en fil som allerede bærer ett, kommer tilbake uendret, og en fil som ikke gjør det, får nøyaktig ett. To kjøringer gir samme fil som én. Det betyr også at en fil som har vært gjennom denne siden og deretter gjennom et verktøy som la til et andre merke, kan ryddes ved å sende den gjennom én gang, fordi bare ett overlever.
Beholdes merket hvis jeg konverterer undertekstfilen til et annet format etterpå?
Ikke av konverteringssidene på dette nettstedet, som skriver vanlig UTF-8 uten merke, så et merke lagt til her, blir ikke med over en formatendring. Planlegg arbeidet deretter: konverter først, og legg så til merket som siste trinn før levering. Det er også den mer fornuftige rekkefølgen generelt, siden merket er en egenskap ved den ferdige filen og ikke ved undertekstinnholdet.
Endrer et merke i en undertekstfil linjesluttene?
Nei. UTF-8-merket er ett tegn plassert foran den første byten i filen og har ingen virkning på det som følger. En Windows-fil full av CRLF forblir full av CRLF, en Unix-fil forblir på LF, og en fil med blandede slutter kommer ut med samme blanding som den kom med. Å endre linjeslutt er en annen side, og det er en dårlig idé å la én side stille gjøre begge.
Hvilke undertekstformater kan få et byteordensmerke?
Alle tolv dette nettstedet håndterer: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON og CSV. Merket handler om filens første byte og ikke om undertekstformatet, så det er ingenting formatspesifikt å få riktig — selv en ren tekstranskripsjon, som ikke har noen tidslinje i det hele tatt, kan bære ett.