Коригиране на кодирането на SRT субтитри без загуба на оригиналния текст

Ако вашите SRT субтитри показват café вместо café, не бързайте да запазвате файла като UTF-8. Първо запазете непокътнато копие на оригиналните байтове, намерете декодирането, което извежда правилните думи, и запишете проверения текст в отделен файл. Запазването на грешните символи в ново кодиране просто ги съхранява завинаги погрешни.

Съществената разлика е валидно кодиране спрямо правилен текст. В първоначалния експеримент с две реплики по-долу един повреден файл преминава строга проверка за UTF-8 и не съдържа заместващи символи. Френският му текст обаче все още е погрешен. Друг файл преминава същата проверка, след като шест оригинални знака са били заменени с �.

Това ръководство предоставя локален Python инструмент за инспекция и конвертиране, файлове с изходен код за изтегляне и възпроизводим тест. То покрива диагностика на ниво файл и изрично конвертиране — без автоматично разпознаване на кодирането, видео синхронизация или гаранция за възстановяване на липсващи букви.

Първо установете какво всъщност е повредено

Разширението .srt обозначава формат за субтитри, а не гарантирано кодиране. SRT съдържа номера на реплики, времеви отпечатъци, текст и разделители; документацията за формата SRT на Библиотеката на Конгреса го описва като обикновен текст без единен стандарт за кодиране на символи.

Използвайте видимия проблем като повод за проучване, а не като окончателна диагноза:

Символите и техните изобразени форми са различни неща. Официалното обяснение за Unicode в Python разграничава кодовите точки от глифите, визуализирани от шрифта. Правилният текст в редактор прави вероятен проблема на ниво плейър; това не гарантира, че инсталирането на конкретен шрифт ще го реши. За целите на тази статия не са тествани конкретни шрифтове или плейъри.

Направете резервно копие на байтовете, след което проверете декодирането

Изтеглете subtitle_encoding.py и го поставете до SRT файла, който искате да проверите. Тези команди изискват инсталиран Python 3 и нямат допълнителни зависимости. Локалните проверки тук са направени с Python 3.14.3 под macOS. Ако вашата Windows инсталация използва стартовия панел на Python (launcher), заменете py -3 с python3; тази среда не е тествана тук.

Отворете терминал в съответната папка. В тези примери заменете input.srt с действителното име на файла. Запазете кавичките около пътища, съдържащи интервали.

Създайте непокътнато копие

python3 subtitle_encoding.py backup "input.srt" "original-bytes.srt"

Целевият файл не трябва да съществува предварително. Инструментът копира байтовете без да ги декодира, прочита обратно копието и извежда неговия SHA-256 хеш. Той също така отказва да приеме изходния път като дестинация. Запазете това резервно копие дори след като получите работещ файл със субтитри.

Проверете UTF-8 без да запазвате нищо

python3 subtitle_encoding.py inspect "original-bytes.srt"

Докладът съдържа strict_utf8, utf8_bom, избраното декодиране и — ако то е успешно — предварителен преглед на текста и replacement_characters брой. Неговият текстов изглед по подразбиране използва utf-8-sig, което се справя с водеща UTF-8 сигнатура.

• strict_utf8: false означава, че байтовете не преминават проверката за UTF-8. Това не ви казва кое друго кодиране е правилното.
• strict_utf8: true означава, че те могат да бъдат декодирани като UTF-8. Това не означава, че думите са правилни.
• Ненулев брой замествания означава, че избраното декодиране е генерирало знаци U+FFFD. Проучете ги, преди да създадете нов файл.

Инспекцията извежда безопасен за ASCII JSON, така че шрифтът на терминала да не може да скрие самоличността на знака: \u00e9 означава é, а \ufffd означава заместващия символ. За да разгледате подозрителен ред в детайли, въведете неговия физически номер на ред, а не номера на субтитъра:

python3 subtitle_encoding.py inspect "original-bytes.srt" --encoding cp1252 --line 3

Това е тест само за четене на Windows-1252, кодекът на Python cp1252 . Използвайте го, когато настройките за експортиране или историята на източника подкрепят този избор, а не защото в този пример случайно се използва френски. Отчетът за реда назовава всеки знак и показва неговата кодова точка; U+20AC е знакът за евро.

