Ret tegnkodning i undertekster
Eller indsæt underteksttekst
Indstillinger
Denne ændrer, hvordan filen læses, ikke hvad der skrives. Normalt findes tegnkodningen ud fra de første bytes: et byteordensmærke, hvis der er et, UTF-8, hvis filen er gyldig UTF-8, og Windows-1252 ellers. Det rammer vesteuropæiske filer rigtigt og alt andet forkert, så en japansk, kinesisk, koreansk eller kyrillisk fil ankommer som en skærm fuld af accentueret volapyk. Angiv tegnkodningen her, og gætteriet springes over. Registrér automatisk er standard og gør intet overhovedet, hvilket er grunden til, at det er sikkert at lade det være. Bemærk, at resultatet skrives tilbage som UTF-8: browsere kan kun producere en håndfuld tegnkodninger, og ingen af dem på denne liste er blandt dem. Det er pointen med siden – teksten kommer korrekt ud og i en form, alle værktøjer kan læse.
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.
Nogle undertekstfiler ankommer som en skærm fuld af symboler, der ikke tilhører noget sprog. Filen er ikke beskadiget, og teksten er ikke væk: programmet, der læser den, anvendte den forkerte regel på bytene, og de tegn, der kom ud, er, hvad de byte betyder under en anden regel. Denne side lader dig sige, hvilken regel der skal bruges, og den anvender den, før noget andet sker med filen.
Grunden til, at det skal være dig, er, at bytene som regel ikke siger det. Et program, der åbner en undertekstfil, gætter: et mærke i begyndelsen afgør det, gyldig UTF-8 afgør det, og ellers falder det tilbage på noget — oftest den lokale kodebog hos den, der kører værktøjet, snarere end hos den, der skrev filen. Japanske, koreanske og kinesiske undertekstfiler er de tilfælde, hvor gættet oftest går galt, fordi de tegnkodninger var standard på de maskiner, der producerede dem, og deres byte ikke er gyldig UTF-8. Enhver, der ved, hvilket program der skrev filen, ved mere end gætteren, og denne side er, hvor den viden skal hen.
Automatisk er standard og betyder, at gættet kører præcis, som det altid har gjort, så at åbne denne side på en fil, der allerede læses korrekt, ikke ændrer noget. Vælg en bestemt tegnkodning, og filen læses sådan i stedet, før underteksten parses — derfor har denne side ikke et separat »anvend«-trin i sædvanlig forstand, og derfor kan en fil, der læses korrekt, komme ud af den med samme tekstblokke, tidsstempler og linjeskift og et helt andet sæt tegn. Det, du vælger, er læsningen, ikke en redigering.
To ting ved resultatet er værd at vide på forhånd, og siden rapporterer begge. Den første er, at et forkert valg ser ud som et forkert valg: symbolerne skifter til andre symboler i stedet for til tekst, og intet beskadiges ved at prøve. Den anden er en rigtig begrænsning i browseren: de tegnkodninger her, som en browser kan læse, kan den ikke alle skrive. En fil, der er repareret som Shift-JIS, GBK, Big5 eller EUC-KR, skrives derfor ud som UTF-8, som læses korrekt overalt og er det, moderne værktøjer forventer — men det er ikke den tegnkodning, du navngav, så hvis et system længere fremme insisterer på den oprindelige, skal du konvertere filen med et desktopværktøj, efter du har repareret den her.
Én post på listen fortjener sin egen bemærkning. ISO-8859-1 og Automatisk rammer samme kodetabel i en browser, fordi standarden siger, at den etiket betyder den vesteuropæiske. Den er stadig værd at have, fordi den gør noget, Automatisk ikke kan: den tilsidesætter gættet. En vesteuropæisk fil, hvis byte tilfældigvis danner en gyldig UTF-8-sekvens, læses automatisk som UTF-8, og de tegn, du ser, er så ikke dem, der er i filen; at navngive ISO-8859-1 tvinger den vesteuropæiske læsning. Alle tolv undertekstformater accepteres, og intet uploades — filen læses og skrives i din browser.
Eksempler
Automatisk registrering på en fil, der allerede læses korrekt
Input
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.
Standardindstillingen og den eneste, der ikke kræver noget: med Automatisk valgt navngives ingen tegnkodning, så filen læses præcis, som den blev, før denne side fandtes. Det gør det sikkert at åbne den på en fil, du er usikker på — var der intet galt, sker der intet — og det er den indstilling, du falder tilbage på, når et bestemt valg gjorde det værre.
Samme fil læst som Shift-JIS
Input
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Resultat
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Samme fil læst på to måder. Det, ruden rummer, når bytene er læst som Shift-JIS, er det japanske, de hele tiden sagde; læst som vesteuropæisk tekst er de samme byte en linje af usammenhængende accented bogstaver, og det er den tilstand, der sender folk på jagt efter denne side. Begge ruder i dette eksempel viser den læsbare version, fordi genlæsningen sker, før underteksten parses — der er intet trin på siden, hvor de forkerte tegn er på skærmen og de rigtige ikke er.
En vesteuropæisk fil, som automatisk registrering læser som UTF-8
Input
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 svære tilfælde og det eneste, hvor Automatisk og en navngivet tegnkodning er uenige i en browser. Filens byte danner tilfældigvis en gyldig UTF-8-sekvens, så gættet er UTF-8, og de tegn, der gives videre, er ikke dem, der er i filen. At navngive ISO-8859-1 tvinger den vesteuropæiske læsning i stedet. Det er samme kodetabel i begge tilfælde, og det er den del, der er let at tage fejl af ud fra ældre dokumentation: det, valget gør, er at tilsidesætte gættet.
Ofte stillede spørgsmål
Hvorfor viser min undertekstfil mærkelige tegn i stedet for den rigtige tekst?
Fordi bytene blev læst under den forkerte regel. Filen rummer japansk, koreansk eller kyrillisk tekst gemt i den tegnkodning, programmet der skrev den, brugte, og programmet der læser den, antog noget andet — meget ofte maskinens lokale kodebog snarere end filens. Intet er beskadiget: de samme byte under den rigtige regel giver den rigtige tekst, hvilket er det, at navngive en tegnkodning på denne side gør.
Hvordan finder jeg ud af, hvilken tegnkodning en undertekstfil egentlig er i?
Som regel ud fra hvad der producerede den. En japansk fil fra et japansk Windows-værktøj er mest sandsynligt Shift-JIS, en kinesisk fra fastlandet er GBK og fra Taiwan Big5, koreansk er EUC-KR, og kyrillisk er det meste af tiden Windows-1251. Ellers prøv dem: det forkerte valg giver symboler, og det rigtige giver tekst, så en fil kan identificeres på få sekunder uden at vide noget om den.
Hvad sker der, hvis jeg vælger den forkerte tegnkodning til min SRT-fil?
Tegnene skifter til et andet sæt forkerte tegn, og intet andet sker — den oprindelige fil på disken er urørt, og intet uploades eller gemmes noget sted. At prøve igen er gratis. Det ene resultat, du skal holde øje med, er en fil, der læses korrekt, men viser en mistænkeligt lang linje symboler øverst, hvilket betyder, at den også bærer et mærke, som den valgte tegnkodning læste som tegn.
Hvorfor skrives min reparerede fil som UTF-8, når jeg valgte Shift-JIS?
Fordi browseren kan læse den tegnkodning, men ikke skrive den. En fil læst som Shift-JIS, GBK, Big5 eller EUC-KR skrives tilbage som UTF-8, som rummer hvert tegn, den indeholder, og er det, næsten al nuværende software forventer. Undertekstteksten er præcis det, du ser i ruden; kun beholderen ændrede sig. Kræver et system længere fremme den oprindelige tegnkodning, skal du konvertere den reparerede fil med et desktopværktøj.
Ændrer en reparation af tegnkodningen teksten i mine undertekster?
Nej. Bytene i din fil ændres ikke, og intet tegn tilføjes, fjernes eller erstattes; det, der ændres, er reglen, der bruges til at gøre bytene til tekst, og alt efter det trin arbejder med den korrekte tekst. Tekstbloknumre, tidsstempler og linjeskift er filens egne, præcis som de er på enhver anden handlingsside her.
Er automatisk registrering af tegnkodning god nok, eller skal jeg altid vælge?
Automatisk er rigtigt for langt de fleste filer, og det er standarden, fordi en fil, der læses korrekt, ikke bør kræve, at du siger noget. Vælg tegnkodningen, når teksten tydeligt er forkert, når du ved hvad der producerede filen, eller når en batch kom fra én kilde og skal læses på én måde. Et tilfælde, hvor det ikke hjælper: en fil i en tegnkodning, som browseren slet ikke har en dekoder til, og som bliver ved med at være forkert, uanset hvilken indstilling du vælger.