Tekencodering herstellen
Of plak ondertiteltekst
Opties
Deze keuze verandert hoe het bestand wordt gelezen, niet wat er wordt geschreven. Normaal wordt de codering uit de eerste bytes afgeleid: een byte-order mark als die er is, UTF-8 als het bestand geldige UTF-8 is, en anders Windows-1252. Dat klopt voor West-Europese bestanden en klopt voor al het andere niet, dus een Japans, Chinees, Koreaans of Cyrillisch bestand komt aan als een scherm vol geaccentueerde onzin. Noem je de codering hier, dan wordt het gissen overgeslagen. Automatisch herkennen is de standaard en doet helemaal niets, daarom kun je het veilig laten staan. Let op: het resultaat wordt teruggeschreven als UTF-8 — browsers kunnen maar een handvol coderingen produceren, en geen daarvan staat in deze lijst. Dat is juist het punt van deze pagina: de tekst komt er correct uit en in een vorm die elk hulpmiddel kan lezen.
In welke beeldsnelheid de tijden worden geteld. Op de formaatpagina’s is dit wat MicroDVD nodig heeft, want het slaat tijden op als framenummers. Op de beeldsnelheidspagina’s is het de snelheid waartegen het bestand getimed is — de versie waarvoor de ondertitels gemaakt zijn — en het tweede vak op de pagina neemt de snelheid van de video die je gaat gebruiken. 23,976, 24, 25, 29,97, 30, 50, 59,94 en 60 zijn de gebruikelijke. Een verkeerde waarde verschuift de hele tijdlijn, en op de beeldsnelheidspagina’s verschuift ze die met een verhouding in plaats van met een vast bedrag.
Deze pagina herstelt een ondertitelbestand waarvan de bytes met de verkeerde tekencodering zijn gelezen. Wanneer een bestand in Shift-JIS is opgeslagen en als UTF-8 wordt geopend, verandert elke letter in een paar vreemde tekens; wanneer een bestand in UTF-8 is opgeslagen en als Windows-1252 wordt geopend, verschijnen er reeksen als `é` in plaats van accenten. Het probleem zit niet in de tekst maar in de vraag welke codering de bytes gebruiken.
Het verschil met de pagina die de codering omzet, is waar de fout zit. Daar is de tekst correct gelezen en wordt hij in een andere codering opgeslagen. Hier is de tekst verkeerd gelezen en moet eerst de juiste codering worden bepaald voordat er iets kan worden opgeslagen. De pagina leest de bytes daarom opnieuw met de codering die je kiest, en parseert pas daarna — dus de correctie gebeurt voordat de ondertitels worden gelezen, niet erna.
De keuzes zijn Automatisch, Shift-JIS, GBK, Big5, EUC-KR, Windows-1251 en ISO-8859-1. Automatisch is de standaard en laat de detector proberen; de expliciete waarden zijn er voor wanneer je weet waar het bestand vandaan komt of wanneer de detector het mis heeft. Een verkeerde keuze is veilig: er wordt niets vernield, je krijgt een ander resultaat en kunt het opnieuw proberen met een andere waarde.
Eén eigenschap van de browser bepaalt wat eruit komt. De browser kan Shift-JIS, GBK, Big5 en EUC-KR lezen maar niet schrijven, dus een bestand dat je met een van die coderingen repareert, wordt als UTF-8 opgeslagen. Dat is geen beperking om je tegen te houden maar de reden dat de pagina werkt: het repareren en het bewaren zijn twee stappen, en de tweede gaat naar een codering die de browser wel kan schrijven. ISO-8859-1 heeft nog een eigenaardigheid: kies je die, dan overschrijft ze een UTF-8-vermoeden van de detector, wat precies is wat je wilt wanneer je weet dat het bestand zo is opgeslagen. Alle twaalf formaten worden geaccepteerd, en er wordt niets geüpload.
Voorbeelden
Een bestand dat als UTF-8 is gelezen maar Shift-JIS is
Invoer
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.
Uitvoer
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.
De Japanse tekst staat als paar vreemde Latijnse tekens in het venster, omdat de bytes als UTF-8 zijn uitgelegd. Met Shift-JIS als broncodering leest de pagina de bytes opnieuw en komt de Japanse tekst terug. De tijdcode en de structuur waren nooit beschadigd — alleen de uitleg van de bytes was verkeerd — dus zodra de codering klopt, is het bestand weer normaal.
Een bestand dat als Windows-1252 is gelezen maar UTF-8 is
Invoer
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Uitvoer
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
`café` is wat je ziet wanneer UTF-8-bytes als Windows-1252 worden gelezen: de twee bytes van de é zijn als twee aparte tekens uitgelegd. Met UTF-8 als broncodering worden ze weer één teken. Dit is de meest voorkomende vorm van dit probleem, en het is ook de reden dat Automatisch meestal goed uitpakt — UTF-8 is tegenwoordig de overheersende codering.
Een verkeerde gok die veilig is
Invoer
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Uitvoer
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Met de verkeerde codering gekozen komt er nog steeds een bestand uit, met andere tekens dan bedoeld. Er is niets vernield en er is niets naar buiten gegaan: de pagina leest alleen opnieuw en je kunt het nog eens proberen. Dat is het verschil tussen een reparatie en een conversie — bij een conversie kun je tekens verliezen aan een codering die ze niet kan voorstellen, bij een reparatie bepaal je alleen hoe de bestaande bytes worden gelezen.
Veelgestelde vragen
Hoe weet ik welke codering mijn ondertitelbestand werkelijk gebruikt?
Probeer Automatisch eerst; de detector komt voor moderne bestanden meestal goed uit, en voor de meeste bestanden is UTF-8 tegenwoordig de juiste gok. Zie je nog steeds vreemde tekens, probeer dan de codering van de regio waar het bestand vandaan komt: Shift-JIS voor Japan, GBK of Big5 voor Chinees, EUC-KR voor Koreaans, Windows-1251 voor Cyrillisch en ISO-8859-1 voor oudere West-Europese bestanden. Een verkeerde keuze vernielt niets, dus proberen is veilig.
Waarom wordt mijn gerepareerde bestand als UTF-8 opgeslagen?
Omdat de browser wel kan lezen in Shift-JIS, GBK, Big5 en EUC-KR maar niet kan schrijven in die coderingen. De reparatie bestaat uit het opnieuw lezen van de bytes, en het opslaan gaat daarna naar UTF-8, dat elk teken kan voorstellen. Dat is ook de beste uitkomst: het bestand is gerepareerd en staat in de codering die vrijwel elke moderne tool verwacht, dus je hoeft het niet nog een keer om te zetten.
Wat is het verschil tussen een bestand repareren en de codering omzetten?
Bij repareren zijn de bytes met de verkeerde codering gelezen en staat de tekst al als rommel op het scherm; de pagina leest de bytes opnieuw met de juiste codering voordat ze worden geparseerd. Bij omzetten is de tekst correct gelezen en wordt hij in een andere codering opgeslagen, zodat de tekens gelijk blijven en alleen de opslag verandert. Een bestand dat er goed uitziet maar de verkeerde bytes heeft, heeft omzetten nodig; een bestand dat er verkeerd uitziet, heeft repareren nodig.
Wat gebeurt er wanneer ik ISO-8859-1 kies voor een bestand dat UTF-8 lijkt?
Dan wordt het als ISO-8859-1 gelezen, ook als de detector UTF-8 vermoedde. Die keuze is met opzet zo: wanneer je weet dat een bestand in die codering is opgeslagen, moet jouw kennis zwaarder wegen dan een gok. Het gevolg is wel dat je een bestand dat werkelijk UTF-8 was, nu verkeerd leest, dus dit is een keuze voor wanneer je het zeker weet in plaats van een algemene instelling.
Wat gebeurt er wanneer de gekozen codering niet de juiste is?
Je krijgt een bestand met andere tekens dan bedoeld, en verder is er niets gebeurd. Er is niets vernield, er is niets opgeslagen en er is niets geüpload, dus je kunt de pagina opnieuw draaien met een andere codering. Dat is waarom de pagina veilig te gebruiken is zonder dat je vooraf zekerheid hebt: het is een herlezing, geen bewerking, en de invoer blijft op je machine staan.
Wordt mijn ondertitelbestand geüpload wanneer ik de codering herstel?
Nee. De bytes worden in je browser opnieuw gelezen en daar weer geschreven; er gaat geen inhoud naar een server. Dat geldt ook voor een batch van honderden bestanden. De pagina blijft werken met een verbroken verbinding zodra ze geladen is, en de enige netwerkactiviteit is het ophalen van de pagina zelf.