Como corrigir a codificação de legendas SRT sem perder o texto original

Se as suas legendas SRT exibem café em vez de café, não salve o arquivo imediatamente como UTF-8. Primeiro, mantenha uma cópia intocada dos seus bytes, identifique uma decodificação que produza as palavras corretas e grave o texto verificado em um arquivo separado. Salvar os caracteres incorretos em uma nova codificação apenas perpetua os caracteres errados.

A distinção fundamental é codificação válida versus texto correto. No experimento original de dois blocos a seguir, um arquivo corrompido passa por uma verificação rigorosa de UTF-8 e não contém caracteres de substituição. Ainda assim, seu texto em francês continua errado. Outro passa na mesma verificação após seis caracteres originais terem sido substituídos por �.

Este guia fornece uma ferramenta local em Python para inspeção e conversão, arquivos de origem para download e um teste reproduzível. Ele aborda o diagnóstico em nível de arquivo e a conversão explícita — e não a detecção automática de codificação, a sincronização de vídeo ou a promessa de recuperar letras perdidas.

Primeiro, identifique o que realmente está com defeito

A extensão .srt identifica um formato de legenda, não uma codificação garantida. O formato SRT contém números de legenda, marcações de tempo, texto e separadores; o registro do formato SRT da Biblioteca do Congresso o descreve como texto simples sem um padrão único de codificação de caracteres.

Use o sintoma visível como um motivo para investigar, e não como um diagnóstico definitivo por si só:

Caracteres e suas formas exibidas são coisas diferentes. A explicação sobre Unicode do Python distingue code points de glifos renderizados por fontes. Um texto correto em um editor torna plausível um problema no reprodutor; isso não prova que instalar uma fonte específica resolverá o problema. Nenhuma fonte ou reprodutor foi testado para este artigo.

Faça backup dos bytes e, em seguida, inspecione uma decodificação

Baixe subtitle_encoding.py e coloque-o ao lado do SRT que deseja investigar. Esses comandos exigem uma instalação existente do Python 3 e nenhum pacote extra. As verificações locais aqui usaram o Python 3.14.3 no macOS. Se a sua instalação no Windows usar o iniciador do Python, substitua py -3 por python3; esse ambiente não foi testado aqui.

Abra um terminal nessa pasta. Nesses exemplos, substitua input.srt pelo nome real do seu arquivo. Mantenha aspas em caminhos que contenham espaços.

Faça uma cópia intocada

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

O destino não pode existir previamente. A ferramenta copia os bytes sem decodificá-los, lê a cópia de volta e informa seu hash SHA-256. Ela também recusa o caminho de origem como destino. Mantenha este backup mesmo depois de gerar uma legenda utilizável.

Verifique o UTF-8 sem salvar nada

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

O relatório inclui strict_utf8, utf8_bom, a decodificação selecionada e — se essa decodificação for bem-sucedida — uma prévia do texto e replacement_characters . Sua visualização de texto padrão usa utf-8-sig, que lida com uma assinatura UTF-8 inicial.

• strict_utf8: false significa que os bytes falharam na verificação UTF-8. Isso não informa qual outra codificação está correta.
• strict_utf8: true significa que eles podem ser decodificados como UTF-8. Isso não significa que as palavras estão corretas.
• Uma contagem de substituição diferente de zero significa que a decodificação selecionada produziu caracteres U+FFFD. Investigue-os antes de criar um novo arquivo.

A inspeção imprime JSON seguro para ASCII para que a fonte do terminal não oculte a identidade do caractere: \u00e9 significa é, e \ufffd indica o caractere de substituição. Para examinar uma linha suspeita em detalhes, solicite o número da linha física — não o número da legenda:

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

Este é um teste somente leitura de Windows-1252, o codec cp1252 do Python. Use-o quando as configurações de exportação ou o histórico de origem justificarem essa escolha, e não apenas porque este exemplo por acaso usou francês. O relatório de linha nomeia cada caractere e mostra seu ponto de código; U+20AC é o símbolo do euro.

Escolha a codificação com base em evidências, não na primeira pré-visualização bem-sucedida

