Видео и субтитры · Инструментарий субтитров
Почему é становится é в субтитрах: кодировки текста и как их расшифровывают браузеры
· Как это работает
субтитры кодировка символов обработка браузера
Моджибаке в субтитрах почти всегда — это несоответствие кодировки. В этом посте объясняется, как байты становятся символами, почему UTF-8 и устаревшие кодовые страницы Windows не совпадают, а также как инструмент на основе браузера декодирует файл, не отправляя его куда-либо.
Акценты — мусор, но время идеальное — как проявляются проблемы с кодированием
Дело в том, что все, кроме персонажей, в порядке. Тайминги точны, порядок реплик правильный, файл загружается, только буквы с диакритическими знаками неправильные. Эта комбинация исключает структурную ошибку, поскольку синтаксический анализатор, который не смог прочитать файл, не смог бы выдать правильные тайминги. То, что пошло не так, произошло до синтаксического анализа, когда последовательность байтов была превращена в последовательность символов.
Это также объясняет, почему ошибка часто возникает в середине рабочего процесса, а не в его источнике. Файл, который выглядел правильно в одном редакторе, может выглядеть неправильно в другом, и при этом его ничего не модифицировало. Ничто не изменило его; вторая программа сделала другое предположение о том, что означают эти байты.
Байты и символы — почему одни и те же байты могут читаться как «é» или «Ã©» в зависимости от декодера
Файл на диске состоит из байтов. Символы существуют только тогда, когда что-то применяет кодировку, которая представляет собой таблицу, сопоставляющую последовательности байтов с символами. UTF-8 представляет собой букву латинского алфавита с акцентом, например e-acute, в виде двух байтов. Windows-1252 представляет одну и ту же букву в виде одного байта и придает двум байтам UTF-8 совершенно разные значения: первый — это заглавная буква A с тильдой, а второй — знак авторского права.
Так что знакомая искаженная пара – это не коррупция. Это точное чтение без потерь правильных байтов не в той таблице. Каждый байт выжил; изменилась только интерпретация. Вот почему повреждение обычно обратимо и поэтому стоит определить, в каком направлении произошло несоответствие, а не редактировать видимые символы вручную.
UTF-8, Windows-1252 и другие — файлы субтитров в кодировках действительно появляются в
Файлы субтитров доступны в небольшом количестве кодировок. UTF-8 — это современное значение по умолчанию, единственное, которое разрешено WebVTT. Windows-1252 часто встречается в файлах, созданных с помощью старых западноевропейских инструментов, а его близкий родственник ISO-8859-1 охватывает большую часть той же области. Файлы из источников Центральной Европы, кириллицы или греческого языка появляются на соответствующих кодовых страницах Windows, а материалы из Восточной Азии добавляют еще несколько.
Ни одна из этих кодировок не записывает свою идентичность внутри файла. Файл SRT не содержит объявления кодировки, использованной для его записи, что является корнем всей проблемы: читатель должен решить, и нет ничего авторитетного для чтения.
Знак порядка байтов — полезная подсказка для некоторых игроков и видимый сбой для других.
Метка порядка байтов является единственным частичным исключением. Это особый символ в самом начале файла, который, если он присутствует, сигнализирует о кодировке. Некоторым игрокам это помогает, а у других отображается в виде случайного символа перед первым индексом субтитров, поэтому файлы, содержащие его, могут дать сбой только в одной программе и работать везде.
Анализатор удаляет его, прежде чем делать что-либо еще, потому что оставшаяся на месте метка прикрепляется к первому индексному номеру и стоит первую реплику. Обнаружение формата также допускает это, поэтому файл WebVTT, который начинается с метки перед его заголовком, по-прежнему распознается как WebVTT, а не обрабатывается как SRT.
Как браузер декодирует файл локально — TextDecoder API, и почему обнаружение — это предположение, когда кодировка не объявлена
Когда инструмент загружает файл, он вызывает текстовый метод File API, и этот метод указывается для декодирования как UTF-8. Параметр кодирования и согласование отсутствуют. Файл, который действительно является UTF-8, читается правильно; файл Windows-1252, содержащий однобайтовую букву с диакритическим знаком, представляет байт, который не может начинать действительную последовательность UTF-8, и декодер заменяет заменяющий символ, а не угадывает.
Это стоит знать, потому что это меняет симптом. Чтение файла UTF-8 с устаревшей таблицей приводит к знакомому двухсимвольному искажению. При чтении устаревшего файла как UTF-8 вместо него создаются символы замены — черные ромбы или пустые поля. Декодирование как нечто иное, чем UTF-8, требует явного указания кодировки через декодер браузера API, а присвоение имени — это самая сложная часть: без объявления в файле любой автоматический выбор является выводом из шаблонов байтов, что является предположением, которое обычно верно, а иногда и уверенно неверно.
Рабочий пример: спасение файла Windows-1252 — определение исходной кодировки и повторное сохранение его как UTF-8 перед преобразованием.
Чтобы спасти устаревший файл, выполните преобразование до начала работы субтитров, а не после. Откройте его в редакторе, который позволяет указать кодировку с обеих сторон, попросите его повторно открыть файл как Windows-1252 и убедитесь, что символы с диакритическими знаками отображаются правильно. Если они это сделают, догадка была верной. Затем сохраните файл явно как UTF-8.
Проверяйте строку, которую вы можете предсказать, а не файл в целом. Выберите реплику, содержащую акцент, который, как вы знаете, должен быть там, и проверьте ее в преобразованном выводе. Если сделать это в первую очередь, инструмент субтитров получит файл, байты которого уже соответствуют предполагаемой кодировке, и на этапе преобразования не останется ошибок.
Чего это не касается — файлы, поврежденные в результате двух раундов неправильного преобразования, где исходные байты уже потеряны.
Файл, который подвергся двум неправильным преобразованиям, представляет собой другую проблему. Если файл был неправильно прочитан, а затем сохранен в этом неправильно прочитанном состоянии, неправильные символы были записаны как настоящие символы, и исходные байты больше не существовали в нем. На этом этапе интерпретировать заново нечего, потому что теперь файл действительно содержит искаженный текст.
Эти случаи иногда можно исправить путем изменения точной последовательности ошибочных кодировок, но только тогда, когда каждый шаг известен и ни один шаг не потерял информацию. Байт, который стал замещающим символом, исчезает навсегда: замена представляет собой один символ, заменяющий байт, который декодер не может использовать, и он не записывает, что это был за байт. Надежное решение — вернуться к исходному файлу.
Вывод: стандартизируйте UTF-8 перед преобразованием — как Subtitle Toolkit работает с вашим файлом в браузере и почему вывод WebVTT по определению имеет значение UTF-8.
Прежде чем что-либо конвертировать, стандартизируйте UTF-8. Сам файл не содержит информации о своей кодировке, поэтому каждая программа, открывающая его, делает предположения, и способ предотвратить несовпадение предположений — сделать их все правильными. WebVTT устраняет двусмысленность по определению, поскольку формат требует UTF-8, что является одной из практических причин конвертировать SRT в WebVTT для доставки через Интернет.
Преобразование выполняется для файла на вкладке браузера. Проверяйте результат на строке, акценты которой вы можете предсказать, а не сканируйте все, что выглядит неправильно, потому что файл с несколькими словами с акцентами в девятистах репликах легко подписаться, не проверив ту часть, которая может дать сбой.