Konvertera undertextens teckenkodning
Eller klistra in undertexttext
Inställningar
Det här ändrar byten, inte undertexterna. Varje tecken i filen skrivs i den kodning du väljer, så en spelare eller ett skript som kräver en viss kodning får en fil den kan läsa. UTF-8 är den som allt modernt förväntar sig och den som den här webbplatsen skriver överallt annars. UTF-8 med BOM är samma byte med det tre byte långa märket framför. UTF-16 LE är vad Windowsprogram kallar Unicode och är ungefär dubbelt så stor. Windows-1252 är den äldre västeuropeiska kodningen, en byte per tecken, och det är den man ska vara försiktig med: den har inte plats för kinesiska, japanska, koreanska, kyrilliska, grekiska eller emoji, så varje tecken den inte kan skriva kommer ut som ett frågetecken och räknas i rapporten ovan. Inget annat i filen ändras.
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.
Skriv om undertextfilen i en annan teckenkodning. Du väljer mellan UTF-8, UTF-8 med BOM, UTF-16LE och Windows-1252, och sidan skriver ut filen på nytt med den kodningen i stället för att bara byta en etikett.
Standardvalet behåller den kodning filen kom in med, inklusive UTF-16BE som inte finns bland de fyra målen. Det gör sidan användbar även när du bara vill kontrollera att en fil är korrekt kodad: väljer du samma kodning som filen redan har blir resultatet identiskt.
Tecken som inte finns i målkodningen kan inte skrivas. Windows-1252 saknar till exempel japanska tecken, och då skrivs ett frågetecken i stället och antalet räknas i resultatet. Sidan väljer inte tyst en annan kodning; den skriver vad den kunde och redovisar vad som inte gick.
Förhandsvisningen ser ofta identisk ut, eftersom texten är densamma. Ändringen sker i byte när filen laddas ner, och det är först då filens storlek och teckenkodning faktiskt skiljer sig. Allt körs i webbläsaren.
Exempel
En engelsk undertextfil skriven som UTF-8
Indata
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.
Filen innehåller bara tecken som ryms i alla fyra kodningarna, så resultatet ser likadant ut hur du än väljer. Skillnaden ligger i byten, inte i texten: en UTF-16LE-fil blir ungefär dubbelt så stor eftersom varje tecken tar två byte.
Samma fil skriven som UTF-16LE
Indata
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.
Texten är oförändrad, men den nedladdade filen är kodad som UTF-16LE och därför ungefär dubbelt så stor. Förhandsvisningen kan inte visa skillnaden, eftersom den läser tillbaka texten och visar tecken, inte byte.
Japanska undertexter skrivna som Windows-1252
Indata
1
00:00:01,000 --> 00:00:02,000
こんにちは
Resultat
1
00:00:01,000 --> 00:00:02,000
こんにちは
Windows-1252 kan inte representera japanska tecken, så de skrivs som frågetecken och antalet räknas i resultatet. Sidan väljer inte en annan kodning i smyg; den redovisar att tecknen inte fick plats. Välj UTF-8 eller UTF-16LE för den här filen.
Vanliga frågor
Vilka teckenkodningar kan jag välja?
UTF-8, UTF-8 med BOM, UTF-16LE och Windows-1252. Standardvalet behåller filens ursprungliga kodning, även om den är UTF-16BE, så du kan köra sidan utan att byta något. De fyra målen täcker de vanligaste kraven från redigerare och leveranssystem.
Vad händer med tecken som inte finns i målkodningen?
De skrivs som ett frågetecken, och antalet räknas i resultatet. Windows-1252 kan till exempel inte representera japanska eller kinesiska tecken, så en sådan fil förlorar sin text om du väljer den kodningen. Sidan väljer inte tyst en annan kodning; den skriver det den kan och redovisar resten.
Varför ser förhandsvisningen likadan ut efter bytet?
Eftersom förhandsvisningen visar text, inte byte. Texten är densamma; det är den nedladdade filens kodning och storlek som ändras. En UTF-16LE-fil blir ungefär dubbelt så stor som en UTF-8-fil med samma innehåll, men båda visar samma tecken i webbläsaren.
Skiljer sig UTF-8 med BOM från vanlig UTF-8?
Ja, med tre byte först i filen: EF BB BF. Själva texten kodas likadant, men vissa program kräver markeringen för att känna igen UTF-8, medan andra visar den som ett osynligt tecken. Välj vanlig UTF-8 om inget uttryckligen kräver BOM, och den med BOM om leveransen säger det.
Behåller sidan radbrytningarna?
Ja. Teckenkodningen avgör hur tecken skrivs, inte vilka radslut filen har. En fil med CRLF behåller CRLF och en fil med LF behåller LF, även när kodningen byts. Vill du ändra radsluten finns en egen sida för det, så de två sakerna inte blandas ihop.
Laddas filen upp någonstans?
Nej. Hela omkodningen sker i webbläsaren, och filen lämnar aldrig datorn. Sidan behöver ingen server och gör inga anrop med filens innehåll. Det gäller även de filer som innehåller tecken som inte får plats i målkodningen: de stannar lokalt och redovisas lokalt.