Pergunte ao criador do arquivo qual foi a codificação de exportação real, verifique as configurações do aplicativo de exportação ou compare com uma transcrição original confiável. Revise nomes com acentos, pontuação, símbolos de moeda e linhas representativas ao longo de todo o arquivo. Se você não souber ler o idioma, um decodificador bem-sucedido não poderá fazer essa revisão por você.

“ANSI” não é preciso o suficiente para selecionar o codec de origem. Da mesma forma, Windows-1252 e Latin-1 não são intercambiáveis. No experimento fornecido, o byte único 80 é decodificado como € no cp1252, mas como o caractere de controle U+0080 sob latin-1. Ambas as operações são bem-sucedidas. Apenas a origem conhecida nos diz qual era a pretendida.

Outros idiomas podem usar diferentes codificações legadas, mas o nome de um idioma por si só não determina uma codificação. Se o histórico for desconhecido e as leituras candidatas divergirem, pare antes da conversão e obtenha evidências mais claras sobre a fonte.

Converta apenas depois que o texto de origem estiver legível

Para uma fonte confirmada como Windows-1252, crie um arquivo UTF-8 separado:

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

O conversor decodifica a fonte completa de forma estrita, codifica esse texto como UTF-8, verifica se a decodificação da saída retorna o mesmo texto e lê os bytes gravados de volta. Ele não edita números de legendas, marcações de tempo, diálogos, tags ou quebras de linha. A nova sequência de bytes pode ser diferente, mesmo que o texto decodificado permaneça idêntico.

Ele se recusa deliberadamente a:

• sobrescrever um destino existente;
• continuar após um erro de decodificação estrita; ou
• gravar texto contendo U+FFFD, mesmo que esse caractere tenha sido intencional.

A última restrição é conservadora: esta ferramenta não pode decidir o que um caractere de substituição deveria representar. Removê-lo para fazer o comando passar descartaria evidências, em vez de restaurar o texto. A documentação de manipuladores de erro do Python explica por que replace e ignore são diferentes da decodificação estrita: eles substituem ou descartam dados problemáticos. Nenhum dos dois tem lugar nesta etapa de conversão.

Se ocorrer um erro de E/S, não use a saída com falha. Um arquivo novo parcial pode restar; mantenha o original e use um novo nome de destino para uma tentativa posterior. O comportamento completo da ferramenta e o uso estão no README para download.

E quanto ao UTF-8 com BOM?

Um BOM UTF-8 é a sequência de bytes inicial EF BB BF. O utf-8-sig codec do Python consome essa assinatura ao decodificar e a adiciona ao codificar.

Para uma fonte UTF-8 confirmada com BOM, use --from-encoding utf-8-sig. A ferramenta normalmente grava em UTF-8 sem BOM; adicione --with-bom apenas quando as exigências do aplicativo de destino assim determinarem. Mudar um BOM não pode transformar café em café. Este experimento não atesta compatibilidade com nenhum player, editor ou plataforma de upload específica.

Cinco arquivos pequenos mostram por que a validade do UTF-8 não é suficiente

O experimento usa dois blocos de legendas em francês de autoria própria. Eles não foram extraídos de um filme, de um cliente ou de um produto de tradução:

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

Em 13 de setembro de 2026, um script da biblioteca padrão do Python 3.14.3 gerou cinco representações de bytes e comparou cada uma com essa fonte conhecida. Trata-se de verificações determinísticas de bytes e strings, e não de um benchmark de qualidade de tradução. Salve os arquivos vinculados no disco em vez de copiar a visualização do navegador: a diferença nos bytes é o ponto central do experimento.

Cada cópia mantém exatamente as mesmas duas strings de carimbo de data/hora. O arquivo convertido corretamente é idêntico byte a byte ao original em UTF-8. Os dois arquivos UTF-8 corrompidos provam algo mais restrito, mas muito útil: nem uma codificação válida nem carimbos de data/hora inalterados garantem que o texto da legenda esteja correto. Além disso, carimbos de data/hora correspondentes não dizem nada sobre se essa faixa inventada sincroniza com um vídeo real.

