Fjern BOM fra 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.
Byte order mark er ét tegn, U+FEFF, der står foran alt andet i en fil. Masser af værktøjer skriver det, og masser af værktøjer forventer det ikke, og dem, der ikke gør, viser det som en kort blok symboler klæbet til begyndelsen af den første tekstblok. Denne side tager det af og lader alt andet være præcis, som den fandt det.
At fjerne det betyder mest, hvor filen holder op med at være noget, et menneske læser, og begynder at være noget, et program parser: undertekst-pipelines, scripts der læser den første linje i en fil, og formater, hvis specifikation siger, at åbningsbytene er det første tegn i den første tekstblok. Det betyder også noget, når filer sammenkædes, fordi et mærke midt i en sammenføjet fil er et tegn midt i en tekstblok. Og det betyder noget ved levering: hvis specifikationen, du leverer til, siger UTF-8 uden mærke, er et mærke en forskel, kontrollen vil finde.
Det, siden ikke gør, er at beslutte noget andet for dig. Tekstbloknumre, tidsstempler, tekstbloktekst og linjeskift kommer alle tilbage, som de gik ind, også CRLF, og en fil uden mærke kommer byte for byte tilbage i stedet for at blive skrevet om til noget tilsvarende. At fjerne et mærke er ikke det samme som at ændre en fils tegnkodning, og de to forveksles ofte: denne side ændrer filens første tegn og intet ved, hvordan resten er kodet.
Der er ét tilfælde, hvor denne sides titel og det, der faktisk sker, går fra hinanden, og det er værd at vide, før du kører den. En UTF-16-fil har brug for sit mærke: uden ét er der ingen måde at skelne de to byteordener, så en UTF-16-fil skrevet uden mærke kan ikke læses tilbage. Send en gennem denne side, og den downloadede fil vil stadig bære et mærke, fordi alternativet ville være en fil, ingen kan åbne. Er din fil UTF-16, og skal mærket væk, er det en anden tegnkodning, du vil have, og ikke den samme uden mærket, og siden, der konverterer tegnkodninger, er linket nedenfor.
Mærket fjernes fra den fil, du downloader, så de to ruder kan se identiske ud her — et nulbredt tegn er præcis, hvad et usynligt tegn ser ud som. Kontroller resultatet i editorens tegnkodningsindikator eller i en hex-viser: en fil uden mærke starter med den første byte i sin første tekstblok. Alle tolv formater på siden accepteres, fra SRT til en ren teksttransskription, og intet uploades: filen læses, ændres og skrives i din browser.
Eksempler
En markeret fil, hvor mærket tages af
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.
Inputtet starter med U+FEFF, og outputtet gør ikke: de to filer adskiller sig med præcis det ene tegn, og det er hele operationen. Filer i denne tilstand kommer normalt ud af et Windows-undertekstprogram, og grunden til, at folk vil have mærket væk, er et build-trin eller en streng parser, der ser på åbningsbytene i stedet for på tekstblokkene.
En Windows-fil, hvor mærket fjernes og carriage return bevares
Input
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.
Kun mærket forsvinder. Hvert carriage return er filens eget, og denne side har ingen holdning til dem — den, der vil have begge ændret, skal bruge linjeskiftssiden, og at holde de to adskilt er det, der gør hver af dem sikker at køre på en fil, du ikke har åbnet. Den forventede tekst rummer stadig sine CRLF præcis som inputtet.
En fil uden mærke, returneret byte for byte
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.
Der var intet at fjerne, så filen kommer uændret tilbage — også uden mærke. Det er det tilfælde, der fanger en implementering, som først skriver et mærke og derefter fjerner det, eller som normaliserer filen undervejs: den ærlige læsning af »der var intet at gøre« er inputtet selv, byte for byte, og ikke en ryddelig version af det.
Ofte stillede spørgsmål
Hvordan afgør jeg, om min undertekstfil har et byte order mark?
Åbn den i en editor, der viser filens tegnkodning, og en UTF-8-fil med mærke er som regel mærket UTF-8 med BOM eller UTF-8 BOM i stedet for ren UTF-8. Ellers se på de første byte i en hex-viser: en fil, der begynder med EF BB BF, bærer et, og en der begynder med tekstblokkens første tegn, gør ikke. Blokken af symboler i begyndelsen af den første linje er det samme set af et program, der læste mærket som tre almindelige tegn.
Hvorfor bliver mærket på en UTF-16-undertekstfil efter fjernelsen?
Fordi en UTF-16-fil har brug for ét. UTF-16 gemmer hvert tegn som to byte, og de to byteordener ser ens ud udefra, så mærket er det, der fortæller en læser, hvilken orden den er i — en UTF-16-fil uden mærke kan ikke læses tilbage, hverken af denne side eller af noget andet. Siden her beholder det af den grund. Skal du have en fil helt uden mærke, skal du ændre dens tegnkodning til UTF-8 eller Windows-1252 i stedet, hvor mærket er valgfrit.
Beskadiger denne side en SRT-fil, der aldrig har haft et mærke?
Nej. Outputtet i det tilfælde er inputtet, byte for byte, og intet rapporteres for det. At køre siden på en fil, hvis tilstand du er usikker på, er sikker af samme grund: er der intet mærke at fjerne, er der intet at skrive, og er der et, er ændringen den mindst mulige. En kørsel, der ikke fandt noget at gøre, er ikke en kørsel, der gjorde noget.
Kan en undertekstfil have mere end ét byte order mark?
Ja, og det sker, hver gang et værktøj tilføjer et mærke uden først at kontrollere, om der er et — det andet mærke laver en fil, der ser helt normal ud i en editor, mens den afviger fra en normal fil i sine åbningsbyte. Denne side fjerner dem alle i stedet for ét, så en dobbelt markeret fil ryddes i én kørsel, og at køre siden igen ændrer intet yderligere.
Ændrer fjernelsen af et mærke tegnkodningen i min undertekstfil?
Ikke i den betydning, folk normalt mener. Filens tekst er stadig de samme tegn, og resten af den er stadig kodet på samme måde; det, der ændres, er, at en læser ikke længere har filens åbningsbyte til at fortælle tegnkodningen. En UTF-8-fil uden mærke er almindelig UTF-8, hvilket er det, de fleste værktøjer alligevel antager. At ændre selve tegnkodningen er en anden side, linket herfra.
Kommer mærket tilbage, når jeg downloader undertekstfilen?
Nej. Downloadet er det punkt, hvor filen skrives, og en kørsel af denne side skriver den uden mærke, så det, du får, er det, de to ruder beskriver. Den tegnkodning, en fil skrives i, bevares fra hvordan den blev læst, med én undtagelse: en fil, der ankommer som UTF-16, skrives tilbage som UTF-16 og beholder sit mærke, fordi det mærke er strukturelt og ikke pynt.