Repară codarea subtitrărilor SRT fără a pierde textul original

Dacă subtitrările tale SRT afișează café în loc de café, nu salva imediat fișierul ca UTF-8. Păstrează mai întâi o copie neatinsă a octeților săi, identifică o decodare care produce cuvintele corecte și scrie textul verificat într-un fișier separat. Salvarea caracterelor greșite într-o nouă codare nu face decât să conserve caracterele greșite.

Distincția importantă este între codare validă și text corect. În experimentul inițial cu două replici de mai jos, un fișier deteriorat trece de o verificare strictă UTF-8 și nu conține caractere de înlocuire. Cu toate acestea, textul său în franceză este în continuare greșit. Un altul trece aceeași verificare după ce șase caractere originale au fost înlocuite cu �.

Acest ghid oferă un instrument Python local pentru inspecție și conversie, fișiere sursă descărcabile și un test reproductibil. Se ocupă de diagnosticarea la nivel de fișier și conversia explicită — nu de detectarea automată a codării, sincronizarea video sau promisiunea de a recupera literele lipsă.

Identifică mai întâi ce este de fapt stricat

O extensie .srt identifică un format de subtitrare, nu o codare garantată. SRT conține numere de replică, marcaje temporale, text și separatori; fișa de format SRT a Bibliotecii Congresului îl descrie ca text simplu fără un standard unic de codare a caracterelor.

Folosește simptomul vizibil ca motiv pentru a investiga, nu ca pe un diagnostic în sine:

Caracterele și formele lor afișate sunt lucruri diferite. Ghidul Unicode din Python face distincție între punctele de cod și glifele randate de fonturi. Faptul că textul este corect într-un editor indică o posibilă problemă legată de player; totuși, nu garantează că instalarea unui anumit font o va rezolva. Niciun font sau player nu a fost testat pentru acest articol.

Faceți o copie de rezervă a octeților, apoi verificați decodificarea

Descărcați subtitle_encoding.py și plasați-l lângă fișierul SRT pe care doriți să-l analizați. Aceste comenzi necesită o instalare existentă de Python 3 și niciun pachet suplimentar. Verificările locale din acest articol au fost realizate cu Python 3.14.3 pe macOS. Dacă instalarea dumneavoastră pe Windows folosește Python Launcher, înlocuiți py -3 cu python3; acel mediu nu a fost testat aici.

Deschideți un terminal în acel folder. În aceste exemple, înlocuiți input.srt cu numele real al fișierului dumneavoastră. Păstrați ghilimelele în jurul căilor care conțin spații.

Creați o copie intactă

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

Fișierul de destinație nu trebuie să existe deja. Instrumentul copiază octeții fără a-i decodifica, citește copia rezultată și îi raportează hash-ul SHA-256. De asemenea, refuză calea sursă ca destinație. Păstrați această copie de rezervă chiar și după ce ați obținut o subtitrare utilizabilă.

Verificați UTF-8 fără a salva nimic

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

Raportul include strict_utf8, utf8_bom, decodificarea selectată și—dacă decodificarea reușește—o previzualizare a textului și replacement_characters . Vizualizarea sa implicită de text folosește utf-8-sig, care gestionează corect o semnătură UTF-8 inițială.

• strict_utf8: false înseamnă că octeții nu trec verificarea UTF-8. Acest lucru nu vă spune ce altă codare este corectă.
• strict_utf8: true înseamnă că pot fi decodați ca UTF-8. Acest lucru nu înseamnă că vorbele sunt corecte.
• Un număr de înlocuiri diferit de zero înseamnă că decodarea selectată a produs caractere U+FFFD. Investigați-le înainte de a crea un fișier nou.

Inspectarea afișează JSON compatibil ASCII, astfel încât fontul terminalului să nu poată ascunde identitatea caracterelor: \u00e9 înseamnă é, iar \ufffd înseamnă caracterul de înlocuire. Pentru a examina în detaliu o linie suspectă, solicitați numărul liniei fizice — nu numărul replicii:

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

Acesta este un test doar pentru citire al Windows-1252, codec-ul cp1252 din Python. Folosiți-l atunci când setările de export sau istoricul sursei susțin această alegere, nu doar pentru că acest exemplu a folosit limba franceză. Raportul liniei denumește fiecare caracter și îi arată punctul de cod; U+20AC este simbolul euro.

Alegeți codarea pe baza dovezilor, nu după prima previzualizare reușită

