Konverter linjeskift i undertekster
Eller indsæt underteksttekst
Indstillinger
Hver linje i filen slutter med enten ét usynligt tegn (LF) eller to (CRLF). Afspillere, editorer og undertekstværktøjer læser begge, så dette er næsten aldrig årsagen til, at en undertekstfil opfører sig forkert – de to grunde, der er, er en byggepipeline eller en streng parser, der afviser den anden, og et diff-værktøj, der viser hver eneste linje som ændret, fordi linjeskiftene er forskellige. LF er valget her som standard, fordi det er det, Unix, macOS og webbet bruger, og fordi en fil, der allerede har det, lades urørt. Vælger du CRLF, konverteres begge slags eksisterende linjeskift, så en fil med en blanding kommer konsistent ud.
Hvilken billedhastighed tiderne tælles i. På formatsiderne er det, hvad MicroDVD har brug for, fordi formatet gemmer tider som billednummer. På siderne om billedhastighed er det den hastighed, filen blev timet efter – den version, underteksterne blev lavet til – og sidens anden boks tager hastigheden for den video, du skal bruge dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 og 60 er de almindelige. Tager man fejl, forskydes hele tidslinjen, og på siderne om billedhastighed forskydes den med et forhold i stedet for et fast beløb.
Et linjeskift er det tegn eller tegnpar, der afslutter en linje, og der er to i almindelig brug. Unix-systemer afslutter en linje med ét tegn, LF; Windows afslutter med to, CR og derefter LF. Begge ser ens ud på skærmen, og begge læses ens af undertekstafspillere, og derfor er det en af de forskelle, der forbliver usynlig, indtil noget længere fremme i kæden går op i den.
Hvad der går op i det: versionskontrol, hvor hver linje i en fil kan se ændret ud, fordi linjeskiftene blev ændret; build-scripts og pipelines, der fjerner det sidste tegn på en linje og står tilbage med et løst carriage return, når de forventede et linjeskift; værktøjer, der opdeler en fil ved LF og ender med et efterfølgende carriage return klæbet til det sidste felt; og enhver leveringsspecifikation, der navngiver en af de to. En undertekstfil, der skal diffes mod en anden eller sammenkædes med en anden, er en fil, hvis linjeskift er en del af dens grænseflade.
Siden er bevidst ensartet i det, den producerer. En fil med blandede linjeskift — nogle linjer CRLF, fordi den blev redigeret på Windows, nogle LF, fordi den blev redigeret alle andre steder — kommer ud helt i den stil, du valgte, fordi siden først normaliserer linjeskift til LF og derefter anvender dit valg. Det er ikke det samme som at konvertere de linjeskift, der allerede er korrekte, og lade resten være: det betyder, at svaret på »hvilken stil er denne fil« holder op med at afhænge af, hvilken linje du ser på, og det er den eneste version af svaret, der er nyttigt for et script.
Et bart carriage return, linjeskiftet fra Mac før OS X, håndteres sammen med resten. Ingen vælger det længere, men filer dukker stadig op med det, og en fil, hvis linjer slutter sådan, er én linje for ethvert værktøj, der kun leder efter LF. At normalisere først betyder, at de filer kommer rigtigt ud i stedet for at komme ud som én kæmpe tekstblok.
De to ruder på denne side er det ene sted i denne familie, hvor forskellen er direkte synlig: et linjeskift er et rigtigt tegn, og en fil med linjer, der ser dobbelt så høje ud i en visning, der ikke skjuler dem, er en fil med CRLF. Alle tolv formater accepteres, fordi et linjeskift er en egenskab ved teksten og ikke ved undertekstformatet — en ren transskription har også linjer. Intet uploades, og filen læses, ændres og skrives i din browser.
Eksempler
Konvertering af en Unix-fil til Windows-linjeskift
Input
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.
Hvert linjeskift bliver to tegn, også den tomme linje mellem tekstblokkene — den tomme linje er også et linjeskift, og en konvertering, der sprang den over, ville efterlade en fil, hvis tekstblokadskiller stadig er et bart LF. Den forventede tekst skriver linjeskiftene som CR LF-par, så antallet kan læses direkte, og intet andet i filen har flyttet sig.
Konvertering af en Windows-fil tilbage til Unix-linjeskift
Input
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.
Retningen med den synlige konsekvens. En fil, der beholder et løst carriage return, vises i nogle editorer som en tom linje efter hver linje og i en shell-pipeline som et carriage return klæbet til det sidste felt. Videoen, tiderne og teksten er identiske i begge filer; forskellen er et tegn i slutningen af hver linje, og det er den retning, der fjerner det.
En fil redigeret på to maskiner, gjort ensartet
Input
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Resultat
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Samme fil rørt på to maskiner: nogle linjer slutter CRLF, nogle LF, og én tekstblokadskiller er skrevet på hver sin måde. Outputtet er ensartet, og det er pointen — filen betyder ikke længere noget forskelligt, alt efter hvilken linje du læser. En naiv søg-og-erstat tager fejl i begge retninger: den lader LF-linjerne være i den ene retning og laver et fordoblet carriage return i den anden.
Ofte stillede spørgsmål
Hvordan kan jeg se, hvilke linjeskift en SRT-fil bruger?
I de fleste editorer vises linjeskiftstilen i statuslinjen som LF, CRLF eller en blanding. Fra en shell viser en fil med CRLF et efterfølgende carriage return på hver linje, når du ser den med et værktøj, der gør kontroltegn synlige. Den direkte prøve er at se på bytene i slutningen af en linje: et enkelt 0A er LF, og parret 0D 0A er CRLF.
Hvad gør siden med en undertekstfil, der har blandede linjeskift?
Den gør dem alle ens. Filen normaliseres først til LF og konverteres derefter til den stil, du valgte, så en fil, hvor nogle linjer slutter på den ene måde og andre på den anden, kommer ud helt ensartet i stedet for delvist konverteret. Filer kommer i den tilstand ved at blive redigeret på mere end én maskine, og blandingen er netop det, der gør en diff mod en anden kopi af filen ulæselig.
Ændrer linjeskift underteksternes tider eller tekstblokteksten?
Nej. Tekstblokkene, deres numre, deres start- og sluttider og ordene i dem er alle identiske før og efter; det, der ændres, er det ene eller to tegn i slutningen af hver linje. En afspiller læser begge filer ens, og derfor er det en konvertering, du kan lave for et leveringskrav uden at bekymre dig om underteksterne selv.
Skal jeg konvertere en VTT-fils linjeskift til LF eller CRLF?
LF, medmindre noget foran dig navngiver CRLF. Det er det, Unix-værktøjer, de fleste build-pipelines og WebVTT-specifikationen forventer, og det gør filen én byte kortere pr. linje. Vælg CRLF, når en leveringsspecifikation eller et Windows-only-værktøj beder om det, og bemærk, at valget er pr. fil og ikke globalt: en undertekstfil, der leveres alene, kan afvige fra resten af projektet.
Hvorfor ændrer konvertering til CRLF også den tomme linje mellem tekstblokke?
Fordi den tomme linje er en linje, og dens afslutning er et linjeskift som alle andre. SRT adskiller tekstblokke med en tom linje, så en fil konverteret til CRLF, hvis tekstblokadskiller blev et bart LF, ville have et linjeskift af en anden slags midt i en ensartet fil — hvilket netop er den blanding, denne side findes for at fjerne. Det samme gælder filens sidste linje.
Bliver gamle Mac-carriage returns også konverteret?
Ja. En fil, hvis linjer slutter med et bart carriage return, stilen fra Mac OS før OS X, normaliseres sammen med alt andet, så den kommer ud i den stil, du valgte, i stedet for at blive ved med at være én lang tekstblok. Der er ingen indstilling for CR på panelet, fordi ingen skriver filer sådan længere, men filer, der allerede er sådan, læses og skrives korrekt.