Dodaj BOM do napisów
Albo wklej tekst napisów
Opcje
BOM to trzy bajty na samym początku pliku, które mówią, w jakim kodowaniu plik jest zapisany. Jest niewidoczny w każdym edytorze i odtwarzaczu, nie zajmuje miejsca na ekranie, a w napisach nic się nie zmienia, gdy się go doda albo usunie. Zajmują się nim dwa rodzaje narzędzi: programy Windows zapisujące napisy, które dodają go domyślnie, oraz surowe parsery w potokach budowania, które odrzucają plik zaczynający się od niego. Ta strona otwiera pole w stanie, który nazywa jej tytuł, więc możesz je przełączyć, jeśli okaże się, że twój plik jest w drugą stronę. Plik UTF-16 zawsze ma BOM, bo to po nim czytnik wie, który z dwóch porządków bajtów widzi — prośba o usunięcie go tam zostawia go na miejscu.
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ść.
Znacznik kolejności bajtów, BOM, to jeden znak – U+FEFF – stojący przed wszystkim innym w pliku. W UTF-8 to trzy bajty, EF BB BF, i pierwsza rzecz, którą widzi czytnik. W wyniku tej strony nic nie wygląda inaczej: te same bloki, ten sam timecode, te same końce wierszy i znacznik przed pierwszym z nich.
Po co komu znacznik: bo plik mówi nim „jestem w UTF-8”, nie mówiąc tego. Program, który otwiera plik napisów, musi zgadnąć kodowanie, a bardzo wiele z nich – starsze odtwarzacze Windows, narzędzia do autoringu płyt, skrypty czytające pierwszy wiersz – decyduje po pierwszych bajtach, zamiast parsować cały plik. Daj im znacznik, a nazwisko z ogonkiem, cudzysłów typograficzny albo grecka litera wychodzą jako siebie. Zostaw go bez znacznika, a ten sam plik może zostać odczytany w lokalnej stronie kodowej systemu, gdzie te znaki stają się czymś zupełnie innym.
Drugi kierunek jest ten, który ludzie spotykają najpierw: plik ze znacznikiem otwarty przez narzędzie, które go nie oczekuje. Narzędzie czyta trzy bajty jako trzy znaki i pokazuje je na początku pierwszego wiersza – stąd bierze się ten mały blok symboli u góry czyjegoś pliku napisów. Jeśli to właśnie widzisz, to zła strona: znacznik trzeba raczej usunąć niż dodać, a strona, która to robi, jest podlinkowana niżej.
Czego strona nie zrobi: nie przeformatuje pliku po drodze. Nie rusza końców wierszy CRLF, numerów bloków, czasów ani tekstu żadnego bloku i nie decyduje za ciebie o kodowaniu pliku: plik, który nie jest UTF-8, to inny problem i jest na to inna strona. Robi jedną rzecz: dodaje jeden znak na samym początku, a jeśli znak już tam jest, zostawia plik w spokoju, zamiast dodawać drugi – więc dwa uruchomienia dają ten sam plik co jedno.
Znacznik trafia do pliku, który pobierasz. Oba okienka mogą więc być identyczne dla oka – niewidzialny znak dokładnie tak wygląda – a uczciwym sposobem sprawdzenia wyniku jest zajrzenie w pierwsze trzy bajty w przeglądarce heksadecymalnej albo w kodowanie pliku w pasku stanu edytora. Wszystkie dwanaście formatów napisów obsługiwanych przez ten serwis może nieść znacznik, bo znacznik jest właściwością początkowych bajtów pliku i nic nie wie o blokach. Nic nie jest wysyłane: plik jest czytany, zmieniany i zapisywany w twojej przeglądarce.
Przykłady
Plik ASCII z napisów ze znacznikiem z przodu
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.
Oczekiwany tekst zaczyna się od niewidzialnego znaku: U+FEFF, trzy bajty EF BB BF, przed jedynką pierwszego numeru bloku. Oba okienka będą dla ciebie wyglądać tak samo i to nie jest błąd renderowania – różnica między tymi plikami ma trzy bajty długości i żaden z nich nie ma kształtu. Pobierz wynik i otwórz go w edytorze pokazującym kodowanie albo zajrzyj w pierwsze bajty w przeglądarce heksadecymalnej: to pierwsza rzecz, którą zobaczysz.
Plik Windows: znacznik dodany, powroty karetki zachowane
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.
Dwie rzeczy, które pisze windowsowe narzędzie do napisów, to znacznik i końce CRLF – dlatego się je myli, ale to dwie osobne rzeczy i ta strona pisze tylko pierwszą. Każdy powrót karetki w oczekiwanym pliku jest własnością wejścia, a znacznik jest dodany przed nimi. Strona, która przepisałaby też końce wierszy, po cichu przeformatowałaby każdy podany plik i to jest dokładnie ta zmiana, której nikt nie zauważa, dopóki nie zacznie jej zależeć jakiemuś narzędziu dalej.
Plik, który już ma znacznik
Wejście
1
00:00:01,000 --> 00:00:02,000
Already marked.
Wynik
1
00:00:01,000 --> 00:00:02,000
Already marked.
Wejście już ma znacznik, więc wynik jest wejściem co do bajtu – plik zachowuje dokładnie jeden. Naiwna wersja tej strony, która dokleja znacznik bez usunięcia tego, co już jest, daje plik z dwoma, a podwójny znacznik jest niewidzialny w każdym edytorze, będąc jednocześnie innym plikiem dla wszystkiego, co czyta początkowe bajty. Uruchomienie tej strony na pliku już oznaczonym powinno być czymś, co robisz bez myślenia.
Częste pytania
Co właściwie zmienia dodanie znacznika kolejności bajtów do pliku napisów?
Jeden znak na samym początku pliku: U+FEFF, zapisany jako trzy bajty EF BB BF w UTF-8. Żaden blok nie jest dodany, usunięty ani zmieniony, żaden timecode się nie przesuwa, numery bloków i końce wierszy wychodzą takie, jakie weszły, a tekst każdego wiersza jest nietknięty. Jeśli porównasz oba pliki, jedynym różniącym się wierszem jest pierwszy, i różni się trzema bajtami na początku.
Dlaczego oba okienka na tej stronie wyglądają identycznie?
Bo dodawany znak nie ma kształtu. U+FEFF to spacja nierozdzielająca o zerowej szerokości, więc okienko renderujące tekst tak, jak zrobiłby to odtwarzacz, pokazuje to samo przed i po. Zmiana jest prawdziwa i jest w pliku, który pobierasz: różnicą są pierwsze trzy bajty. Szukaj jej we wskaźniku kodowania edytora albo w przeglądarce heksadecymalnej pokazującej EF BB BF na początku, a nie w tekście.
Czy dodawanie BOM można bezpiecznie uruchomić dwa razy na tym samym pliku?
Tak. Strona usuwa każdy znacznik już obecny, zanim zapisze własny, więc plik, który już go ma, wraca niezmieniony, a plik, który go nie ma, dostaje dokładnie jeden. Dwa uruchomienia dają ten sam plik co jedno. Oznacza to też, że plik, który przeszedł przez tę stronę, a potem przez narzędzie dodające drugi znacznik, można naprawić jednym przepuszczeniem, bo przeżyje tylko jeden.
Czy znacznik zostaje, jeśli potem przekonwertuję plik na inny format?
Nie w przypadku stron konwersji tego serwisu, które piszą czysty UTF-8 bez znacznika, więc znacznik dodany tutaj nie przechodzi przez zmianę formatu. Ułóż pracę w tej kolejności: najpierw konwersja, potem znacznik jako ostatni krok przed dostawą. To zresztą sensowniejsza kolejność w ogóle, bo znacznik jest właściwością gotowego pliku, a nie treści napisów.
Czy dodanie znacznika zmienia końce wierszy w pliku napisów?
Nie. Znacznik to jeden znak umieszczony przed pierwszym bajtem pliku i nie ma wpływu na to, co po nim następuje. Plik Windows pełen CRLF zostaje pełen CRLF, plik uniksowy zostaje na LF, a plik z mieszanymi końcami wychodzi z tą samą mieszanką, z jaką przyszedł. Zmiana końców wierszy to inna strona i złym pomysłem jest, żeby jedna strona po cichu robiła jedno i drugie.
Które formaty napisów mogą dostać znacznik kolejności bajtów?
Wszystkie dwanaście obsługiwanych przez ten serwis: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON i CSV. Znacznik dotyczy początkowych bajtów pliku, a nie formatu napisów, więc nie ma tu nic specyficznego dla formatu do zrobienia – nawet zwykły transkrypt tekstowy, który nie ma osi czasu, może go nieść.