Întrebați creatorul fișierului despre codarea reală de export, verificați setările aplicației de export sau comparați cu o transcriere originală de încredere. Verificați numele cu diacritice, punctuația, simbolurile monetare și linii reprezentative din tot fișierul. Dacă nu înțelegeți limba respectivă, un decodor care funcționează nu poate face această verificare în locul dumneavoastră.

„ANSI” nu este o denumire suficient de precisă pentru a selecta codecul sursă. Nici Windows-1252 și Latin-1 nu sunt interschimbabile. În experimentul furnizat, octetul unic 80 se decodează ca € în cp1252, dar ca și caracter de control U+0080 sub latin-1. Ambele operațiuni reușesc. Doar sursa inițială cunoscută ne poate spune care este varianta corectă.

Alte limbi pot folosi codificări vechi diferite, însă simpla denumire a unei limbi nu indică automat codificarea corectă. Dacă istoricul fișierului este necunoscut, iar variantele posibile de citire nu coincid, opriți-vă înainte de conversie și obțineți dovezi mai clare despre sursă.

Efectuați conversia doar după ce textul sursă devine lizibil

Pentru o sursă confirmată ca fiind Windows-1252, creați un fișier UTF-8 separat:

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

Convertorul decodează strict întreaga sursă, codifică textul respectiv ca UTF-8, verifică dacă decodarea rezultatului returnează exact același text și citește octeții scriși. Nu modifică numerele replicilor, marcajele temporale, dialogul, etichetele sau sfârșiturile de linie. Noua secvență de octeți poate fi diferită, chiar dacă textul decodat rămâne identic.

Acesta refuză în mod deliberat să:

• suprascrie o destinație existentă;
• continue după o eroare strictă de decodare; sau
• scrie text care conține U+FFFD, chiar dacă acel caracter a fost adăugat intenționat.

Ultima restricție este prudentă: acest instrument nu poate stabili ce ar fi trebuit să reprezinte un caracter de înlocuire. Eliminarea acestuia doar pentru ca această comandă să se execute cu succes ar distruge indicii valoroase, fără a restaura textul. Documentația Python privind gestionarea erorilor explică de ce replace și ignore sunt diferite de decodarea strictă: acestea înlocuiesc sau elimină datele problematice. Niciuna dintre aceste abordări nu își are locul în această etapă de conversie.

Dacă apare o eroare I/O, nu folosiți fișierul rezultat incomplet. Este posibil să rămână un fișier nou parțial; păstrați originalul și folosiți un nume nou de destinație pentru o încercare ulterioară. Comportamentul complet al instrumentului și instrucțiunile de utilizare se găsesc în fișierul README descărcabil.

Cum procedăm cu UTF-8 cu BOM?

Un BOM UTF-8 este secvența inițială de octeți EF BB BF. utf-8-sig Codec-ul din Python consumă acea semnătură la decodare și o adaugă la codificare.

Pentru o sursă confirmată UTF-8 cu BOM, folosește --from-encoding utf-8-sig. Instrumentul scrie în mod normal UTF-8 fără BOM; adaugă --with-bom doar atunci când cerințele aplicației de destinație o cer. Schimbarea unui BOM nu poate transforma café în café. Acest experiment nu stabilește compatibilitatea cu vreun player, editor sau platformă de încărcare anume.

Cinci fișiere mici arată de ce validitatea UTF-8 nu este suficientă

Experimentul utilizează două replici de subtitrare în franceză create în întregime de autor. Nu sunt preluate dintr-un film, de la un client sau dintr-un produs de traducere:

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é.

La 13 septembrie 2026, un script bazat pe biblioteca standard Python 3.14.3 a generat cinci reprezentări pe octeți și a comparat-o pe fiecare cu acea sursă cunoscută. Acestea sunt verificări deterministe de octeți și șiruri de caractere, nu un benchmark de calitate a traducerii. Salvează fișierele asociate pe disc în loc să le copiezi previzualizările din browser: diferența de octeți reprezintă chiar esența experimentului.

Fiecare copie păstrează aceleași două șiruri de timestamp. Fișierul convertit corect este identic octet cu octet cu originalul UTF-8. Cele două fișiere UTF-8 deteriorate demonstrează ceva mai specific, dar util: nici codificarea validă, nici timestamp-urile neschimbate nu garantează că textul subtitrării este corect. De asemenea, potrivirea marcajelor temporale nu spune nimic despre sincronizarea acestei piste inventate cu un videoclip real.

