Zmień końce wierszy w napisach
Albo wklej tekst napisów
Opcje
Każdy wiersz w pliku kończy się jednym niewidocznym znakiem (LF) albo dwoma (CRLF). Odtwarzacze, edytory i narzędzia do napisów czytają oba, więc prawie nigdy nie jest to przyczyna złego zachowania pliku z napisami — powody, gdy jednak jest, to potok budowania albo surowy parser odrzucający ten drugi oraz narzędzie do porównywania, które pokazuje każdy wiersz jako zmieniony, bo końce się różnią. LF jest tu domyślne, bo tego używają Unix, macOS i sieć, a plik, który już je ma, zostaje w spokoju. Wybór CRLF zamienia oba rodzaje istniejących końców, więc plik z mieszanką wychodzi spójny.
W jakiej liczbie klatek na sekundę liczone są czasy. Na stronach formatów tego wymaga MicroDVD, bo zapisuje czasy jako numery klatek. Na stronach poświęconych liczbie klatek jest to stawka, według której zgrany był plik — wersja, dla której powstały napisy — a drugie pole na stronie przyjmuje liczbę klatek wideo, z którym napisy będą używane. Najczęstsze wartości to 23,976, 24, 25, 29,97, 30, 50, 59,94 i 60. Pomyłka przesuwa całą oś czasu, a na stronach poświęconych liczbie klatek przesuwa ją o współczynnik, a nie o stałą wartość.
Końcem wiersza jest znak albo para znaków kończąca wiersz, i w zwykłym użyciu są dwa. Systemy uniksowe kończą wiersz jednym znakiem, LF; Windows kończy go dwoma, CR, a potem LF. Oba wyglądają tak samo na ekranie i oba są czytane tak samo przez odtwarzacze napisów – dlatego to jedna z tych różnic, które pozostają niewidzialne, dopóki czemuś dalej na tym nie zależy.
A zależy: kontroli wersji, gdzie każdy wiersz pliku może wyglądać na zmieniony, bo zmieniły się końce; skryptom budowania i potokom, które obcinają ostatni znak wiersza i zostają z zabłąkanym powrotem karetki, gdy oczekiwały nowego wiersza; narzędziom dzielącym plik po LF, którym na końcu ostatniego pola przykleja się powrót karetki; i każdej specyfikacji dostawy, która nazywa jeden z tych dwóch. Plik napisów, który ma być porównywany z innym albo łączony z innym, jest plikiem, którego końce wierszy są częścią interfejsu.
Strona jest celowo jednolita w tym, co produkuje. Plik z mieszanymi końcami – część wierszy CRLF, bo był edytowany w Windows, część LF, bo był edytowany gdzie indziej – wychodzi w całości w stylu, który wybrałeś, bo strona najpierw normalizuje końce do LF, a potem stosuje twój wybór. To nie to samo co zamiana końców już poprawnych i zostawienie reszty: znaczy, że odpowiedź na pytanie „w jakim stylu jest ten plik” przestaje zależeć od tego, który wiersz oglądasz, i tylko taka odpowiedź jest użyteczna dla skryptu.
Samotny powrót karetki, koniec wiersza Maca przed OS X, jest obsługiwany razem z resztą. Nikt go już nie wybiera, ale pliki nadal się z nim trafiają, a plik, którego wiersze kończą się w ten sposób, jest dla każdego narzędzia szukającego tylko LF jednym wierszem. Normalizacja najpierw sprawia, że takie pliki wychodzą poprawnie, zamiast wychodzić jako jeden ogromny blok.
Oba okienka to jedyne miejsce w tej rodzinie, gdzie różnica jest bezpośrednio widoczna: koniec wiersza to prawdziwy znak, a plik z wierszami wyglądającymi na podwójnie odległe w przeglądarce, która ich nie ukrywa, to plik z CRLF. Wszystkie dwanaście formatów jest przyjmowanych, bo koniec wiersza jest właściwością tekstu, a nie formatu napisów – zwykły transkrypt też ma wiersze. Nic nie jest wysyłane, a plik jest czytany, zmieniany i zapisywany w przeglądarce.
Przykłady
Zamiana pliku uniksowego na końce Windows
Wejście
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.
Wynik
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.
Każdy koniec wiersza staje się dwoma znakami, łącznie z pustym wierszem między blokami – ten pusty wiersz też jest końcem wiersza, a konwersja, która by go pominęła, zostawiłaby plik, którego separator bloków nadal jest gołym LF. Oczekiwany tekst wypisuje końce jako pary CR LF, żeby liczbę można było odczytać wprost z niego, a nic innego w pliku się nie przesunęło.
Zamiana pliku Windows z powrotem na końce uniksowe
Wejście
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Wynik
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Kierunek z widoczną konsekwencją. Plik, który zachowuje zabłąkany powrót karetki, pokazuje się w niektórych edytorach jako mający pusty wiersz po każdym wierszu, a w potoku powłoki jako powrót karetki przyklejony do końca ostatniego pola. Obraz, czasy i tekst są w obu plikach identyczne; różnicą jest znak na końcu każdego wiersza i to jest kierunek, który go usuwa.
Plik edytowany na dwóch maszynach, ujednolicony
Wejście
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Wynik
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Ten sam plik dotknięty na dwóch maszynach: część wierszy kończy się CRLF, część LF, a jeden separator bloków jest zapisany każdym sposobem. Wynik jest jednolity i o to chodzi – plik przestaje znaczyć coś innego w zależności od tego, który wiersz czytasz. Naiwne wyszukiwanie i zamiana myli ten przypadek w obu kierunkach: zostawia wiersze LF w jednym kierunku i produkuje podwójny powrót karetki w drugim.
Częste pytania
Jak zobaczyć, jakich końców wierszy używa plik napisów?
W większości edytorów styl końca wiersza jest pokazany w pasku stanu jako LF, CRLF albo mieszanka. W powłoce plik, którego wiersze kończą się CRLF, pokazuje na końcu każdego wiersza powrót karetki, gdy patrzysz na niego narzędziem uwidaczniającym znaki sterujące. Bezpośrednim testem jest zajrzenie w bajty na końcu wiersza: pojedyncze 0A to LF, a para 0D 0A to CRLF.
Co ta strona robi z plikiem napisów, który ma mieszane końce wierszy?
Ujednolica je. Plik jest najpierw normalizowany do LF, a potem zamieniany na styl, który wybrałeś, więc plik, w którym część wierszy kończy się jednym sposobem, a część drugim, wychodzi całkowicie jednolity, a nie częściowo zamieniony. Pliki trafiają w ten stan przez edycję na więcej niż jednej maszynie, a mieszanka jest dokładnie tym, co czyni porównanie z inną kopią pliku nieczytelnym.
Czy końce wierszy zmieniają czasy napisów albo tekst bloków?
Nie. Bloki, ich numery, ich czasy początku i końca oraz słowa w nich są identyczne przed i po; zmienia się jeden albo dwa znaki na końcu każdego wiersza. Odtwarzacz czyta oba pliki tak samo, dlatego jest to konwersja, którą możesz wykonać dla wymogu dostawy bez martwienia się o same napisy.
Czy zamieniać końce wierszy napisów na LF czy na CRLF?
Na LF, chyba że coś przed tobą nazywa CRLF. To na LF oczekują narzędzia uniksowe, większość potoków budowania i specyfikacja WebVTT, a plik jest o bajt krótszy na wiersz. Wybierz CRLF, gdy prosi o to specyfikacja dostawy albo narzędzie działające tylko w Windows, i pamiętaj, że wybór jest na plik, a nie globalny: plik napisów dostarczany osobno może różnić się od reszty projektu.
Dlaczego zamiana na CRLF zmienia też pusty wiersz między napisami?
Bo ten pusty wiersz jest wierszem, a jego koniec jest końcem wiersza jak każdy inny. SRT oddziela bloki pustym wierszem, więc plik zamieniony na CRLF, którego separator bloków został gołym LF, miałby jeden koniec wiersza innego rodzaju w środku jednolitego pliku – a to jest dokładnie ta mieszanka, którą ta strona ma usunąć. To samo dotyczy ostatniego wiersza pliku.
Czy stare powroty karetki Maca też są zamieniane?
Tak. Plik, którego wiersze kończą się gołym powrotem karetki, w stylu Mac OS przed OS X, jest normalizowany razem z resztą, więc wychodzi w stylu, który wybrałeś, zamiast pozostać jednym długim blokiem. Na panelu nie ma opcji CR, bo nikt już tak nie pisze plików, ale pliki, które już tak wyglądają, są czytane i przepisywane poprawnie.