Виправити кодування субтитрів
Або вставте текст субтитрів
Параметри
Це змінює те, як файл читається, а не те, що записується. Зазвичай кодування визначається за першими байтами: BOM, якщо вона є, UTF-8, якщо файл — валідний UTF-8, і Windows-1252 в іншому разі. Це правильно для західноєвропейських файлів і неправильно для решти, тож японський, китайський, корейський або кириличний файл приходить як екран наголошеної нісенітниці. Назвіть кодування тут — і вгадування пропускається. «Визначати автоматично» — за замовчуванням і не робить нічого, тож його безпечно лишати. Зауважте, що результат записується назад як UTF-8: браузери можуть створювати лише кілька кодувань, і жодного з цього списку серед них немає. У цьому й сенс сторінки — текст виходить правильний і в формі, яку прочитає кожен інструмент.
У якій частоті кадрів пораховано таймінги. На сторінках форматів це те, що потрібно MicroDVD, бо він зберігає час як номери кадрів. На сторінках частоти кадрів це частота, за якою файл синхронізували — версія, для якої робили субтитри, — а друге поле сторінки приймає частоту відео, з яким ви будете їх використовувати. 23,976, 24, 25, 29,97, 30, 50, 59,94 і 60 — найпоширеніші. Помилка зміщує весь таймлайн, а на сторінках частоти кадрів — на відношення, а не на фіксовану величину.
Деякі файли субтитрів приходять як екран символів, що не належать жодній мові. Файл не пошкоджений і текст не зник: програма, що його читала, застосувала до байтів неправильне правило, а символи, які вийшли, — це те, що ці байти означають за іншим правилом. Ця сторінка дозволяє сказати, яке правило використовувати, і застосовує його до того, як з файлом станеться будь-що інше.
Причина, чому це має бути ваш вибір, у тому, що байти зазвичай не кажуть самі. Програма, відкриваючи файл субтитрів, угадує: маркер на початку вирішує, коректний UTF-8 вирішує, а інакше вона падає на щось — зазвичай на локальну кодову сторінку того, хто запускає інструмент, а не того, хто писав файл. Японські, корейські й китайські файли субтитрів — випадки, де вгадування помиляється найчастіше, бо ці кодування були типовими на машинах, що їх створили, а їхні байти не є коректним UTF-8. Той, хто знає, яка програма писала файл, знає більше за вгадувача, і ця сторінка — місце для цього знання.
Автоматичне — типове значення, і воно означає, що вгадування працює точно як завжди, тож відкриття цієї сторінки файлом, який уже читається правильно, нічого не змінює. Виберіть конкретне кодування — і файл прочитають саме так, до розбору субтитрів; ось чому на сторінці немає окремого кроку «застосувати» у звичному сенсі й чому файл, що читається правильно, може вийти з неї з тими самими репліками, таймкодами й закінченнями рядків і зовсім іншим набором символів. Ви вибираєте читання, а не редагування.
Дві речі про результат варто знати заздалегідь, і сторінка повідомляє обидві. Перша: неправильний вибір виглядає як неправильний вибір — символи змінюються на інші символи, а не на текст, і від спроби ніщо не псується. Друга — справжнє обмеження браузера: кодування, які він уміє читати, він не всі вміє писати. Тому файл, виправлений як Shift-JIS, GBK, Big5 або EUC-KR, записується назад як UTF-8, який читається правильно всюди й якого очікують сучасні інструменти, але це не те кодування, яке ви назвали; якщо система далі вимагає оригінального, конвертуйте файл настільним інструментом після виправлення тут.
Один пункт у списку вартий окремого слова. ISO-8859-1 і автоматичне доходять до тієї самої кодової таблиці в браузері, бо стандарт каже, що ця назва означає західноєвропейську. Його все одно варто мати, бо він робить те, чого автоматичне не може: скасовує вгадування. Західноєвропейський файл, чиї байти випадково утворюють коректну послідовність UTF-8, читається автоматично як UTF-8, і символи, які ви бачите, тоді не ті, що у файлі; назва ISO-8859-1 примушує західне читання. Приймаються всі дванадцять форматів, і нічого не завантажується: файл читається й записується у вашому браузері.
Приклади
Автоматичне визначення на файлі, який уже читається правильно
Вхід
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.
Результат
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.
Типове налаштування й єдине, що нічого не просить: коли вибрано автоматичне, кодування не назване, тому файл читається точно як до появи цієї сторінки. Це робить її безпечною для відкриття файлом, у якому ви не впевнені: якщо все було гаразд, нічого не станеться; і це налаштування, до якого варто повернутися, коли конкретний вибір зробив гірше.
Той самий файл, прочитаний як Shift-JIS
Вхід
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Результат
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Той самий файл, прочитаний двома способами. Те, що панель тримає після читання байтів як Shift-JIS, — це японська, яку вони й казали весь час; прочитані як західний текст, ті самі байти є рядком не пов’язаних між собою літер з наголосами, і саме цей стан приводить людей шукати цю сторінку. Обидві панелі прикладу показують читабельну версію, бо перечитування відбувається до розбору субтитрів: немає кроку сторінки, на якому на екрані були б хибні символи, а правильних не було.
Західний файл, який автоматичне визначення читає як UTF-8
Вхід
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Результат
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Складний випадок і єдиний, де автоматичне й назване кодування розходяться в браузері. Байти файлу випадково утворюють коректну послідовність UTF-8, тому вгадування дає UTF-8, і передані далі символи не ті, що у файлі. Назва ISO-8859-1 примушує натомість західноєвропейське читання. Кодова таблиця в обох випадках та сама, і саме це легко зрозуміти хибно зі старішої документації: вибір скасовує вгадування.
Часті запитання
Чому мій файл субтитрів показує дивні символи замість правильного тексту?
Бо байти прочитали за неправильним правилом. Файл містить японський, корейський або кириличний текст, збережений у кодуванні програми, що його писала, а програма, що читає, припустила щось інше — дуже часто локальну кодову сторінку машини, а не файлу. Ніщо не пошкоджено: ті самі байти за правильним правилом дають правильний текст, і саме це робить назва кодування на цій сторінці.
Як дізнатися, у якому кодуванні файл субтитрів насправді?
Зазвичай із того, що його створило. Японський файл із японського інструмента Windows найімовірніше Shift-JIS, китайський із материка — GBK, із Тайваню — Big5, корейський — EUC-KR, а кирилиця здебільшого Windows-1251. Якщо це не допомагає, спробуйте їх: неправильний вибір дає символи, правильний — текст, тож файл можна розпізнати за кілька секунд, нічого про нього не знаючи.
Що буде, якщо я виберу неправильне кодування для файлу субтитрів?
Символи зміняться на інший набір неправильних символів, і більше нічого не станеться: оригінальний файл на диску недоторканий, ніщо не завантажене й ніде не збережене. Спробувати ще раз нічого не коштує. Єдиний результат, за яким варто стежити, — файл, що читається правильно, але показує підозріло довгий рядок символів угорі: це означає, що він несе ще й маркер, який вибране кодування прочитало як символи.
Чому виправлений файл записано як UTF-8, коли я вибрав Shift-JIS?
Бо браузер уміє це кодування читати, але не вміє писати. Файл, прочитаний як Shift-JIS, GBK, Big5 або EUC-KR, записується назад як UTF-8, який вміщає кожен символ, що в ньому є, і якого очікує майже все сучасне програмне забезпечення. Текст субтитрів точно такий, як ви бачите на панелі; змінився лише контейнер. Якщо система далі вимагає оригінального кодування, конвертуйте виправлений файл настільним інструментом.
Чи змінює виправлення кодування текст моїх субтитрів?
Ні. Байти вашого файлу не змінюються, і жоден символ не додається, не зникає й не замінюється; змінюється правило, яким ці байти перетворюють на текст, і все після цього кроку працює з правильним текстом. Номери реплік, таймкоди й закінчення рядків належать файлу, точно як на кожній іншій сторінці операцій тут.
Автоматичного визначення кодування достатньо, чи його завжди треба задавати?
Автоматичне правильне для переважної більшості файлів, і воно типове, бо файл, що читається правильно, не повинен вимагати від вас нічого. Задавайте кодування, коли текст видимо хибний, коли ви знаєте, що створило файл, або коли пакет прийшов з одного джерела й має читатися одним способом. Один випадок, де це не допоможе: файл у кодуванні, для якого в браузера немає декодера взагалі; він лишиться хибним за будь-якого варіанта.