Pentru a reproduce chiar tu cele cinci fișiere, descarcă reproduce.py și rulează-l indicând un director care nu există:

python3 reproduce.py encoding-experiment

Scriptul generează fișierele de test și un results.json care conține textul integral, transformările, valorile hash, versiunea mediului de rulare și aserțiunile. Compară-l cu rezultatele înregistrate ale experimentului; doar marcajul temporal de generare va fi diferit. Scripturile și fișierele didactice originale includ o licență MIT.

Verificările convertorului local au testat, de asemenea, refuzul suprascrierii fișierelor existente, refuzul căilor sursă nevalide, eșecul la codec incorect, refuzul caracterului U+FFFD, păstrarea CRLF și generarea explicită a BOM. Aceste verificări testează comportamentul acestui instrument la nivel de fișier. Ele nu testează randarea în playere video, sincronizarea pe conținut media real sau traducerea prin BookTranslator.

Dacă caracterele corupte au fost deja salvate

Mojibake salvat: investighează istoricul exact

Copia noastră afectată de mojibake a urmat un lanț binecunoscut: octeții UTF-8 originali au fost decodificați ca Windows-1252, apoi acele caractere greșite au fost salvate ca UTF-8. Rezultatul include café și secvența coruptă a simbolului euro €.

Deoarece această transformare particulară nu a pierdut niciun octet, scriptul de reproducere o poate inversa: recodifică textul eronat folosind cp1252, apoi decodifică octeții rezultați ca UTF-8. Acesta verifică textul recuperat comparându-l cu originalul.

Aceasta este o dovadă valabilă pentru acest lanț specific, nu o instrucțiune de a aplica orbește o operațiune globală de „reparare mojibake” pe orice SRT. Un fișier poate conține caractere legitime, istorice mixte sau text deja modificat de o încercare anterioară de reparare. Folosește întotdeauna sursa intactă și calea normală de conversie. Dacă a mai rămas doar fișierul cu mojibake salvat, păstrează-l și află exact cum a fost produs înainte de a încerca o transformare inversă pe o copie separată.

Caractere de înlocuire salvate: litera lipsă nu este codificată acolo

Fișierul de test cu pierderi a fost creat prin decodarea octeților Windows-1252 ca UTF-8 cu opțiunea de înlocuire activată, urmată de salvarea rezultatului. Caractere originale diferite au devenit același marker � . Markerul salvat nu conține suficiente informații pentru a identifica ce caracter original a ocupat acea poziție.

Nu confundați acest lucru cu simpla vizualizare � într-o aplicație. Dacă octeții originali au rămas neatinși, o decodare corectă poate recupera totuși textul — așa cum se întâmplă pentru sursa noastră Windows-1252. Inspectați acea sursă înainte de a declara pierderea datelor.

Dacă singura copie rămasă a înlocuit efectiv textul lipsă cu U+FFFD sau cu semne de întrebare literale, reexportați sau obțineți din nou o sursă curată, ori verificați o transcriere manuală comparând-o cu un material de încredere. Un semn de întrebare obișnuit poate fi, de asemenea, o punctuație legitimă; simpla sa prezență nu dovedește nimic. O înlocuire plauzibilă generată de un model este doar o presupunere, nu date recuperate din fișier.

Asigurați-vă că obțineți o sursă lizibilă — nu doar o comandă executată cu succes

Înainte de a accepta fișierul reparat, comparați cuvinte și simboluri reprezentative cu sursa de încredere, confirmați că liniile de replică și marcajele temporale nu s-au modificat și deschideți fișierul nou în aplicația care îl va utiliza. Scriptul păstrează textul decodat; nu este un validator de sintaxă SRT și nici un test de acceptare a redării.

Dacă acum puteți citi subtitrările și nu aveți nevoie de o altă limbă, sarcina este finalizată. Dacă aveți nevoie de o verificare video directă sau de editare suplimentară, comparația programelor de subtitrare explică rolurile diferitelor instrumente.

Abia după ce textul sursă este de încredere — și chiar aveți nevoie de o altă limbă — treceți la Traducătorul de subtitrări BookTranslator și la fluxul de lucru pentru traducerea subtitrărilor cu IA. Tratați repararea codificării, traducerea și vizualizarea pistei finale ca pe sarcini separate. Niciuna dintre ele nu este o dovadă că celelalte au reușit.