Fjern BOM fra 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.
Byteordensmerket er ett tegn, U+FEFF, som står foran alt annet i en fil. Mange verktøy skriver det, og mange verktøy forventer det ikke, og de som ikke gjør det, viser det som en liten klump med symboler klistret til starten av den første blokken. Denne siden tar det av og lar alt annet være nøyaktig som det fant det.
Å fjerne det betyr mest der filen slutter å være noe et menneske leser og begynner å være noe et program tolker: undertekstpipeliner, skript som leser den første linjen i en fil, og formater hvis spesifikasjon sier at de første bytene er det første tegnet i den første blokken. Det betyr også noe når filer settes sammen, fordi et merke midt i en sammenføyd fil er et tegn midt i en blokk. Og det betyr noe for levering: sier spesifikasjonen du leverer til, UTF-8 uten merke, er et merke en forskjell kontrolløren vil finne.
Det siden ikke gjør, er å bestemme noe annet for deg. Blokknumre, timekoder, blokktekst og linjeslutter kommer alle tilbake som de gikk inn, også CRLF, og en fil som ikke hadde noe merke, kommer tilbake byte for byte i stedet for å bli skrevet om til noe tilsvarende. Å fjerne et merke er ikke det samme som å endre en fils tegnkoding, og de to blandes ofte sammen: denne siden endrer det første tegnet i filen og ingenting ved hvordan resten av den er kodet.
Det finnes ett tilfelle der tittelen på denne siden og det som faktisk skjer, går fra hverandre, og det er verdt å vite før du kjører. En UTF-16-fil trenger merket sitt: uten ett er det ingen måte å skille de to byteordenene fra hverandre, så en UTF-16-fil skrevet uten merke kan ikke leses tilbake. Sender du en gjennom denne siden, vil den nedlastede filen fortsatt bære et merke, fordi alternativet ville vært en fil ingen kan åpne. Er filen din UTF-16 og merket må bort, er det du vil ha, en annen koding og ikke den samme uten merke, og siden som konverterer kodinger, er lenket nedenfor.
Merket fjernes fra filen du laster ned, så de to rutene kan se identiske ut her — et breddeløst tegn er nøyaktig det et usynlig tegn ser ut som. Kontroller resultatet i kodingsviseren i editoren eller i en hex-viser: en fil uten merke begynner med den første byten i den første blokken. Alle tolv formatene dette nettstedet håndterer, tas imot, fra SRT til en ren tekstranskripsjon, og ingenting lastes opp: filen leses, endres og skrives inne i nettleseren din.
Eksempler
En merket fil, med merket tatt av
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.
Inndataene begynner med U+FEFF og utdataene gjør det ikke: de to filene skiller seg med nøyaktig det ene tegnet, som er hele operasjonen. Filer i denne tilstanden kom vanligvis ut av et Windows-undertekstprogram, og grunnen til at folk vil ha merket bort, er et byggesteg eller en streng tolker som ser på de første bytene i stedet for på blokkene.
En Windows-fil, merke fjernet og vognreturer beholdt
Inndata
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Resultat
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Bare merket går. Hver vognretur er filens egen, og denne siden har ingen mening om dem — den som vil ha begge endret, vil ha linjesluttsiden, og det å holde de to fra hverandre er det som gjør hver av dem trygg å kjøre på en fil du ikke har åpnet. Forventet tekst holder fortsatt sin CRLF nøyaktig som inndataene gjorde.
En fil uten merke, returnert byte for byte
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.
Det var ingenting å fjerne, så filen kommer tilbake uendret — også i å ha ingen merke. Dette er tilfellet som fanger en implementasjon som skriver et merke først og stripper det etterpå, eller som normaliserer filen på veien: den ærlige lesningen av «det var ingenting å gjøre» er inndataene selv, byte for byte, og ikke en ryddet versjon av dem.
Ofte stilte spørsmål
Hvordan ser jeg om undertekstfilen min har et byteordensmerke?
Åpne den i en editor som viser filkodingen, og en UTF-8-fil med merke merkes vanligvis som UTF-8 med BOM eller UTF-8 BOM i stedet for vanlig UTF-8. Ellers kan du se på de første bytene i en hex-viser: en fil som begynner med EF BB BF, bærer ett, og en som begynner med det første tegnet i blokken, gjør det ikke. Klumpen med symboler i starten av den første linjen er det samme sett av et program som leste merket som tre vanlige tegn.
Hvorfor blir merket stående på en UTF-16-undertekstfil etter at jeg fjernet det?
Fordi en UTF-16-fil trenger ett. UTF-16 lagrer hvert tegn som to byte, og de to byteordenene ser like ut utenfra, så merket er det som forteller en leser hvilken orden den er i — en UTF-16-fil uten merke kan ikke leses tilbake, verken av dette nettstedet eller av noe annet. Siden du er på, beholder det av den grunnen. Vil du ha en fil som ikke har noe merke i det hele tatt, endre kodingen til UTF-8 eller Windows-1252 i stedet, der merket er valgfritt.
Skader denne siden en undertekstfil som aldri hadde noe merke?
Nei. Utdataene i det tilfellet er inndataene, byte for byte, og ingenting rapporteres for det. Å kjøre siden på en fil du er usikker på tilstanden til, er trygt av samme grunn: med ingen merke å fjerne er det ingenting å skrive, og med ett er det den minste mulige endringen. En kjøring som ikke fant noe å gjøre, er ikke en kjøring som gjorde noe.
Kan en undertekstfil ha mer enn ett byteordensmerke?
Ja, og det skjer hver gang et verktøy legger til et merke uten å sjekke for ett først — det andre merket lager en fil som ser helt normal ut i en editor mens den skiller seg fra en normal fil i de første bytene. Denne siden fjerner alle i stedet for ett, så en dobbelt merket fil ryddes i én omgang, og å kjøre siden igjen endrer ingenting mer.
Endrer fjerning av et merke kodingen i undertekstfilen min?
Ikke i den betydningen folk vanligvis mener. Teksten i filen er fortsatt de samme tegnene, og resten av den er fortsatt kodet på samme måte; det som endres, er at en leser ikke lenger har filens første byte som forteller den kodingen. En UTF-8-fil uten merke er vanlig UTF-8, som de fleste verktøy antar uansett. Å endre selve kodingen er en egen side, lenket herfra.
Kommer merket tilbake når jeg laster ned undertekstfilen?
Nei. Nedlastingen er øyeblikket filen skrives, og en kjøring av denne siden skriver den uten merke, så det du får, er det de to rutene beskriver. Kodingen en fil skrives i, bevares fra hvordan den ble lest, med én unntak: en fil som kommer som UTF-16, skrives tilbake som UTF-16 og beholder merket sitt, fordi det merket er strukturelt og ikke dekorativt.