Rätta undertextens teckenkodning
Eller klistra in undertexttext
Inställningar
Den här ändrar hur filen läses, inte vad som skrivs. Normalt räknas kodningen fram från de första byten: en BOM om det finns en, UTF-8 om filen är giltig UTF-8 och Windows-1252 annars. Det blir rätt för västeuropeiska filer och fel för allt annat, så en japansk, kinesisk, koreansk eller kyrillisk fil kommer in som en skärm full av accentuerat nonsens. Namnge kodningen här och gissningen hoppas över. Identifiera automatiskt är standard och gör ingenting alls, vilket är varför det är säkert att lämna det. Observera att resultatet skrivs tillbaka som UTF-8: webbläsare kan bara producera en handfull kodningar, och ingen av dem i den här listan finns bland dem. Det är poängen med sidan – texten kommer ut korrekt och i en form som alla verktyg kan läsa.
Vilken bildfrekvens tiderna räknas i. På formatsidorna är det här vad MicroDVD behöver, eftersom formatet lagrar tider som bildnummer. På bildfrekvenssidorna är det den frekvens som filens tider byggdes för – den version som undertexterna gjordes för – och sidans andra fält tar frekvensen för den video du ska använda dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 och 60 är de vanligaste. Blir det fel förskjuts hela tidslinjen, och på bildfrekvenssidorna förskjuts den med ett förhållande i stället för med ett fast belopp.
Rätta en undertextfil som läses med fel teckenkodning. När en fil öppnas som UTF-8 men egentligen är skriven i Shift-JIS, GBK, Big5 eller Windows-1251 blir texten skräp — ofta syns det som frågetecken eller märkliga tecken där bokstäverna borde stå. Sidan låter dig tala om vilken kodning filen egentligen har, och skriver sedan ut den som UTF-8.
Läsningen sker före tolkningen av formatet. Det betyder att sidan först bestämmer vilka tecken filen innehåller och därefter läser textblocken, så en fil som såg trasig ut kan bli fullt läsbar innan den skrivs ut. Standardvalet är automatisk igenkänning, som fungerar för de flesta filer men inte för alla.
Några kodningar kan webbläsaren läsa men inte skriva. Sidan skriver därför alltid resultatet som UTF-8, oavsett vilken kodning du valde att läsa med. Det är det format som alla moderna program klarar och som undviker nästa omgång teckenproblem.
Ett undantag är ISO-8859-1, som överrider den automatiska igenkänningen. Väljer du den läses filen som ISO-8859-1 även om den skulle kunna tolkas som UTF-8, vilket är användbart när en fil har dubbelkodats. Filen lämnar aldrig datorn.
Exempel
Automatisk igenkänning på en fil som redan läses rätt
Indata
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.
Filen är redan korrekt kodad och läses utan problem, så resultatet blir oförändrat. Sidan skriver ut den som UTF-8, vilket för en ren ASCII-fil ger samma byte.
Samma fil läst som Shift-JIS
Indata
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Resultat
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Här talar läsvalet om att filen är skriven i Shift-JIS, och den japanska texten blir läsbar innan den skrivs ut som UTF-8. Utan valet hade byten tolkats som UTF-8 och kunnat bli skräp. Det är det här steget som skiljer sidan från en vanlig omkodning.
En västerländsk fil som automatiken läser som UTF-8
Indata
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
Filen innehåller redan den typiska följden för dubbelkodning, Café Ã la carte, och automatiken läser den som UTF-8. Resultatet blir samma text, eftersom sidan inte kan veta vilken text som var avsedd. Välj ISO-8859-1 i läsvalet om filen egentligen är kodad så.
Vanliga frågor
Vad gör sidan som en vanlig omkodning inte gör?
Den väljer teckenkodning innan filen tolkas som undertext. En vanlig omkodning läser filen med den kodning den redan har och skriver om den; här kan du tala om att filen egentligen är skriven i en annan kodning, så att texten blir läsbar först och sedan skrivs ut som UTF-8. Det är skillnaden mellan att byta etikett och att rätta läsningen.
Vilka teckenkodningar kan jag läsa med?
Bland andra Shift-JIS, GBK, Big5, EUC-KR, Windows-1251 och ISO-8859-1, förutom automatisk igenkänning. Listan täcker de vanligaste fallen där en fil från en annan region öppnas med fel kodning. Välj den kodning filen skapades med, inte den du vill att resultatet ska ha — resultatet skrivs alltid som UTF-8.
Varför skrivs resultatet alltid som UTF-8?
Därför att webbläsaren kan läsa flera äldre kodningar men inte skriva alla. Att skriva ut i samma kodning som indata skulle dessutom kunna återinföra problemet. UTF-8 klarar alla tecken, läses av alla moderna program och är det format som undertextverktyg förväntar sig i dag.
Vad gör ISO-8859-1 speciellt?
Det överrider den automatiska igenkänningen. Väljer du ISO-8859-1 läses filen så, även om den skulle kunna tolkas som UTF-8. Det är användbart när en fil har dubbelkodats och automatiken annars väljer UTF-8, men det kan också göra en korrekt UTF-8-fil oläsbar, så välj det bara när du vet att filen är kodad så.
Kan sidan rätta en fil som redan har tappat tecken?
Nej. Om tecknen redan har skrivits som frågetecken eller ersatts av andra tecken finns informationen inte kvar i filen, och ingen kodning kan återställa den. Sidan rättar läsningen av de byte som finns; den kan inte hitta på tecken som aldrig sparades.
Rörs tider och textblockens ordning?
Nej. Sidan läser om filens tecken och skriver ut texten som UTF-8, men formatets struktur, textblockens tider, ordning och numrering är desamma. Bara byte och tecken ändras; en fil som redan läses korrekt kommer tillbaka med samma innehåll.