Napraw kodowanie napisów
Albo wklej tekst napisów
Opcje
To pole zmienia sposób czytania pliku, a nie to, co jest zapisywane. Zwykle kodowanie jest odgadywane z pierwszych bajtów: znacznik kolejności bajtów, jeśli jest, UTF-8, jeśli plik jest poprawnym UTF-8, a w przeciwnym razie Windows-1252. To działa dla plików z Europy Zachodniej, a dla wszystkich innych nie, więc plik japoński, chiński, koreański czy w cyrylicy przychodzi jako ekran ozdobnych bzdur. Nazwij tutaj kodowanie, a zgadywanie zostanie pominięte. Wykryj automatycznie jest domyślne i nie robi zupełnie nic, dlatego bezpiecznie je zostawić. Zwróć uwagę, że wynik jest zapisywany z powrotem jako UTF-8: przeglądarki potrafią wytworzyć tylko garść kodowań i żadne z tej listy wśród nich nie jest. Na tym polega ta strona — tekst wychodzi poprawny i w postaci, którą przeczyta każde narzędzie.
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ść.
Niektóre pliki napisów przychodzą jako ekran symboli nienależących do żadnego języka. Plik nie jest uszkodzony, a tekst nie zniknął: program czytający plik zastosował niewłaściwą regułę do bajtów, a znaki, które wyszły, są tym, co te bajty znaczą pod inną regułą. Ta strona pozwala ci powiedzieć, której reguły użyć, i stosuje ją, zanim cokolwiek innego stanie się z plikiem.
Powód, dla którego musi to być twoja decyzja, jest taki, że bajty zwykle nic nie mówią. Program otwierający plik napisów zgaduje: znacznik na początku rozstrzyga, poprawne UTF-8 rozstrzyga, a w przeciwnym razie spada na coś – zwykle na lokalną stronę kodową tego, kto uruchamia narzędzie, a nie tego, kto napisał plik. Japońskie, koreańskie i chińskie pliki napisów to przypadki, w których zgadywanie myli się najczęściej, bo te kodowania były domyślne na maszynach, które je tworzyły, a ich bajty nie są poprawnym UTF-8. Każdy, kto wie, który program napisał plik, wie więcej niż zgadujący, i ta strona jest miejscem, gdzie ta wiedza trafia.
Automatyczne jest domyślne i znaczy, że zgadywanie działa dokładnie tak, jak zawsze, więc otwarcie tej strony na pliku, który już czyta się poprawnie, niczego nie zmienia. Wybierz konkretne kodowanie, a plik zostanie odczytany właśnie tak, zanim napisy zostaną sparsowane – dlatego ta strona nie ma osobnego kroku „zastosuj” w zwykłym sensie i dlatego plik, który czyta się poprawnie, może z niej wyjść z tymi samymi blokami, timecode’ami i końcami wierszy oraz zupełnie innym zestawem znaków. Wybierasz odczyt, nie edycję.
Dwie rzeczy o wyniku warto wiedzieć z góry i strona raportuje obie. Pierwsza: zły wybór wygląda jak zły wybór – symbole zmieniają się w inne symbole, a nie w tekst, więc próbowanie niczego nie psuje. Druga to prawdziwe ograniczenie przeglądarki: kodowania, które przeglądarka potrafi czytać, nie wszystkie potrafi zapisać. Plik naprawiony jako Shift-JIS, GBK, Big5 albo EUC-KR jest więc zapisywany jako UTF-8, który czyta się poprawnie wszędzie i którego oczekują nowoczesne narzędzia – ale to nie jest kodowanie, które nazwałeś, więc jeśli system dalej wymaga oryginalnego, przekonwertuj plik narzędziem desktopowym po naprawieniu go tutaj.
Jeden wpis na liście zasługuje na osobne zdanie. ISO-8859-1 i automatyczne trafiają w przeglądarce do tej samej tablicy kodowej, bo standard mówi, że ta etykieta znaczy zachodnioeuropejską. Warto go mieć, bo robi coś, czego automatyczne nie potrafi: unieważnia zgadywanie. Zachodnioeuropejski plik, którego bajty przypadkiem tworzą poprawne UTF-8, jest automatycznie czytany jako UTF-8, a znaki, które widzisz, nie są wtedy tymi z pliku; nazwanie ISO-8859-1 wymusza odczyt zachodni. Wszystkie dwanaście formatów jest przyjmowanych, a nic nie jest wysyłane – plik jest czytany i zapisywany w twojej przeglądarce.
Przykłady
Automatyczne wykrywanie na pliku, który czyta się poprawnie
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.
Ustawienie domyślne i jedyne, które o nic nie prosi: przy automatycznym żadne kodowanie nie jest nazwane, więc plik jest czytany dokładnie tak, jak przed istnieniem tej strony. To czyni ją bezpieczną do otwarcia na pliku, co do którego nie masz pewności – jeśli nic nie było źle, nic się nie dzieje – i jest ustawieniem, do którego wracasz, gdy konkretny wybór pogorszył sprawę.
Ten sam plik odczytany jako Shift-JIS
Wejście
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Wynik
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Ten sam plik czytany na dwa sposoby. To, co okienko trzyma po odczytaniu bajtów jako Shift-JIS, to japoński, który one przez cały czas mówiły; czytane jako tekst zachodni te same bajty są wierszem niepowiązanych liter z akcentami i to jest stan, który wysyła ludzi na poszukiwanie tej strony. Oba okienka tego przykładu pokazują czytelną wersję, bo ponowny odczyt dzieje się przed sparsowaniem napisów – nie ma etapu tej strony, na którym złe znaki są na ekranie, a dobre nie.
Zachodni plik, który automatyczne wykrywanie czyta jako UTF-8
Wejście
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Wynik
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Trudny przypadek i jedyny, w którym automatyczne i nazwane kodowanie różnią się w przeglądarce. Bajty pliku przypadkiem tworzą poprawne UTF-8, więc zgadywanie daje UTF-8, a przekazane znaki nie są tymi z pliku. Nazwanie ISO-8859-1 wymusza zamiast tego odczyt zachodnioeuropejski. W obu przypadkach to ta sama tablica kodowa i to jest część łatwa do pomylenia na podstawie starszej dokumentacji: wybór unieważnia zgadywanie.
Częste pytania
Dlaczego mój plik napisów pokazuje dziwne znaki zamiast właściwego tekstu?
Bo bajty zostały odczytane pod niewłaściwą regułą. Plik trzyma japoński, koreański albo cyrylicki tekst zapisany w kodowaniu, którego użył program piszący, a program czytający założył coś innego – bardzo często lokalną stronę kodową maszyny, a nie pliku. Nic nie jest uszkodzone: te same bajty pod właściwą regułą dają właściwy tekst, i to robi nazwanie kodowania na tej stronie.
Jak się dowiedzieć, w jakim kodowaniu naprawdę jest plik napisów?
Zwykle po tym, co go utworzyło. Japoński plik z japońskiego narzędzia Windows to najprawdopodobniej Shift-JIS, chiński z kontynentu to GBK, a z Tajwanu Big5, koreański to EUC-KR, a cyrylica przez większość czasu Windows-1251. Jeśli to nie pomoże, wypróbuj je: zły wybór daje symbole, a dobry tekst, więc plik da się zidentyfikować w kilka sekund, nie wiedząc o nim nic.
Co się stanie, jeśli wybiorę złe kodowanie dla mojego pliku napisów?
Znaki zmienią się w inny zestaw złych znaków i nic więcej się nie dzieje – oryginalny plik na dysku jest nietknięty, a nic nie jest wysyłane ani nigdzie zapisywane. Kolejna próba jest darmowa. Jedynym wynikiem, na który warto uważać, jest plik, który czyta się poprawnie, ale pokazuje podejrzanie długi wiersz symboli u góry; to znaczy, że niesie też znacznik, który wybrane kodowanie odczytało jako znaki.
Dlaczego naprawiony plik napisów jest zapisany jako UTF-8, choć wybrałem Shift-JIS?
Bo przeglądarka potrafi to kodowanie czytać, ale nie zapisać. Plik odczytany jako Shift-JIS, GBK, Big5 albo EUC-KR jest zapisywany jako UTF-8, który mieści każdy zawarty w nim znak i którego oczekuje niemal całe obecne oprogramowanie. Tekst napisów jest dokładnie tym, co widzisz w okienku; zmieniło się tylko opakowanie. Jeśli system dalej wymaga oryginalnego kodowania, przekonwertuj naprawiony plik narzędziem desktopowym.
Czy naprawianie kodowania zmienia tekst moich napisów?
Nie. Bajty pliku nie są zmieniane i żaden znak nie jest dodawany, usuwany ani zastępowany; zmienia się reguła używana do zamiany tych bajtów na tekst, a wszystko po tym kroku pracuje już na poprawnym tekście. Numery bloków, timecode’y i końce wierszy są własnością pliku, dokładnie tak jak na każdej innej stronie operacji w tym serwisie.
Czy automatyczne wykrywanie kodowania wystarcza, czy zawsze powinienem je ustawiać?
Automatyczne jest właściwe dla zdecydowanej większości plików i jest domyślne, bo plik, który czyta się poprawnie, nie powinien wymagać, żebyś cokolwiek mówił. Ustaw kodowanie, gdy tekst jest widocznie zły, gdy wiesz, co utworzyło plik, albo gdy partia przyszła z jednego źródła i powinna być czytana jednym sposobem. Jeden przypadek, w którym to nie pomoże: plik w kodowaniu, dla którego przeglądarka nie ma w ogóle dekodera – zostanie zły przy każdym wyborze.