Rett tegnkoding i undertekster
Eller lim inn underteksttekst
Innstillinger
Denne endrer hvordan filen leses, ikke hva som skrives. Normalt regnes kodingen ut fra de første bytene: et byteordensmerke hvis det finnes, UTF-8 hvis filen er gyldig UTF-8, og Windows-1252 ellers. Det blir riktig for vesteuropeiske filer og galt for alt annet, så en japansk, kinesisk, koreansk eller kyrillisk fil kommer inn som en skjerm full av aksenterte vrøvltegn. Oppgi kodingen her, og gjettingen hoppes over. Gjenkjenn automatisk er standardvalget og gjør ingenting i det hele tatt, som er grunnen til at det er trygt å la det stå. Merk at resultatet skrives tilbake som UTF-8: nettlesere kan bare produsere en håndfull kodinger, og ingen av dem i denne listen er blant dem. Det er poenget med siden — teksten kommer ut riktig og i en form alle verktøy kan lese.
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.
Noen undertekstfiler kommer fram som en skjerm full av symboler som ikke hører til noe språk. Filen er ikke skadet og teksten er ikke borte: programmet som leste den, brukte feil regel på bytene, og tegnene som kom ut, er det bytene betyr under en annen regel. Denne siden lar deg si hvilken regel som skal brukes, og den bruker den før noe annet skjer med filen.
Grunnen til at det må være deg, er at bytene vanligvis ikke sier det. Et program som åpner en undertekstfil, gjetter: et merke i starten avgjør det, gyldig UTF-8 avgjør det, og ellers faller det tilbake på noe — vanligvis den lokale kodingen til den som kjører verktøyet og ikke den som skrev filen. Japanske, koreanske og kinesiske undertekstfiler er tilfellene der gjetningen går feil oftest, fordi de kodingene var standarden på maskinene som laget dem, og bytene deres ikke er gyldig UTF-8. Alle som vet hvilket program som skrev filen, vet mer enn gjetteren, og denne siden er der den kunnskapen går inn.
Automatisk er standardvalget og betyr at gjetningen går nøyaktig som den alltid har gjort, så å åpne denne siden på en fil som allerede leses riktig, endrer ingenting. Velg en bestemt koding, og filen leses slik i stedet, før underteksten tolkes — som er hvorfor denne siden ikke har noe eget «bruk»-trinn i vanlig forstand, og hvorfor en fil som leses riktig, kan komme ut av den med de samme blokkene, timekodene og linjesluttene og et helt annet sett tegn. Det du velger, er lesningen, ikke en redigering.
To ting ved utfallet er verdt å vite på forhånd, og siden rapporterer begge. Det første er at et feil valg ser ut som et feil valg: symbolene blir til andre symboler i stedet for til tekst, og ingenting blir skadet av å prøve. Det andre er en reell begrensning i nettleseren: de kodingene her som en nettleser kan lese, kan den ikke alle skrive. En fil reparert som Shift-JIS, GBK, Big5 eller EUC-KR skrives derfor ut som UTF-8, som leses riktig overalt og er det moderne verktøy forventer — men det er ikke kodingen du navnga, så hvis et system lenger ned krever den opprinnelige, må du konvertere filen med et skrivebordsverktøy etter å ha reparert den her.
Én oppføring i listen fortjener et eget ord. ISO-8859-1 og automatisk når samme kodetabell i en nettleser, fordi standarden sier at den etiketten betyr den vesteuropeiske. Den er likevel verdt å ha, fordi den gjør noe automatisk ikke kan: den overstyrer gjetningen. En vesteuropeisk fil hvis byte tilfeldigvis danner en gyldig UTF-8-sekvens, leses som UTF-8 automatisk, og tegnene du ser, er da ikke de som står i filen; å navngi ISO-8859-1 tvinger den vestlige lesningen. Alle tolv undertekstformatene tas imot, og ingenting lastes opp — filen leses og skrives inne i nettleseren din.
Eksempler
Automatisk registrering på en fil som allerede leses riktig
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.
Standardinnstillingen, og den eneste som ikke ber om noe: med automatisk valgt navngis ingen koding, så filen leses nøyaktig som den gjorde før denne siden fantes. Det gjør det trygt å åpne den på en fil du er usikker på — var ingenting galt, skjer ingenting — og det er innstillingen å falle tilbake på når et bestemt valg gjorde ting verre.
Den samme filen lest som Shift-JIS
Inndata
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Resultat
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Den samme filen lest på to måter. Det ruten holder når bytene er lest som Shift-JIS, er den japansken de sa hele tiden; lest som vestlig tekst er de samme bytene en linje med urelaterte aksentbokstaver, og det er tilstanden som sender folk til denne siden. Begge rutene i dette eksempelet viser den lesbare versjonen, fordi omlesningen skjer før underteksten tolkes — det finnes ikke noe trinn på siden der de feile tegnene er på skjermen og de riktige ikke er.
En vestlig fil som automatisk registrering leser som UTF-8
Inndata
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Resultat
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Det vanskelige tilfellet, og det eneste der automatisk og en navngitt koding er uenige i en nettleser. Filens byte danner tilfeldigvis en gyldig UTF-8-sekvens, så gjetningen er UTF-8, og tegnene som gis videre, er ikke de som står i filen. Å navngi ISO-8859-1 tvinger den vesteuropeiske lesningen i stedet. Det er den samme kodetabellen uansett, som er den delen det er lett å ta feil av fra eldre dokumentasjon: det valget gjør, er å overstyre gjetningen.
Ofte stilte spørsmål
Hvorfor viser undertekstfilen min rare tegn i stedet for riktig tekst?
Fordi bytene ble lest etter feil regel. Filen holder japansk, koreansk eller kyrillisk tekst lagret i kodingen programmet som skrev den brukte, og programmet som leser den antok noe annet — svært ofte maskinens lokale koding og ikke filens. Ingenting er skadet: de samme bytene under riktig regel gir riktig tekst, som er det å navngi en koding på denne siden gjør.
Hvordan finner jeg ut hvilken koding en undertekstfil egentlig er i?
Vanligvis ut fra hva som laget den. En japansk fil fra et japansk Windows-verktøy er mest sannsynlig Shift-JIS, en kinesisk fra fastlandet er GBK og fra Taiwan Big5, koreansk er EUC-KR, og kyrillisk er Windows-1251 mesteparten av tiden. Ellers får du prøve: feil valg gir symboler og riktig gir tekst, så en fil kan identifiseres på noen sekunder uten å vite noe om den.
Hva skjer hvis jeg velger feil koding for undertekstfilen?
Tegnene blir til et annet sett feile tegn, og ingenting annet skjer — originalfilen på disken er urørt, og ingenting lastes opp eller lagres noe sted. Det er gratis å prøve igjen. Det ene utfallet å se etter, er en fil som leses riktig men viser en mistenkelig lang linje med symboler øverst, som betyr at den også bærer et merke som den valgte kodingen leste som tegn.
Hvorfor skrives den reparerte undertekstfilen som UTF-8 når jeg valgte Shift-JIS?
Fordi nettleseren kan lese den kodingen men ikke skrive den. En fil lest som Shift-JIS, GBK, Big5 eller EUC-KR skrives ut som UTF-8, som holder hvert tegn den inneholder og er det nesten all nåværende programvare forventer. Undertekstteksten er nøyaktig det du ser i ruten; bare beholderen endret seg. Krever et system lenger ned den opprinnelige kodingen, må du konvertere den reparerte filen med et skrivebordsverktøy.
Endrer reparasjonen av kodingen teksten i undertekstene?
Nei. Bytene i filen din endres ikke, og ingen tegn legges til, fjernes eller erstattes; det som endres, er regelen som brukes for å gjøre bytene om til tekst, og alt etter det trinnet arbeider med riktig tekst. Blokknumre, timekoder og linjeslutter er filens egne, nøyaktig som på hver annen operasjonsside her.
Er automatisk kodingsregistrering god nok, eller bør jeg alltid sette den?
Automatisk er riktig for den store majoriteten av filer, og det er standardvalget fordi en fil som leses riktig, ikke skal trenge at du sier noe. Sett kodingen når teksten er synlig feil, når du vet hva som laget filen, eller når en gruppe kom fra én kilde og bør leses på én måte. Ett tilfelle der det ikke hjelper: en fil i en koding nettleseren ikke har noen dekoder for i det hele tatt, som forblir feil uansett hvilket alternativ du velger.