Додати BOM до субтитрів
Або вставте текст субтитрів
Параметри
BOM — це три байти на самому початку файлу, що вказують, у якому кодуванні він записаний. Вона невидима в кожному редакторі й плеєрі, не займає місця на екрані, і нічого в субтитрах не змінюється, коли її додати чи вилучити. Про неї дбають два різновиди інструментів: програми Windows, що пишуть субтитри, які ставлять її за замовчуванням, і строгі парсери в складальних конвеєрах, які відкидають файл, що починається з неї. Ця сторінка відкриває поле в стані, який називає її заголовок, тож ви можете перемкнути його, якщо ваш файл виявиться навпаки. Файл у UTF-16 завжди несе BOM, бо саме так читач знає, який із двох порядків байтів перед ним — прохання вилучити її там лишає її на місці.
У якій частоті кадрів пораховано таймінги. На сторінках форматів це те, що потрібно MicroDVD, бо він зберігає час як номери кадрів. На сторінках частоти кадрів це частота, за якою файл синхронізували — версія, для якої робили субтитри, — а друге поле сторінки приймає частоту відео, з яким ви будете їх використовувати. 23,976, 24, 25, 29,97, 30, 50, 59,94 і 60 — найпоширеніші. Помилка зміщує весь таймлайн, а на сторінках частоти кадрів — на відношення, а не на фіксовану величину.
Маркер порядку байтів — це один символ, U+FEFF, що стоїть перед усім іншим у файлі. У UTF-8 він займає три байти, EF BB BF, і це перше, що бачить читач. У виході цієї сторінки ніщо не виглядає інакше: ті самі репліки, ті самі таймкоди, ті самі закінчення рядків і маркер перед першою реплікою.
Він потрібен тому, що маркер — це спосіб, яким файл каже «я в UTF-8», не кажучи цього. Програма, що відкриває файл субтитрів, мусить угадати кодування, і багато хто з них — старі плеєри Windows, інструменти авторингу дисків, скрипти, що читають перший рядок, — вирішує, дивлячись на перші байти, а не намагаючись розібрати весь файл. Дайте їм маркер, і ім’я з наголосом, фігурна лапка чи грецька літера вийдуть собою. Приберіть його, і той самий файл можуть прочитати як локальну кодову сторінку системи, де ці символи перетворюються на щось зовсім інше.
Зворотний напрямок — той, із яким люди зазвичай зустрічаються першим: файл із маркером відкриває інструмент, що маркера не чекає. Він читає три байти як три символи й показує їх на початку першого рядка — звідси той невеликий блок символів угорі файлу субтитрів. Якщо ви дивитеся саме на це, вам потрібна інша сторінка: маркер треба прибрати, а не додати, і сторінка, що це робить, посилається нижче.
Чого сторінка не робить — не переформатує файл дорогою. Вона не чіпає закінчень CRLF, номерів реплік, таймкодів чи тексту жодної репліки й не вирішує за вас кодування файлу: файл не в UTF-8 — це інша проблема, і для неї теж є сторінка. Вона додає один символ на самому початку, а якщо символ уже там, лишає файл як є, а не додає другий, тож два прогони дають той самий файл, що й один.
Маркер додається до файлу, який ви завантажуєте. Тому дві панелі на сторінці можуть бути однакові на око — невидимий символ саме так і виглядає, — а чесний спосіб перевірити результат — подивитися на перші три байти в шістнадцятковому редакторі або на кодування файлу в рядку стану вашого редактора. Усі дванадцять форматів субтитрів, з якими працює сайт, можуть нести маркер, бо він властивість початкових байтів файлу й нічого не знає про репліки. Нічого не завантажується: файл читається, змінюється й записується у вашому браузері.
Приклади
ASCII-файл субтитрів із маркером попереду
Вхід
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.
Очікуваний текст починається невидимим символом: U+FEFF, три байти EF BB BF, перед одиницею номера першої репліки. Панелі виглядатимуть для вас однаково, і це не вада рендерингу — різниця між цими файлами завдовжки три байти, і жоден із них не має форми. Завантажте результат і відкрийте його в редакторі, що показує кодування, або подивіться на перші байти в шістнадцятковому редакторі, і ви побачите її одразу.
Файл Windows: маркер додано, повернення каретки збережено
Вхід
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Результат
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Дві речі, які пише інструмент субтитрів Windows, — це маркер і закінчення CRLF, тому їх і плутають, але вони окремі, і ця сторінка пише лише першу. Кожне повернення каретки в очікуваному файлі належить входу, а маркер додано перед ними. Сторінка, що переписала б і закінчення рядків, тихо переформатувала б кожен переданий їй файл — саме та зміна, якої ніхто не помічає, доки вона не почне важити для інструмента далі.
Файл, який уже несе маркер
Вхід
1
00:00:01,000 --> 00:00:02,000
Already marked.
Результат
1
00:00:01,000 --> 00:00:02,000
Already marked.
Вхід уже має маркер, тому вихід — це вхід байт у байт: файл зберігає рівно один. Наївна версія сторінки, яка вставляє маркер, не прибравши наявний, дає файл із двома, а подвоєний маркер невидимий у кожному редакторі, хоч для всього, що читає початкові байти, це вже інший файл. Прогін сторінки файлом, який уже має маркер, має бути тим, що ви можете робити не замислюючись.
Часті запитання
Що насправді змінює додавання маркера порядку байтів до файлу субтитрів?
Один символ на самому початку файлу: U+FEFF, записаний трьома байтами EF BB BF в UTF-8. Жодна репліка не додається, не зникає й не редагується, жоден таймкод не рухається, номери реплік і закінчення рядків виходять такими, якими увійшли, а текст кожного рядка недоторканий. Якщо порівняти два файли, відрізнятиметься лише перший рядок, і відрізнятиметься трьома байтами на початку.
Чому обидві панелі на цій сторінці виглядають однаково?
Бо символ, який додається, не має форми. U+FEFF — це пробіл нульової ширини без розриву, тому панель, що показує текст так, як показав би ваш плеєр, бачить те саме до і після. Зміна справжня й лежить у файлі, який ви завантажуєте: різниця — перші три байти. Покажчик кодування у вашому редакторі або шістнадцятковий редактор із EF BB BF на початку — ось де її шукати, а не в тексті.
Чи безпечно запускати додавання BOM двічі на тому самому файлі?
Так. Сторінка прибирає будь-який наявний маркер перед тим, як записати свій, тому файл, що вже його несе, повертається незмінним, а файл без нього отримує рівно один. Два прогони дають той самий файл, що й один. Це також означає, що файл, який пройшов цю сторінку, а потім інструмент, що додав другий маркер, можна виправити одним прогоном, бо виживає лише один.
Чи збережеться маркер, якщо потім конвертувати файл в інший формат?
Сторінки конвертації цього сайту його не збережуть, бо пишуть звичайний UTF-8 без маркера. Тому впорядкуйте роботу відповідно: спершу конвертуйте, а маркер додавайте останнім кроком перед здачею. Це й загалом розумніший порядок, бо маркер — властивість готового файлу, а не вмісту субтитрів, і проміжні кроки не повинні вирішувати, чи буде він у результаті.
Чи змінює додавання маркера закінчення рядків у файлі?
Ні. Маркер — один символ, поставлений перед першим байтом файлу, і він не впливає на те, що йде далі. Файл Windows, повний CRLF, лишається повним CRLF, файл Unix лишається на LF, а файл зі змішаними закінченнями виходить із тією самою сумішшю, з якою прийшов. Зміна закінчень рядків — окрема сторінка, і погана ідея мати одну сторінку, яка тихо робить обидві речі.
Яким форматам субтитрів можна дати маркер порядку байтів?
Усім дванадцятьом, з якими працює сайт: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON і CSV. Маркер стосується початкових байтів файлу, а не формату субтитрів, тому немає нічого форматоспецифічного, що могло б піти не так; навіть звичайний текстовий транскрипт, який узагалі не має часової шкали, може його нести.