Correggi la codifica dei sottotitoli SRT senza perdere il testo originale

Se i tuoi sottotitoli SRT mostrano café al posto di café, non salvare subito il file in formato UTF-8. Prima di tutto, conserva una copia intatta dei byte originali, individua la codifica che restituisce le parole corrette e scrivi il testo verificato in un file separato. Salvare i caratteri errati con una nuova codifica non farà altro che preservare gli errori.

La distinzione fondamentale è tra codifica valida e testo corretto. Nel nostro esperimento su due battute riportato di seguito, un file corrotto supera un rigoroso controllo UTF-8 e non contiene caratteri di sostituzione. Eppure, il suo testo in francese è ancora errato. Un altro file supera lo stesso controllo dopo che sei caratteri originali sono stati sostituiti con �.

Questa guida mette a disposizione uno strumento Python locale per l'ispezione e la conversione, file sorgente scaricabili e un test riproducibile. Si occupa della diagnosi a livello di file e della conversione esplicita: non si tratta di un rilevamento automatico della codifica, né di una sincronizzazione video o di una promessa di recuperare lettere mancanti.

Per prima cosa, identifica qual è il vero problema

L'estensione .srt identifica un formato di sottotitoli, non una codifica garantita. Il formato SRT contiene numeri di battuta, timestamp, testo e separatori; la scheda sul formato SRT della Library of Congress lo descrive come testo semplice privo di un unico standard di codifica dei caratteri.

Considera il sintomo visibile come un motivo per approfondire, non come una diagnosi definitiva:

I caratteri e le forme grafiche con cui vengono mostrati sono cose diverse. La spiegazione su Unicode di Python distingue i code point dai glifi renderizzati dai font. Se il testo appare corretto in un editor, è plausibile che il problema riguardi il lettore; questo però non garantisce che installare un font specifico risolverà la situazione. Nessun font o lettore è stato testato per questo articolo.

Esegui il backup dei byte, poi analizza la decodifica

Scarica subtitle_encoding.py e posizionalo accanto al file SRT che vuoi esaminare. Questi comandi richiedono un'installazione esistente di Python 3 e nessun pacchetto aggiuntivo. I controlli locali qui descritti hanno utilizzato Python 3.14.3 su macOS. Se la tua installazione di Windows utilizza il Python launcher, sostituisci py -3 a python3; tale ambiente non è stato testato in questa sede.

Apri un terminale in quella cartella. In questi esempi, sostituisci input.srt con il nome effettivo del tuo file. Mantieni le virgolette per i percorsi che contengono spazi.

Crea una copia intatta

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

La destinazione non deve essere già esistente. Lo strumento copia i byte senza decodificarli, rilegge la copia e restituisce il relativo hash SHA-256. Rifiuta inoltre il percorso di origine come destinazione. Conserva questo backup anche dopo aver ottenuto un sottotitolo utilizzabile.

Verifica la codifica UTF-8 senza salvare nulla

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

Il report include strict_utf8, utf8_bom, la decodifica selezionata e, se tale decodifica ha successo, un'anteprima del testo e replacement_characters . La sua visualizzazione di testo predefinita utilizza utf-8-sig, che gestisce una firma iniziale UTF-8.

• strict_utf8: false indica che i byte non superano la verifica UTF-8. Non ti dice quale altra codifica sia corretta.
• strict_utf8: true significa che possono essere decodificati come UTF-8. Non significa che le parole siano corrette.
• Un conteggio di sostituzioni diverso da zero indica che la decodifica selezionata ha prodotto caratteri U+FFFD. Esaminali attentamente prima di creare un nuovo file.

L'ispezione stampa JSON compatibile con ASCII affinché il font del terminale non possa nascondere l'identità del carattere: \u00e9 indica é, e \ufffd indica il carattere di sostituzione. Per esaminare in dettaglio una riga sospetta, richiedi il suo numero di riga fisico, non il suo numero di sottotitolo:

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

Questo è un test in sola lettura di Windows-1252, il codec cp1252 di Python. Usalo quando le impostazioni di esportazione o la provenienza della sorgente supportano tale scelta, non perché questo esempio si trova a utilizzare il francese. Il report della riga denomina ciascun carattere e ne mostra il code point; U+20AC è il simbolo dell'euro.

Scegli la codifica in base alle evidenze, non alla prima anteprima riuscita