Изберете кодирането въз основа на доказателства, а не на първия успешен предварителен преглед

Попитайте създателя на файла за действителното кодиране при експортиране, проверете настройките на приложението, от което е експортиран, или го сравнете с надеждна оригинална стенограма. Прегледайте имената с ударения, препинателните знаци, валутните символи и представителните редове в целия файл. Ако не владеете езика, успешното декодиране не може да направи този преглед вместо вас.

„ANSI“ не е достатъчно точно, за да изберете изходния кодек. Нито пък Windows-1252 и Latin-1 са взаимозаменяеми. В предоставения експеримент единичният байт 80 се декодира до € при cp1252, но до контролния знак U+0080 под latin-1. И двете операции са успешни. Единствено познатият източник показва кое е правилното значение.

Други езици може да използват различни остарели кодирания, но името на езика само по себе си не определя точно едно от тях. Ако произходът е неизвестен и възможните прочитания се различават, спрете преди конвертирането и потърсете по-сигурни данни за източника.

Конвертирайте само след като изходният текст стане четлив

За източник, потвърден като Windows-1252, създайте отделен UTF-8 файл:

python3 subtitle_encoding.py convert "original-bytes.srt" "repaired-utf8.srt" --from-encoding cp1252
python3 subtitle_encoding.py inspect "repaired-utf8.srt"

Конверторът декодира стриктно целия източник, кодира този текст като UTF-8, проверява дали повторното декодиране на резултата връща същия текст и прочита обратно записаните байтове. Той не променя номерата на репликите, времевите маркери, диалога, таговете или знаците за край на ред. Новата байтова последователност може да се различава, въпреки че декодираният текст остава напълно идентичен.

Той умишлено отказва да:

• презаписва съществуващ целеви файл;
• продължава при грешка при стриктно декодиране; или
• записва текст, съдържащ U+FFFD, дори ако този символ е бил умишлен.

Последното ограничение е консервативно: този инструмент не може да определи какво е трябвало да представлява заместващият символ. Премахването му само за да се изпълни командата, би унищожило доказателства, а не би възстановило текста. Официалната документация за обработка на грешки в Python обяснява защо replace и ignore се различават от стриктното декодиране: те заместват или премахват проблемните данни. Нито един от тези подходи няма място в тази стъпка на конвертиране.

Ако възникне входно-изходна грешка, не използвайте повредения резултат. Възможно е да остане частичен нов файл; запазете оригинала и използвайте ново име на целевия файл за следващ опит. Пълното описание на работата и употребата на инструмента се намира в файла README за изтегляне.

А какво ще кажете за UTF-8 с BOM?

UTF-8 BOM е началната байтова последователност EF BB BF. Кодекът utf-8-sig в Python премахва тази сигнатура при декодиране и я добавя при кодиране.

За потвърден UTF-8 източник с BOM използвайте --from-encoding utf-8-sig. Инструментът обикновено записва UTF-8 без BOM; добавяйте --with-bom само когато изискванията на целевото приложение го налагат. Промяната на BOM не може да превърне café в café. Този експеримент не гарантира съвместимост с конкретен плейър, редактор или платформа за качване.

Пет малки файла показват защо валидността на UTF-8 не е достатъчна

Експериментът използва две изцяло авторски реплики за субтитри на френски език. Те не са взети от филм, клиент или продукт за превод:

1
00:00:01,000 --> 00:00:04,000
Émile dit : « Le prix est de 12,50 €. »

2
00:00:05,000 --> 00:00:08,000
Le café est fermé.

На 13 септември 2026 г. скрипт със стандартната библиотека на Python 3.14.3 генерира пет байтови представяния и сравни всяко от тях с този известен източник. Това са детерминистични проверки на байтове и низове, а не бенчмарк за качество на превода. Запазете свързаните файлове на диска, вместо да копирате визуализациите им в браузъра: различните байтове са същността на експеримента.

Всяко копие запазва същите два низа с времеви маркери. Правилно конвертираният файл е байт по байт идентичен с оригинала в UTF-8. Двата повредени UTF-8 файла доказват нещо по-тясно, но полезно: нито валидното кодиране, нито непроменените времеви маркери гарантират коректен текст на субтитрите. Съвпадащите времеви отпечатъци също така не дават информация дали тази измислена писта пасва на реално видео.