Para reproduzir os cinco arquivos você mesmo, baixe reproduce.py e execute-o com o nome de um diretório inexistente:

python3 reproduce.py encoding-experiment

O script cria os arquivos de teste e um results.json contendo o texto completo, transformações, hashes, versão de tempo de execução e asserções. Compare-o com os resultados registrados do experimento; o carimbo de data/hora de geração será diferente. Os scripts e os arquivos didáticos originais incluem uma licença MIT.

As verificações do conversor local também testaram a recusa de sobrescrever saídas existentes, a recusa de caminhos de origem inválidos, falhas por codec incorreto, recusa de U+FFFD, preservação de CRLF e saída explícita de BOM. Essas verificações validam o comportamento de arquivos desta ferramenta. Elas não testam a renderização em reprodutores, o sincronismo em mídias reais ou a tradução do BookTranslator.

Se os caracteres corrompidos já tiverem sido salvos

Mojibake salvo: investigue o histórico exato

Nossa cópia com mojibake seguiu uma cadeia conhecida: os bytes originais em UTF-8 foram decodificados como Windows-1252 e, em seguida, esses caracteres incorretos foram salvos como UTF-8. O resultado inclui café e a sequência corrompida do euro €.

Como essa transformação específica não perdeu bytes, o script de reprodução consegue revertê-la: codifica o texto incorreto novamente via cp1252e, em seguida, decodifica os bytes resultantes como UTF-8. Ele compara e valida o texto recuperado com o original.

Isso serve como evidência para essa cadeia específica, e não como uma instrução para aplicar uma operação genérica de “reparar mojibake” a todo arquivo SRT. Um arquivo pode conter caracteres legítimos, históricos mistos ou textos já alterados por uma tentativa anterior de reparo. Dê preferência ao arquivo original intocado e ao processo de conversão padrão. Se restar apenas o mojibake salvo, preserve-o e descubra exatamente como ele foi gerado antes de tentar uma transformação inversa em outra cópia.

Caracteres de substituição salvos: a letra ausente não está codificada ali

O arquivo de teste com perda de dados foi gerado ao decodificar bytes do Windows-1252 como UTF-8 com a substituição ativada e, em seguida, salvar o resultado. Diferentes caracteres originais viraram o mesmo marcador � . O marcador salvo não carrega informações suficientes para identificar qual caractere original ocupava aquela posição.

Não confunda isso com apenas visualizar � em um aplicativo. Se os bytes originais permanecerem intactos, uma decodificação correta ainda poderá recuperar o texto — como ocorre com a nossa fonte em Windows-1252. Inspecione essa fonte antes de declarar perda definitiva.

Se a única cópia restante tiver de fato substituído o texto ausente por U+FFFD ou pontos de interrogação literais, exporte novamente ou obtenha uma fonte limpa, ou verifique uma transcrição manual comparando-a com materiais confiáveis. Um ponto de interrogação comum também pode ser uma pontuação legítima; sua presença isolada não prova nada. Uma substituição plausível feita por um modelo é apenas um palpite, não dados recuperados do arquivo.

Conclua com uma fonte legível — não apenas com um comando bem-sucedido

Antes de aceitar o arquivo corrigido, compare palavras e símbolos representativos com a fonte confiável, confirme se as linhas de marcação e de carimbo de data/hora não foram alteradas e abra o novo arquivo no aplicativo que irá utilizá-lo. O script preserva o texto decodificado; ele não é um validador de sintaxe SRT nem um teste de aceitação de reprodução.

Se agora você consegue ler as legendas e não precisa de outro idioma, a tarefa está concluída. Caso precise de uma revisão prática em vídeo ou de edições adicionais, a comparação de softwares de legenda explica as diferentes funções de cada ferramenta.

Somente quando o texto de origem for confiável — e você realmente precisar de outro idioma — avance para o Tradutor de Legendas do BookTranslator e para o fluxo de trabalho de tradução de legendas por IA. Trate a correção de codificação, a tradução e a visualização da faixa final como etapas distintas. Nenhuma delas serve de prova de que as outras foram bem-sucedidas.