Konverter tegnkoding i undertekster
Eller lim inn underteksttekst
Innstillinger
Dette endrer bytene, ikke undertekstene. Hvert tegn i filen skrives i kodingen du velger, så en spiller eller et skript som krever én bestemt koding, får en fil den kan lese. UTF-8 er den alt moderne forventer, og den dette nettstedet skriver overalt ellers. UTF-8 med BOM er de samme bytene med det tre byte store merket foran. UTF-16 LE er det Windows-programmer kaller Unicode, og er omtrent dobbelt så stor. Windows-1252 er den eldre vesteuropeiske kodingen, én byte per tegn, og det er den du må være forsiktig med: den har ikke plass til kinesisk, japansk, koreansk, kyrillisk, gresk eller emoji, så hvert tegn den ikke kan skrive, kommer ut som et spørsmålstegn og telles i rapporten ovenfor. Ingenting annet ved filen endres.
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.
En fils tegnkoding er regelen som gjør teksten om til byte, og det er den ene egenskapen ved en undertekstfil som ikke kan ses ved å se på den. Notisblokk, en nettleser, en kringkastingsserver og et fjernsyn må alle få vite det eller gjette, og når de gjetter forskjellig, kommer teksten fram som symboler som ikke hører til noe språk. Denne siden skriver filen ut i en tegnkoding du navngir, så lesesiden ikke har noe å gjette på.
Standardvalget er å beholde det filen kom i, som er det du vil ha mesteparten av tiden: en operasjon som å forskyve en undertekst i tid, har ingenting med å skrive om kodingen å gjøre, og en fil som var UTF-16LE da den kom inn, er fortsatt UTF-16LE når den går ut. Endre denne innstillingen bare når noe foran deg navngir en koding — en leveransespesifikasjon, et verktøy som avviser en fil, en avspiller som viser feil tegn — eller når du standardiserer en mappe med filer som kom fra forskjellige steder.
De fire valgene på panelet er de som dukker opp. UTF-8 er det nettet og de fleste moderne verktøy bruker, og det hver konverteringsside på dette nettstedet skriver som standard. UTF-8 med merke er de samme bytene med tre ekstra foran, for Windows-programmene som ser på de første bytene for å avgjøre. UTF-16LE er det Windows-undertekstverktøy kaller Unicode, og det lagrer hvert tegn som to byte, så filen blir omtrent dobbelt så stor. Windows-1252 er den eldre vesteuropeiske kodingen, fortsatt skrevet av mange europeiske kringkastingsverktøy, og den kan holde aksentene i vesteuropeiske språk og ingenting annet.
Det siste punktet er et tap, og det er grunnen til at denne siden rapporterer det før du bekrefter. Lagrer du japanske, kinesiske, kyrilliske eller greske undertekster som Windows-1252, skrives tegnene som ikke har noen byte i den kodingen, som spørsmålstegn — filen er ikke ødelagt, de riktige tegnene er borte. Rapporten over arbeidsområdet teller dem og sier hvor mange, og tallet kommer fra den samme kodetabellen som koderen skriver med, så tallet du leser, er antallet spørsmålstegn du vil få. Er tallet ikke null, velg et annet mål.
De to rutene på denne siden kan se identiske ut, og det er forventet og ikke en feil: en koding er en egenskap ved bytene, og rutene holder tegnene. Endringen skjer i det øyeblikket filen skrives, som er når du laster den ned. Raden for hver fil sier hvilken koding den ble lest som, og legger til en andre etikett som navngir kodingen den vil bli skrevet som når de to er forskjellige. Ingenting lastes opp, og arbeidet gjøres i nettleseren din.
Denne siden er også den ene i tekstfamilien som ikke rører selve dokumentet: de andre operasjonene endrer blokkene og skriver dem ut igjen, mens denne skriver om bytene og returnerer det ferdige resultatet uten å bygge et nytt undertekstdokument. Det er derfor den kan gjøre noe de andre ikke kan — endre en egenskap ved filen som ingen blokk inneholder.
Eksempler
En engelsk undertekstfil skrevet som UTF-8
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.
Standardvalget, og kodingen hver andre side på dette nettstedet skriver. Utdataene er lik inndataene fordi UTF-8 er det filen allerede var. Det dette tilfellet fester, er det negative: å velge en koding normaliserer ingenting annet ved filen, så en blokk mister ikke linjesluttene, får ikke et merke og endrer ikke timekoden fordi du besøkte denne siden.
Den samme filen skrevet som UTF-16LE
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.
Windows-undertekstprogrammer kaller dette Unicode, og det er kodingen som gjør den største synlige forskjellen på filen: hvert tegn blir to byte, et merke går foran, og resultatet er omtrent dobbelt så stort. Ingenting av det er synlig i disse rutene, fordi de holder tegn — filens størrelse i filbehandleren og kodingen i editoren er der forskjellen vises.
Japanske undertekster skrevet som Windows-1252
Inndata
1
00:00:01,000 --> 00:00:02,000
こんにちは
Resultat
1
00:00:01,000 --> 00:00:02,000
こんにちは
Fem kana og en koding uten plass til noen av dem, så tapsrapporten for denne kjøringen teller fem tegn som blir spørsmålstegn. Rutene viser fortsatt kanaene, fordi erstatningen skjer når filen skrives og ikke når den leses. Den delingen er med vilje: du får se hva filen sier, og i rapporten hva du ville gi opp ved å skrive den slik.
Ofte stilte spørsmål
Hva er forskjellen mellom tegnkodingen og formatet til en undertekstfil?
Formatet er hvordan filen organiserer blokknumre, timekoder og tekst — SRT, WebVTT, ASS og så videre — og det er noe du kan lese. Tegnkodingen er hvordan tegnene gjøres om til byte, og den er usynlig: den samme SRT-filen kan lagres som UTF-8, UTF-16 eller Windows-1252 og se identisk ut i hver editor. Denne siden endrer den andre og lar den første stå; konverteringssidene endrer den første.
Hva skjer med tegn som målkodingen ikke kan representere?
De skrives som spørsmålstegn, og siden forteller deg hvor mange før du laster ned. Windows-1252 dekker vesteuropeiske bokstaver og har ingen byte for japansk, kinesisk, koreansk, kyrillisk, gresk eller emoji, så de tegnene kan ikke overleve den i noen form — det finnes ingen feil og ingen erstatning som beholder betydningen. Tallet i tapsrapporten er antallet spørsmålstegn i filen du ville fått, regnet ut fra den samme tabellen som skriveren bruker.
Hvorfor ser de to rutene like ut når jeg konverterer tegnkodingen i en undertekstfil?
Fordi rutene holder tegn, og valget handler om byte. Tekst er tekst; om hvert tegn tar én byte, to byte eller tre, avgjøres når filen skrives, ved nedlasting. Raden i køen navngir kodingen hver fil ble lest som og legger til en andre etikett når kodingen den skal skrives som, er forskjellig, og editoren din vil oppgi kodingen til filen du lagret.
Hvilken koding bør jeg velge for en undertekstfil jeg leverer?
UTF-8 med mindre noe i spesifikasjonen sier noe annet, og spesifikasjonen sier vanligvis det. Windows-1252 er vanlig i europeiske kringkastingsleveranser og er trygt bare for vesteuropeisk tekst; UTF-16LE er det et Windows-verktøy kan kreve. Var filen allerede i en passende koding, beholder standardvalget den, som er det tryggeste svaret av alle når ingenting har gått galt.
Gjør valget av UTF-16 undertekstfilen min dobbelt så stor?
Ja, omtrent. Hvert tegn lagres som to byte, så en engelsk undertekstfil på 20 kB blir omtrent 40 kB, og et generelt kompresjonstrinn etterpå fjerner mye av den forskjellen. Merket foran legger til to byte. Størrelsen er prisen for egenskapen som gjorde UTF-16 vanlig på Windows: hvert tegn er like bredt, som eldre programvare syntes var enklere.
Hvorfor finnes det ikke noe UTF-16 big endian-alternativ i kodingslisten?
Fordi ingen velger det, og filer som allerede er i det, håndteres likevel. En fil som kommer som UTF-16 big endian, skrives tilbake som UTF-16 big endian under standardinnstillingen, siden å beholde inndataenes koding er det siden gjør når du ikke navngir noen. Listen holder de fire målene folk faktisk ber om; skriveren under dekker big endian, så det å beholde en fil som den var, aldri stille endrer den.