Tekencodering van ondertitels
Of plak ondertiteltekst
Opties
Dit verandert de bytes, niet de ondertitels. Elk teken in het bestand wordt in de gekozen codering geschreven, zodat een speler of script dat op één codering staat, een bestand krijgt dat het kan lezen. UTF-8 is wat alles moderne verwacht en wat deze site overal elders schrijft. UTF-8 met een BOM zijn dezelfde bytes met de drietekenige markering ervoor. UTF-16 LE is wat Windows-programma’s Unicode noemen en ongeveer twee keer zo groot. Windows-1252 is de oudere West-Europese codering, één byte per teken, en de codering waar je voorzichtig mee moet zijn: ze heeft geen ruimte voor Chinees, Japans, Koreaans, Cyrillisch, Grieks of emoji, dus elk teken dat ze niet kan schrijven komt er als vraagteken uit en wordt in het rapport hierboven geteld. Verder verandert er niets aan het bestand.
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 slaat je ondertitelbestand opnieuw op in een tekencodering die je kiest. De keuzes zijn UTF-8, UTF-8 met BOM, UTF-16LE en Windows-1252, en de standaard laat de codering van het bestand zoals hij is. Je hoeft dus niet te weten wat een bestand nu is om het te kunnen omzetten; je hoeft alleen te weten wat de ontvanger verwacht.
De pagina werkt op de bytes en niet op de leesbare tekst. Dat is het verschil met de pagina die een verkeerd gelezen bestand herstelt: die probeert eerst te raden met welke codering de bytes zijn geschreven voordat ze worden gelezen, terwijl deze pagina de tekst correct leest en daarna opnieuw opslaat. De twee zien er in de paneelweergave vaak hetzelfde uit, en dat is geen fout — de tekens zijn hetzelfde, alleen de bytes eronder zijn anders.
Het geval om op te letten is Windows-1252. Die codering kan maar een paar honderd tekens voorstellen, dus alles wat er niet in past, wordt een vraagteken en gaat verloren. De run telt hoeveel tekens dat waren en meldt het aantal, zodat je niet met een bestand eindigt waarin de helft van de accenten stilletjes weg is. Voor een leverancier die werkelijk Windows-1252 eist, is dat de prijs; voor alle andere gevallen is UTF-8 de keuze zonder verlies.
Eén detail over de standaard: laat je de codering zoals hij is en was het bestand UTF-16 in groot-endian volgorde, dan blijft het groot-endian. Kies je expliciet UTF-16LE, dan wordt het klein-endian. De standaard bewaart dus wat er is, en een expliciete keuze doet wat er staat. Alle twaalf formaten worden geaccepteerd, niets wordt geüpload, en de omzetting gebeurt volledig in je browser.
Voorbeelden
UTF-8 met BOM naar gewone UTF-8
Invoer
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Uitvoer
1
00:00:01,000 --> 00:00:02,000
The room is dark.
De drie markeringsbytes verdwijnen en de tekst blijft precies zoals hij was. Beide bestanden zien er in een editor identiek uit, en dat is het punt: de tekens zijn hetzelfde, alleen de bytes aan het begin zijn anders. Een leverancier die geen BOM wil, keurt het eerste bestand af en accepteert het tweede, terwijl jij geen letter hebt aangepast.
UTF-8 naar UTF-16LE
Invoer
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Uitvoer
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Elk teken wordt twee bytes in klein-endian volgorde, en de BOM hoort daarbij: UTF-16 heeft haar nodig om te kunnen worden gelezen. In een hexweergave zie je tussen elke letter een nulbyte, wat precies is wat UTF-16LE van Latijnse tekst maakt. De leesbare tekst blijft gelijk, de blokken en tijdcodes ook; alleen de opslag is anders.
Een teken dat Windows-1252 niet kan voorstellen
Invoer
1
00:00:01,000 --> 00:00:02,000
こんにちは
Uitvoer
1
00:00:01,000 --> 00:00:02,000
こんにちは
De Chinese tekens passen niet in Windows-1252, dus ze worden vraagtekens en de run meldt hoeveel tekens verloren zijn gegaan. De tijdcodes en de structuur blijven intact. Dit is het geval waarin de pagina je niet tegenhoudt maar ook niet zwijgt: je krijgt een bestand dat de leverancier kan openen, en een getal dat zegt wat het heeft gekost.
Veelgestelde vragen
Hoe verschilt het omzetten van de tekencodering van het repareren van een verkeerd gelezen bestand?
Omzetten leest de tekst correct en slaat hem opnieuw op in een andere codering, dus de tekens die je ziet blijven de tekens die je ziet. Repareren gaat over een bestand waarvan de bytes met de verkeerde codering zijn gelezen, waardoor de tekst zelf al als rommel op het scherm staat; daar moet eerst worden bepaald welke codering de bytes werkelijk gebruiken. Een bestand dat er goed uitziet, heeft omzetten nodig; een bestand dat er verkeerd uitziet, heeft repareren nodig.
Welke tekencoderingen kan ik voor mijn ondertitels kiezen?
UTF-8, UTF-8 met BOM, UTF-16LE en Windows-1252, plus de standaard die de codering van het invoerbestand laat zoals hij is. UTF-8 is de veilige keuze voor alles wat op het web of in moderne spelers terechtkomt; UTF-8 met BOM is voor programma’s die de markering verwachten; UTF-16LE is voor een enkele oudere toepassing; Windows-1252 alleen wanneer een leverancier het expliciet eist, omdat die codering niet alles kan voorstellen.
Wat gebeurt er met tekens die de gekozen codering niet kan voorstellen?
Ze worden een vraagteken en gaan verloren, en de run meldt hoeveel tekens dat waren. Dat is onvermijdelijk: een codering heeft een vaste lijst tekens en kan niets voorstellen wat er niet in staat. De melding is er zodat je het weet voordat je het bestand verstuurt. Wil je geen verlies, kies dan UTF-8; die kan elk teken voorstellen dat in je ondertitels kan voorkomen.
Waarom ziet de uitvoer er hetzelfde uit als de invoer in het voorbeeld?
Omdat de tekens hetzelfde zijn en alleen de bytes eronder verschillen. Een editor toont de tekst, niet de codering, dus UTF-8 en UTF-16LE met dezelfde inhoud zien er identiek uit. Het verschil wordt zichtbaar in een hexweergave of wanneer een programma het bestand weigert omdat het de verkeerde codering verwacht. Dat de panelen gelijk lijken, betekent dus niet dat er niets is gebeurd.
Wat doet de standaardoptie met een UTF-16-bestand in groot-endian volgorde?
Ze laat het groot-endian. De standaard betekent letterlijk dat de codering van het invoerbestand wordt bewaard, ook de bytevolgorde. Kies je expliciet UTF-16LE, dan wordt het klein-endian, wat voor de meeste bestanden de gebruikelijke volgorde is. Wil je zeker weten wat je krijgt, kies dan een expliciete waarde in plaats van de standaard, want dan staat het vast.
Wordt mijn ondertitelbestand geüpload wanneer ik de codering omzet?
Nee. De bytes worden in je browser gelezen en de nieuwe bytes worden daar geschreven. Er gaat niets naar een server, ook niet bij een groot bestand of een hele batch. Je kunt de pagina met een verbroken verbinding blijven gebruiken zodra ze geladen is, en de enige netwerkactiviteit is het ophalen van de pagina zelf.