Zmień kodowanie napisów
Albo wklej tekst napisów
Opcje
To zmienia bajty, a nie napisy. Każdy znak w pliku jest zapisany w wybranym kodowaniu, więc odtwarzacz albo skrypt, który wymaga jednego kodowania, dostaje plik, który potrafi odczytać. UTF-8 to kodowanie, którego oczekuje wszystko nowoczesne i w którym ta strona zapisuje wszędzie indziej. UTF-8 z BOM to te same bajty z trzybajtowym znacznikiem z przodu. UTF-16 LE to to, co programy Windows nazywają Unicode, i zajmuje około dwa razy więcej miejsca. Windows-1252 to starsze kodowanie Europy Zachodniej, jeden bajt na znak, i to z nim trzeba uważać: nie ma miejsca na chiński, japoński, koreański, cyrylicę, grekę ani emoji, więc każdy znak, którego nie potrafi zapisać, wychodzi jako znak zapytania i jest liczony w raporcie powyżej. Poza tym w pliku nic się nie zmienia.
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ść.
Kodowanie znaków pliku to reguła, która zamienia jego tekst na bajty, i jedyna właściwość pliku napisów, której nie da się zobaczyć, patrząc na niego. Notatnik, przeglądarka, serwer emisyjny i telewizor muszą zostać poinformowane albo zgadnąć, a gdy zgadują różnie, tekst przychodzi jako symbole nienależące do żadnego języka. Ta strona zapisuje plik w kodowaniu, które nazwiesz, żeby strona czytająca nie miała czego zgadywać.
Domyślnie zostaje to, w czym plik przyszedł, i to jest to, czego chcesz w większości przypadków: operacja taka jak przesunięcie napisów w czasie nie ma nic do rzeczy przy przepisywaniu kodowania, a plik, który przyszedł jako UTF-16LE, wychodzi nadal jako UTF-16LE. Zmień to ustawienie tylko wtedy, gdy coś przed tobą nazywa kodowanie – specyfikacja dostawy, narzędzie odrzucające plik, odtwarzacz pokazujący złe znaki – albo gdy ujednolicasz folder plików pochodzących z różnych miejsc.
Cztery wybory na panelu to te, które się pojawiają. UTF-8 jest tym, czego używa sieć i większość nowoczesnych narzędzi, i tym, co domyślnie pisze każda strona konwersji w tym serwisie. UTF-8 ze znacznikiem to te same bajty z trzema dodatkowymi z przodu, dla programów Windows, które decydują po początkowych bajtach. UTF-16LE to to, co windowsowe narzędzia do napisów nazywają Unicode; zapisuje każdy znak jako dwa bajty, więc plik wychodzi mniej więcej dwa razy większy. Windows-1252 to starsze kodowanie zachodnioeuropejskie, nadal pisane przez wiele europejskich narzędzi emisyjnych; mieści akcenty języków zachodnioeuropejskich i nic więcej.
Ten ostatni punkt jest stratą i dlatego strona raportuje ją przed zatwierdzeniem. Zapisanie japońskich, chińskich, cyrylickich albo greckich napisów jako Windows-1252 zamienia znaki, które nie mają bajtu w tym kodowaniu, na znaki zapytania – plik nie jest zepsuty, tylko właściwe znaki zniknęły. Raport nad obszarem roboczym je liczy i mówi ile, a liczba pochodzi z tej samej tablicy kodowej, którą pisze koder, więc liczba, którą czytasz, jest liczbą znaków zapytania, które dostaniesz. Jeśli liczba nie jest zerem, wybierz inny cel.
Oba okienka mogą wyglądać identycznie i to jest oczekiwane, a nie błąd: kodowanie jest właściwością bajtów, a okienka trzymają znaki. Zmiana dzieje się w chwili zapisu pliku, czyli przy pobieraniu. Wiersz każdego pliku mówi, w jakim kodowaniu został odczytany, i dodaje drugą etykietę z kodowaniem zapisu, gdy się różnią. Nic nie jest wysyłane, a praca dzieje się w przeglądarce.
Przykłady
Angielski plik napisów zapisany jako UTF-8
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.
Ustawienie domyślne i kodowanie, w którym pisze każda inna strona tego serwisu. Wynik równa się wejściu, bo UTF-8 to kodowanie, w którym plik już był. Ten przypadek utrwala stronę negatywną: wybór kodowania nie normalizuje niczego innego w pliku, więc blok nie traci końców wierszy, nie zyskuje znacznika ani nie zmienia timecode’u dlatego, że odwiedziłeś tę stronę.
Ten sam plik zapisany jako UTF-16LE
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.
Windowsowe programy do napisów nazywają to Unicode i to kodowanie robi największą widoczną różnicę w pliku: każdy znak staje się dwoma bajtami, z przodu idzie znacznik, a wynik jest mniej więcej dwa razy większy. Nic z tego nie jest widoczne w okienkach, bo trzymają one znaki – różnicę widać w rozmiarze pliku w menedżerze plików i w kodowaniu w edytorze.
Japońskie napisy zapisane jako Windows-1252
Wejście
1
00:00:01,000 --> 00:00:02,000
こんにちは
Wynik
1
00:00:01,000 --> 00:00:02,000
こんにちは
Pięć znaków kany i kodowanie, które nie ma miejsca na żaden z nich, więc raport strat dla tego uruchomienia liczy pięć znaków zamienionych na znaki zapytania. Okienka nadal pokazują kanę, bo podstawienie dzieje się przy zapisie pliku, a nie przy odczycie. Ten podział jest celowy: widzisz, co plik mówi, a w raporcie – czego byś się pozbawił, zapisując go w ten sposób.
Częste pytania
Czym różni się kodowanie pliku napisów od jego formatu?
Format to sposób, w jaki plik organizuje numery bloków, timecode’y i tekst – SRT, WebVTT, ASS i tak dalej – i to coś, co można przeczytać. Kodowanie to sposób, w jaki te znaki zamieniają się na bajty, i jest niewidzialne: ten sam plik SRT może być zapisany jako UTF-8, UTF-16 albo Windows-1252 i wyglądać identycznie w każdym edytorze. Ta strona zmienia drugie i zostawia pierwsze; strony konwersji zmieniają pierwsze.
Co dzieje się ze znakami, których docelowe kodowanie nie potrafi przedstawić?
Są zapisywane jako znaki zapytania, a strona mówi ci, ile ich będzie, przed pobraniem. Windows-1252 obejmuje litery zachodnioeuropejskie i nie ma bajtu na japoński, chiński, koreański, cyrylicę, grekę ani emoji, więc te znaki nie przetrwają w żadnej formie – nie ma błędu ani podstawienia, które zachowa znaczenie. Liczba w raporcie strat to liczba znaków zapytania w pliku, który dostaniesz, policzona z tej samej tablicy, której używa zapis.
Dlaczego oba okienka wyglądają tak samo, gdy zmieniam kodowanie pliku napisów?
Bo okienka trzymają znaki, a wybór dotyczy bajtów. Tekst to tekst; to, czy każdy znak zajmuje jeden bajt, dwa czy trzy, rozstrzyga się przy zapisie pliku, w chwili pobierania. Wiersz w kolejce nazywa kodowanie, w którym każdy plik został odczytany, i dodaje drugą etykietę, gdy kodowanie zapisu się różni, a twój edytor pokaże kodowanie zapisanego pliku.
Jakie kodowanie wybrać dla pliku napisów, który dostarczam?
UTF-8, chyba że specyfikacja mówi inaczej – a zwykle mówi. Windows-1252 jest częste w europejskich dostawach emisyjnych i bezpieczne tylko dla tekstu zachodnioeuropejskiego; UTF-16LE może wymagać narzędzie autoringowe działające tylko w Windows. Jeśli plik był już w odpowiednim kodowaniu, domyślne ustawienie je zachowuje, co jest najbezpieczniejszą odpowiedzią, gdy nic się nie zepsuło.
Czy wybór UTF-16 sprawi, że plik napisów będzie dwa razy większy?
Tak, mniej więcej. Każdy znak jest zapisany jako dwa bajty, więc angielski plik napisów o rozmiarze 20 KB staje się około 40 KB, a ogólna kompresja wykonana potem usuwa znaczną część tej różnicy. Znacznik z przodu dodaje jeszcze dwa bajty. Rozmiar jest ceną za właściwość, która zrobiła UTF-16 popularnym w Windows: każdy znak ma tę samą szerokość, co dawnemu oprogramowaniu było łatwiej obsłużyć.
Dlaczego na liście kodowań nie ma UTF-16 big endian?
Bo nikt go nie wybiera, a pliki, które już w nim są, i tak są obsługiwane. Plik, który przychodzi jako UTF-16 big endian, jest zapisywany z powrotem jako UTF-16 big endian przy ustawieniu domyślnym, bo zachowanie kodowania wejścia to właśnie to, co strona robi, gdy nie nazwiesz żadnego. Lista zawiera cztery cele, o które ludzie naprawdę proszą; zapis pod spodem obsługuje big endian, żeby zachowanie pliku takim, jaki był, nigdy nie zmieniało go po cichu.