За да възпроизведете петте файла сами, изтеглете reproduce.py и го стартирайте с име на директория, която не съществува:

python3 reproduce.py encoding-experiment

Скриптът записва тестовите файлове и results.json , съдържащ пълния текст, трансформациите, хешовете, версията на средата за изпълнение и проверките (assertions). Сравнете го със записаните резултати от експеримента; времевият маркер за генериране ще бъде различен. Скриптовете и оригиналните учебни файлове включват MIT лиценз.

Проверките на локалния конвертор обхванаха също отказ при вече съществуващ изходен файл, отказ при проблем с пътя на източника, неуспех при неправилен кодек, отказ при U+FFFD, запазване на CRLF и изричен изход с BOM. Тези проверки валидират поведението на този инструмент спрямо файловете. Те не тестват възпроизвеждането в плейър, синхронизацията с реално медийно съдържание или превода с BookTranslator.

Ако повредените символи вече са записани

Записан mojibake: проучете точната хронология

Нашето mojibake копие следва позната верига: оригиналните UTF-8 байтове са декодирани като Windows-1252, след което тези погрешни символи са записани отново като UTF-8. Резултатът включва café и повредената поредица за евро €.

Тъй като при тази конкретна трансформация не са изгубени байтове, скриптът за възпроизвеждане може да я обърне: кодирайте грешния текст обратно чрез cp1252, след което декодирайте получените байтове като UTF-8. Той проверява възстановения текст спрямо оригинала.

Това е доказателство за тази конкретна верига, а не указание за прилагане на универсална операция „поправи mojibake“ върху всеки SRT файл. Един файл може да съдържа легитимни символи, смесена история на промените или текст, вече модифициран от предишен опит за възстановяване. За предпочитане е да използвате непокътнатия източник и стандартния път за конвертиране. Ако е останало само запазеното повредено копие (mojibake), съхранете го и установете как точно е било генерирано, преди да опитате обратна трансформация върху друго копие.

Запазени заместващи символи: липсващата буква не е кодирана там

Файлът с невъзвратима загуба беше създаден чрез декодиране на Windows-1252 байтове като UTF-8 с включено заместване и последващо запазване на резултата. Различни оригинални символи се превърнаха в един и същ маркер � . Запазеният маркер не носи достатъчно информация, за да се определи кой оригинален символ е заемал тази позиция.

Не бъркайте това с простото виждане на � в дадено приложение. Ако оригиналните байтове са непокътнати, правилното декодиране все още може да възстанови текста — както се случва с нашия източник в Windows-1252. Проверете този източник, преди да обявите загубата за необратима.

Ако единственото останало копие действително е заменило липсващия текст с U+FFFD или буквални въпросителни знаци, експортирайте отново или намерете чист източник, или сверете ръчната транскрипция с надежден материал. Обикновеният въпросителен знак може да бъде и легитимен препинателен знак; самото му присъствие не доказва нищо. Правдоподобното заместване от езиков модел е предположение, а не възстановени файлови данни.

Завършете с четим източник — а не просто с успешно изпълнена команда

Преди да приемете поправения файл, сравнете представителни думи и символи с надеждния източник, уверете се, че редовете с номера на репликите и времевите маркери не са се променили, и отворете новия файл в приложението, което ще го използва. Скриптът запазва декодирания текст; той не е валидатор на SRT синтаксис или приемо-предавателен тест за възпроизвеждане.

Ако вече можете да четете субтитрите и не се нуждаете от друг език, задачата е изпълнена. Ако се нуждаете от предварителен преглед с видеото или по-нататъшна редакция, нашето сравнение на софтуер за субтитри разяснява ролята на различните инструменти.

Едва когато изходният текст е надежден — и наистина ви е необходим друг език — преминете към Преводача на субтитри на BookTranslator и работния процес за AI превод на субтитри. Разглеждайте поправката на кодирането, превода и прегледа на финалната писта като отделни задачи. Успехът на една от тях не е доказателство, че останалите също са успешни.