Konverter linjeskift
Eller lim inn underteksttekst
Innstillinger
Hver linje i filen slutter med enten ett usynlig tegn (LF) eller to (CRLF). Spillere, editorer og undertekstverktøy leser begge, så dette er nesten aldri grunnen til at en undertekstfil oppfører seg rart — de to grunnene det er, er en byggeprosess eller en streng leser som avviser den andre, og et diff-verktøy som viser hver eneste linje som endret fordi linjeskiftene er forskjellige. LF er valget her som standard fordi det er det Unix, macOS og nettet bruker, og fordi en fil som allerede har det, blir stående urørt. Velger du CRLF, konverteres begge slags eksisterende linjeskift, så en fil med en blanding kommer ut konsistent.
Hvilken bildefrekvens tidene telles i. På formatsidene er det dette MicroDVD trenger, fordi det lagrer tid som bildenummer. På sidene for bildefrekvens er det frekvensen filen ble tidsstyrt mot — versjonen undertekstene ble laget for — og sidens andre boks tar frekvensen til videoen du skal bruke dem med. 23,976, 24, 25, 29,97, 30, 50, 59,94 og 60 er de vanlige. Tar du feil, forskyves hele tidslinjen, og på bildefrekvenssidene forskyves den med et forhold i stedet for et fast beløp.
Et linjeslutt er tegnet eller teparet som avslutter en linje, og det er to av dem i vanlig bruk. Unix-systemer avslutter en linje med ett tegn, LF; Windows avslutter den med to, CR og deretter LF. Begge ser like ut på skjermen, og begge leses likt av undertekstavspillere, som er grunnen til at dette er en av de forskjellene som forblir usynlig til noe lenger ned i kjeden bryr seg.
Det som bryr seg: versjonskontroll, der hver linje i en fil kan se endret ut fordi sluttene endret seg; byggeskript og pipeliner som stripper det siste tegnet i en linje og sitter igjen med en løs vognretur der de forventet et linjeskift; verktøy som deler en fil på LF og ender med en etterfølgende vognretur klistret til det siste feltet; og enhver leveransespesifikasjon som navngir en av de to. En undertekstfil som skal diffes mot en annen, eller settes sammen med en annen, er en fil der linjesluttene er en del av grensesnittet.
Siden er med vilje ensartet i det den produserer. En fil med blandede slutter — noen linjer CRLF fordi den ble redigert på Windows, noen LF fordi den ble redigert andre steder — kommer ut helt i stilen du valgte, fordi siden først normaliserer linjesluttene til LF og deretter bruker valget ditt. Det er ikke det samme som å konvertere sluttene som allerede er riktige og la resten stå: det betyr at svaret på «hvilken stil er denne filen» slutter å avhenge av hvilken linje du ser på, som er den eneste versjonen av svaret som er nyttig for et skript.
En bar vognretur, linjesluttet på Mac før OS X, håndteres sammen med resten. Ingen velger det lenger, men filer dukker fortsatt opp med det, og en fil hvis linjer slutter slik, er én enkelt linje for hvert verktøy som bare leter etter LF. Å normalisere først betyr at de filene kommer ut riktig i stedet for å komme ut som én enorm blokk.
De to rutene på denne siden er det ene stedet i denne familien der forskjellen er direkte synlig: et linjeslutt er et ekte tegn, og en fil med linjer som ser dobbelt avstandsjusterte ut i en visning som ikke skjuler dem, er en fil med CRLF. Alle tolv formatene tas imot, fordi et linjeslutt er en egenskap ved teksten og ikke ved undertekstformatet — også en ren transkripsjon har linjer. Ingenting lastes opp, og filen leses, endres og skrives i nettleseren din.
Denne siden er som de andre i tekstfamilien den varianten som ikke bygger et nytt undertekstdokument: den skriver om bytene og returnerer det ferdige resultatet, så det er ingen blokkmodell som kan miste noe på veien. Det er også derfor den virker på alle tolv formatene, også de som ikke har noen tidslinje å snakke om.
Eksempler
Konvertering av en Unix-fil til Windows-slutter
Inndata
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 linjeslutt blir to tegn, også den tomme linjen mellom blokkene — den tomme linjen er også et linjeslutt, og en konvertering som hoppet over den, ville latt en fil bli igjen der blokkskillet fortsatt er en bar LF. Forventet tekst skriver ut sluttene som CR LF-par, så antallet kan leses rett av den, og ingenting annet i filen har flyttet seg.
Konvertering av en Windows-fil tilbake til Unix-slutter
Inndata
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 følgen. En fil som beholder en løs vognretur, vises i enkelte editorer som at den har en tom linje etter hver linje, og i en skallpipeline som en vognretur klistret til slutten av det siste feltet. Videoen, tidene og teksten er identiske i begge filene; forskjellen er et tegn i slutten av hver linje, og dette er retningen som fjerner det.
En fil redigert på to maskiner, gjort ensartet
Inndata
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.
Den samme filen berørt på to maskiner: noen linjer slutter med CRLF, noen med LF, og ett blokkskille er skrevet hver sin vei. Utdataene er ensartede, som er poenget — filen betyr ikke lenger noe annet avhengig av hvilken linje du leser. En naiv søk-og-erstatt tar dette tilfellet feil i begge retninger: den lar LF-linjene stå den ene veien og lager en doblet vognretur den andre.
Ofte stilte spørsmål
Hvordan kan jeg se hvilke linjeslutter en undertekstfil bruker?
I de fleste editorer vises linjesluttstilen i statuslinjen, som LF, CRLF eller en blanding. Fra et skall viser en fil som slutter med CRLF, en etterfølgende vognretur på hver linje når du ser på den med et verktøy som gjør kontrolltegn synlige. Den direkte testen er å se på bytene i slutten av en linje: en enkelt 0A er LF, og paret 0D 0A er CRLF.
Hva gjør denne siden med en undertekstfil som har blandede linjeslutter?
Den gjør dem alle like. Filen normaliseres til LF først og konverteres deretter til stilen du valgte, så en fil der noen linjer slutter den ene veien og noen den andre, kommer ut helt ensartet i stedet for delvis konvertert. Filer havner i den tilstanden ved å bli redigert på mer enn én maskin, og blandingen er nettopp det som gjør en diff mot en annen kopi av filen uleselig.
Endrer linjesluttene tidene eller teksten i blokkene?
Nei. Blokkene, numrene deres, start- og sluttidene og ordene i dem er identiske før og etter; det som endres, er det ene eller de to tegnene i slutten av hver linje. En avspiller leser begge filene likt, som er grunnen til at dette er en konvertering du kan gjøre for et leveransekrav uten å bekymre deg for undertekstene selv.
Bør jeg konvertere undertekstens linjeslutter til LF eller CRLF?
LF med mindre noe foran deg navngir CRLF. Det er det Unix-verktøy, de fleste byggpipeliner og WebVTT-spesifikasjonen forventer, og det gjør filen én byte kortere per linje. Velg CRLF når en leveransespesifikasjon eller et Windows-verktøy ber om det, og legg merke til at valget gjelder per fil og ikke globalt: en undertekstfil som leveres alene, kan avvike fra resten av prosjektet.
Hvorfor endrer konvertering til CRLF også den tomme linjen mellom undertekstene?
Fordi den tomme linjen er en linje, og slutten på den er et linjeslutt som alle andre. SRT skiller blokker med en tom linje, så en fil konvertert til CRLF der blokkskillet ble igjen som en bar LF, ville hatt ett linjeslutt av en annen sort midt i en ensartet fil — som er nøyaktig den blandingen denne siden finnes for å fjerne. Det samme gjelder den siste linjen i filen.
Blir gamle Mac-vognreturer også konvertert?
Ja. En fil hvis linjer slutter med en bar vognretur, stilen Mac OS brukte før OS X, normaliseres sammen med alt annet, så den kommer ut i stilen du valgte i stedet for å bli stående som én lang blokk. Det finnes ingen innstilling for CR på panelet fordi ingen skriver filer slik lenger, men filer som allerede er slik, leses og skrives riktig.