Chiedi a chi ha creato il file la reale codifica di esportazione, controlla le impostazioni dell'applicazione di esportazione o confrontalo con una trascrizione originale attendibile. Verifica i nomi accentati, la punteggiatura, i simboli di valuta e le righe più rappresentative nell'intero file. Se non conosci la lingua, nessun decodificatore riuscito potrà fare questa verifica al posto tuo.

Il termine “ANSI” non è abbastanza preciso per selezionare il codec sorgente. Né Windows-1252 e Latin-1 sono intercambiabili. Nell'esperimento fornito, il singolo byte 80 si decodifica in € con cp1252, ma nel carattere di controllo U+0080 con latin-1. Entrambe le operazioni vanno a buon fine. Solo la fonte certa può indicare quale sia quella corretta.

Altre lingue possono utilizzare diverse codifiche legacy, ma il solo nome della lingua non è sufficiente a determinarne una. Se la cronologia è sconosciuta e le letture ipotizzate non coincidono, fermati prima della conversione e recupera informazioni più certe sull'origine del file.

Converti solo dopo aver reso leggibile il testo sorgente

Per una sorgente confermata come Windows-1252, crea un file UTF-8 separato:

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

Il convertitore decodifica l'intera sorgente in modalità rigorosa (strict), codifica tale testo in UTF-8, verifica che la decodifica dell'output restituisca lo stesso identico testo e rilegge i byte scritti. Non modifica numeri di battuta, timestamp, dialoghi, tag o interruzioni di riga. La nuova sequenza di byte può differire anche se il testo decodificato rimane identico.

Rifiuta deliberatamente di:

• sovrascrivere una destinazione esistente;
• proseguire in caso di errore di decodifica strict; oppure
• scrivere testo contenente U+FFFD, anche se tale carattere era intenzionale.

Quest'ultima restrizione è prudenziale: questo strumento non può stabilire cosa dovesse rappresentare un carattere di sostituzione. Rimuoverlo per far passare il comando significherebbe eliminare prove, non ripristinare il testo. La documentazione sui gestori di errori di Python spiega perché replace e ignore differiscano dalla decodifica strict: sostituiscono o scartano i dati problematici. Nessuno dei due è adatto a questa fase di conversione.

Se si verifica un errore di I/O, non utilizzare l'output non riuscito. Potrebbe rimanere un nuovo file parziale; conserva l'originale e usa un nuovo nome di destinazione per un tentativo successivo. Il comportamento completo e l'utilizzo dello strumento sono descritti nel README scaricabile.

E per quanto riguarda UTF-8 con BOM?

Un BOM UTF-8 è la sequenza di byte iniziale EF BB BF. Il codec utf-8-sig di Python rimuove tale firma durante la decodifica e la aggiunge in fase di codifica.

Per un file sorgente UTF-8 confermato con BOM, usa --from-encoding utf-8-sig. Lo strumento scrive normalmente in UTF-8 senza BOM; aggiungi --with-bom solo quando i requisiti dell'applicazione di destinazione lo richiedono. Modificare un BOM non può trasformare café in café. Questo esperimento non stabilisce la compatibilità con alcun lettore, editor o piattaforma di caricamento in particolare.

Cinque piccoli file mostrano perché la validità UTF-8 non è sufficiente

L'esperimento utilizza due battute di sottotitoli in francese create interamente da noi. Non sono tratte da un film, da un cliente o da un prodotto di traduzione:

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

Il 13 settembre 2026, uno script basato sulla libreria standard di Python 3.14.3 ha generato cinque rappresentazioni di byte e le ha confrontate con tale sorgente nota. Si tratta di verifiche deterministiche su byte e stringhe, non di un benchmark sulla qualità della traduzione. Salva i file collegati su disco anziché copiare le loro anteprime nel browser: i byte differenti sono proprio il fulcro dell'esperimento.

Ogni copia conserva le stesse due stringhe di timestamp. Il file convertito correttamente è identico byte per byte all'originale UTF-8. I due file UTF-8 danneggiati dimostrano un punto più circoscritto ma utile: né una codifica valida né timestamp inalterati garantiscono la correttezza del testo dei sottotitoli. Inoltre, la corrispondenza dei timestamp non dice nulla sull'effettiva sincronizzazione di questa traccia fittizia con un video reale.

Per riprodurre autonomamente i cinque file, scarica reproduce.py ed eseguilo indicando il nome di una directory non esistente:

python3 reproduce.py encoding-experiment

Lo script genera i file di test e un results.json contenente il testo completo, le trasformazioni, gli hash, la versione del runtime e le asserzioni. Confrontalo con i risultati registrati dell'esperimento; il timestamp di generazione sarà diverso. Gli script e i file didattici originali includono una licenza MIT.

I controlli del convertitore locale hanno verificato anche il rifiuto di sovrascrivere output esistenti, il rifiuto di percorsi di origine non validi, il fallimento con codec errato, il rifiuto di U+FFFD, la conservazione dei ritorni a capo CRLF e l'output con BOM esplicito. Tali verifiche attestano il comportamento dello strumento sui file. Non testano il rendering nei player, il timing sui file multimediali reali o la traduzione di BookTranslator.

Se i caratteri corrotti sono già stati salvati

Mojibake salvato: analizzare la cronologia esatta

La nostra copia con mojibake ha seguito una sequenza nota: i byte originali in UTF-8 sono stati decodificati come Windows-1252, dopodiché quei caratteri errati sono stati salvati come UTF-8. Il risultato include café e la sequenza corrotta del simbolo dell'euro €.

Poiché questa specifica trasformazione non ha perso alcun byte, lo script di riproduzione è in grado di invertirla: ricodificare il testo errato tramite cp1252, quindi decodificare i byte risultanti come UTF-8. Lo script verifica infine il testo recuperato confrontandolo con l'originale.

Questa è la prova dell'efficacia per questa sequenza specifica, non un invito ad applicare un'operazione generica di "riparazione mojibake" a qualsiasi file SRT. Un file può infatti contenere caratteri legittimi, passaggi storici misti o testo già alterato da un precedente tentativo di ripristino. È sempre preferibile partire dalla sorgente intatta e seguire la normale procedura di conversione. Se resta solo il file con mojibake salvato, fanne una copia di sicurezza e ricostruisci esattamente come è stato generato prima di tentare una trasformazione inversa su un'altra copia.

Caratteri di sostituzione salvati: la lettera mancante non è codificata lì

Il campione con perdita è stato creato decodificando byte Windows-1252 come UTF-8 con la sostituzione abilitata, per poi salvare il risultato. Caratteri originali diversi sono diventati lo stesso marcatore � . Il marcatore salvato non contiene informazioni sufficienti per identificare quale carattere originale occupasse quella posizione.

Non confondere questo fenomeno con il semplice fatto di vederlo � all'interno di un'applicazione. Se i byte originali non sono stati modificati, una decodifica corretta può comunque recuperare il testo, proprio come avviene per la nostra sorgente Windows-1252. Esamina attentamente la sorgente prima di dare per scontata la perdita definitiva.

Se l'unica copia rimasta ha effettivamente sostituito il testo mancante con U+FFFD o con punti interrogativi letterali, riesporta o recupera nuovamente una sorgente intatta, oppure verifica una trascrizione manuale confrontandola con materiale affidabile. Un normale punto interrogativo può essere anche una punteggiatura del tutto legittima; la sua sola presenza non dimostra nulla. La sostituzione verosimile proposta da un modello linguistico è una congettura, non dati di file realmente recuperati.

Punta a una sorgente leggibile, non solo a un comando eseguito con successo

Prima di considerare valido il file riparato, confronta parole e simboli rappresentativi con la sorgente affidabile, verifica che le righe delle battute e dei timestamp non siano cambiate e apri il nuovo file nell'applicazione in cui verrà effettivamente utilizzato. Lo script preserva il testo decodificato, ma non funge da validatore della sintassi SRT né da test di conformità per la riproduzione.

Se ora riesci a leggere i sottotitoli e non hai bisogno di altre lingue, il lavoro è concluso. Se invece ti occorre una revisione video approfondita o ulteriori modifiche, il confronto dei software per sottotitoli spiega i diversi ruoli svolti da ciascuno strumento.

Solo quando il testo sorgente è affidabile — e hai effettivamente bisogno di un'altra lingua — passa al traduttore di sottotitoli di BookTranslator e al flusso di lavoro per la traduzione di sottotitoli con l'IA. Considera la riparazione della codifica, la traduzione e la visualizzazione della traccia finale come passaggi distinti. Nessuno di essi dimostra da solo che anche gli altri siano riusciti.