Regeleinden van ondertitels
Of plak ondertiteltekst
Opties
Elke regel in het bestand eindigt op één onzichtbaar teken (LF) of twee (CRLF). Spelers, editors en ondertitelhulpmiddelen lezen beide, dus dit is bijna nooit de reden dat een ondertitelbestand zich raar gedraagt — de twee redenen waarom het wel zo is, zijn een build-pipeline of een strikte parser die het andere weigert, en een diff-hulpmiddel dat elke regel als gewijzigd toont omdat de regeleinden verschillen. LF is hier standaard de keuze omdat Unix, macOS en het web het gebruiken, en omdat een bestand dat het al heeft met rust gelaten wordt. Kies je CRLF, dan worden beide bestaande soorten omgezet, zodat een gemengd bestand er consistent uitkomt.
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 zet alle regeleinden in een ondertitelbestand om naar één stijl: LF of CRLF. Een bestand dat vandaag een mengeling is — sommige regels met een enkele LF, andere met CRLF, en hier en daar een losse CR van een oudere editor — komt eruit met één consistent regeleinde, zodat de volgende tool niet halverwege het bestand anders gaat doen dan aan het begin.
Beide stijlen zijn geldige tekst; het verschil is een erfenis van hoe Windows en Unix een nieuwe regel markeren. CRLF is gevolgd door en is wat Windows-programma’s verwachten; LF is alleen en is wat macOS, Linux en vrijwel alles op het web gebruikt. Een ondertitelbestand met de verkeerde stijl werkt meestal wel, maar kan in een editor als één lange regel verschijnen of bij een strikte controle worden afgekeurd, en gemengde stijlen zijn de versie waar niemand op rekent.
De pagina normaliseert eerst: elke losse CR wordt een regeleinde en elke CRLF wordt herkend als één regeleinde in plaats van twee. Daarna wordt elk regeleinde in de gekozen stijl geschreven. Dat gebeurt overal — tussen blokken, binnen een blok, in de lege regel tussen twee ondertitels en na de laatste regel van het bestand. Een bestand zonder regeleinde aan het einde krijgt er een, omdat een ontbrekend laatste regeleinde precies het soort verschil is dat een leverancier als fout telt.
Deze pagina verandert alleen de bytes die een regel beëindigen. De tijdcodes, de bloknummers en de tekst zelf zijn byte voor byte die van het origineel, en de codering blijft ongewijzigd: een UTF-8-bestand blijft UTF-8 en houdt zijn BOM als het er een had. Alle twaalf formaten worden geaccepteerd, en de omzetting gebeurt in je browser zonder upload.
Voorbeelden
Gemengde regeleinden naar LF
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.
Het bestand had een CRLF na de eerste tijdcode, LF daarna en een losse CR aan het einde. Alle drie worden één LF, dus de hexweergave toont na elke regel precies één `0A` en nergens een `0D`. De leesbare tekst is identiek, en dat is het punt: een diff in versiebeheer zou eerst elke regel als gewijzigd hebben getoond en nu geen enkele.
LF naar CRLF voor een Windows-programma
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.
Elke `0A` wordt `0D 0A`, ook de lege regel tussen de twee ondertitels, en ook de regel na de laatste tijdcode. De tekst blijft gelijk. Dit is de richting die je nodig hebt wanneer een oudere Windows-editor of een omroeptool het bestand anders als één lange regel toont; het is dezelfde tekst met een andere markering voor het regeleinde.
Een bestand met een losse CR
Invoer
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Uitvoer
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
De losse CR midden in het bestand wordt eerst als regeleinde herkend en daarna in de gekozen stijl geschreven, dus de twee stukken tekst komen op twee regels te staan in plaats van aan elkaar geplakt. Zonder die normalisatiestap zou een CR alleen zijn blijven staan en zou het bestand nog steeds gemengd zijn. De laatste regel krijgt ook een regeleinde, wat de ontbrekende afsluiting repareert.
Veelgestelde vragen
Wat is het verschil tussen LF en CRLF in een ondertitelbestand?
Beide markeren het einde van een regel, met andere bytes. LF is één byte, 0A, en is wat macOS, Linux en de meeste webgereedschappen gebruiken. CRLF is twee bytes, 0D 0A, en is wat Windows van oudsher gebruikt. De leesbare tekst is identiek; het verschil wordt zichtbaar wanneer een programma de ene stijl verwacht en de andere krijgt, bijvoorbeeld doordat het hele bestand als één regel verschijnt.
Wat gebeurt er met een bestand dat gemengde regeleinden heeft?
De pagina normaliseert eerst alle varianten naar één regeleinde en schrijft daarna de gekozen stijl, dus het resultaat is overal hetzelfde. Een losse CR wordt als regeleinde herkend in plaats van als tekstteken, en een CRLF wordt als één regeleinde geteld in plaats van als twee. Gemengde bestanden zijn de gevaarlijkste, omdat de helft van de tools ze goed leest en de andere helft niet, afhankelijk van waar in het bestand ze stoppen.
Worden de lege regels tussen ondertitels ook omgezet?
Ja. Elke regelafsluiting in het bestand wordt omgezet, inclusief de lege regel tussen twee blokken en de regel na de laatste tijdcode. Een lege regel is in SRT en WebVTT een structureel onderdeel van het formaat, dus wanneer die in een andere stijl blijft staan, is het bestand nog steeds gemengd en kan een strikte lezer de blokken niet meer scheiden.
Verandert het omzetten van regeleinden de tijdcodes of de tekst?
Nee. Alleen de bytes die een regel beëindigen worden vervangen; de tijdcodes, de bloknummers en de tekst zelf komen byte voor byte terug. De codering blijft ook ongewijzigd, dus een UTF-8-bestand blijft UTF-8 en een bestand met een BOM houdt zijn BOM. Wil je ook de codering aanpassen, dan doet de pagina die de tekencodering omzet dat in een aparte stap met een eigen melding.
Krijgt een bestand zonder regeleinde aan het einde er een?
Ja. Een ontbrekend laatste regeleinde wordt toegevoegd in de gekozen stijl, omdat het precies het soort verschil is dat een leverancier als fout telt en dat in een diff als een gewijzigde laatste regel verschijnt. De laatste regel tekst zelf wordt niet aangeraakt; er komt alleen een afsluiting achter. Wil je dat niet, dan is het enige alternatief het bestand met de hand aanpassen, en dat is zelden wat iemand wil.
Wordt mijn ondertitelbestand geüpload wanneer ik de regeleinden omzet?
Nee. De bytes worden in je browser gelezen en geschreven, dus er gaat geen inhoud naar een server. Dat geldt ook voor een groot bestand of een batch van honderden afleveringen. De pagina werkt met een verbroken verbinding zodra ze geladen is, en de enige netwerkactiviteit is het ophalen van de pagina zelf.