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

Se as suas legendas SRT apresentarem café em vez de café, não guarde imediatamente o ficheiro como UTF-8. Primeiro, mantenha uma cópia intacta dos respetivos bytes, identifique uma descodificação que produza as palavras corretas e grave o texto verificado num ficheiro separado. Guardar os carateres errados numa nova codificação apenas perpetua os carateres errados.

A distinção fundamental é codificação válida versus texto correto. Na experiência original de duas entradas abaixo, um ficheiro corrompido passa numa verificação rigorosa de UTF-8 e não contém carateres de substituição. Ainda assim, o seu texto em francês continua incorreto. Outro passa na mesma verificação após seis carateres originais terem sido substituídos por �.

Este guia fornece uma ferramenta Python local de inspeção e conversão, ficheiros de origem transferíveis e um teste reproduzível. Trata do diagnóstico e da conversão explícita ao nível do ficheiro — não de deteção automática de codificação, sincronização de vídeo ou de uma promessa de recuperação de letras perdidas.

Primeiro, identifique o que está realmente corrompido

Uma extensão .srt identifica um formato de legendas, não uma codificação garantida. O formato SRT contém números de entrada, marcas temporais, texto e separadores; o registo do formato SRT da Biblioteca do Congresso descreve-o como texto simples sem um padrão único de codificação de carateres.

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

Os caracteres e as formas apresentadas no ecrã são coisas distintas. A explicação de Unicode do Python distingue pontos de código de glifos compostos pelo tipo de letra. Ter o texto correto num editor torna plausível a existência de um problema no leitor; contudo, isso não garante que a instalação de um tipo de letra específico resolva a situação. Nenhum tipo de letra ou leitor multimédia foi testado para este artigo.

Faça uma cópia de segurança dos bytes e, em seguida, inspecione uma descodificação

Transfira o ficheiro subtitle_encoding.py e coloque-o ao lado do ficheiro SRT que pretende investigar. Estes comandos requerem uma instalação existente do Python 3 e nenhum pacote adicional. As verificações locais apresentadas recorreram ao Python 3.14.3 no macOS. Se a sua instalação do Windows utilizar o inicializador do Python, substitua py -3 por python3; esse ambiente não foi testado aqui.

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

Crie uma cópia intacta

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

O destino não pode existir previamente. A ferramenta copia os bytes sem os descodificar, lê a cópia novamente e indica o respetivo hash SHA-256. Também rejeita o caminho de origem como destino. Mantenha esta cópia de segurança mesmo após criar uma legenda utilizável.

Verifique o UTF-8 sem guardar nada

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

O relatório inclui strict_utf8, utf8_bom, a descodificação selecionada e — se essa descodificação for bem-sucedida — uma pré-visualização do texto e replacement_characters . A sua vista de texto predefinida utiliza utf-8-sig, que suporta uma assinatura UTF-8 inicial.

• strict_utf8: false significa que os bytes falham a validação de UTF-8. Não indica qual é a outra codificação correta.
• strict_utf8: true significa que podem ser descodificados como UTF-8. Não significa que as palavras estejam corretas.
• Uma contagem de substituições diferente de zero significa que a descodificação selecionada produziu carateres U+FFFD. Inspecione-os antes de criar um novo ficheiro.

A inspeção apresenta JSON seguro para ASCII para que o tipo de letra do terminal não oculte a identidade dos carateres: \u00e9 significa é, e \ufffd representa o caráter de substituição. Para analisar uma linha suspeita em detalhe, indique o número físico da linha—não o número da legenda:

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

Este é um teste só de leitura para Windows-1252, o codec cp1252 do Python. Utilize-o quando as definições de exportação ou o histórico de origem justificarem essa escolha, e não apenas porque este exemplo usou francês. O relatório da linha identifica cada caráter e mostra o respetivo code point; U+20AC é o símbolo do euro.

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

Pergunte a quem criou o ficheiro qual foi a codificação de exportação real, verifique as definições da aplicação que exportou ou compare com uma transcrição original de confiança. Reveja nomes com acentos, pontuação, símbolos de moeda e linhas representativas ao longo de todo o ficheiro. Se não souber ler o idioma, um descodificador bem-sucedido não poderá fazer essa verificação por si.

«ANSI» não é suficientemente preciso para selecionar o codec de origem. Da mesma forma, o Windows-1252 e o Latin-1 não são permutáveis. Na experiência fornecida, o byte individual 80 é descodificado como € no cp1252, mas como o caráter de controlo U+0080 sob latin-1. Ambas as operações são bem-sucedidas. Apenas a origem conhecida nos diz qual é 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 melhores evidências sobre a origem.

Converta apenas depois de o texto de origem estar legível

Para uma origem confirmada como Windows-1252, crie um ficheiro UTF-8 em 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 descodifica a origem completa de forma estrita, codifica esse texto como UTF-8, verifica se a descodificação da saída devolve o mesmo texto e lê os bytes gravados de volta. Não edita números de deixa, marcas temporais, diálogos, etiquetas ou quebras de linha. A nova sequência de bytes pode diferir, mesmo que o texto descodificado permaneça idêntico.

Recusa deliberadamente:

• substituir um destino existente;
• avançar perante um erro de descodificação estrita; ou
• gravar texto que contenha U+FFFD, mesmo que esse caráter tenha sido intencional.

A última restrição é conservadora: esta ferramenta não consegue determinar o que um caráter de substituição pretendia representar. Removê-lo para que o comando seja concluído com êxito descartaria evidências, em vez de restaurar o texto. A documentação de processamento de erros do Python explica por que razão replace e ignore são diferentes da descodificação estrita: substituem ou descartam dados problemáticos. Nenhum deles tem lugar nesta etapa de conversão.

Se ocorrer um erro de E/S, não utilize a saída com falha. Um ficheiro novo parcial pode permanecer; mantenha o original e utilize um novo nome de destino para uma tentativa posterior. O comportamento completo da ferramenta e a sua utilização constam no README descarregável.

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 descodificar e adiciona-a ao codificar.

Para uma fonte comprovadamente em UTF-8 com um BOM, utilize --from-encoding utf-8-sig. Normalmente, a ferramenta grava em UTF-8 sem BOM; adicione --with-bom apenas quando os requisitos da aplicação de destino assim o exigirem. Alterar um BOM não consegue transformar café em café. Esta experiência não estabelece a compatibilidade com nenhum leitor, editor ou plataforma de envio em particular.

Cinco pequenos ficheiros mostram porque a validade do UTF-8 não é suficiente

A experiência utiliza duas legendas em francês inteiramente criadas pelo autor. Não foram retiradas de nenhum filme, cliente ou 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é.

A 13 de setembro de 2026, um script baseado na biblioteca padrão do Python 3.14.3 gerou cinco representações de bytes e comparou cada uma delas com essa fonte conhecida. Trata-se de verificações determinísticas de bytes e strings, e não de uma avaliação comparativa de qualidade de tradução. Guarde os ficheiros associados no disco em vez de copiar as respetivas pré-visualizações no navegador: a diferença entre os bytes é precisamente o objetivo da experiência.

Cada cópia mantém exatamente as mesmas duas strings de marca temporal. O ficheiro convertido corretamente é idêntico byte a byte ao original em UTF-8. Os dois ficheiros UTF-8 corrompidos provam algo mais restrito, mas bastante útil: nem uma codificação válida nem marcas temporais inalteradas garantem que o texto das legendas esteja correto. Marcas temporais coincidentes também nada dizem sobre se esta faixa fictícia se ajusta a um vídeo real.

Para reproduzir os cinco ficheiros por si mesmo, transfira o reproduce.py e execute-o indicando o nome de um diretório que não exista:

python3 reproduce.py encoding-experiment

O script cria os ficheiros de teste e um results.json com o texto integral, transformações, hashes, versão do runtime e asserções. Compare-o com os resultados registados da experiência; apenas a marca temporal da geração será diferente. Os scripts e os ficheiros didáticos originais incluem uma licença MIT.

As verificações do conversor local também testaram a recusa de sobrescrita de ficheiros existentes, a recusa do caminho de origem, a falha por codec incorreto, a recusa de U+FFFD, a preservação de CRLF e a exportação explícita de BOM. Estas verificações comprovam o comportamento do utilitário a nível de ficheiros. Não testam a renderização em reprodutores multimédia, a sincronização com ficheiros de vídeo reais ou a tradução do BookTranslator.

Se os caracteres corrompidos já tiverem sido guardados

Mojibake guardado: investigue o histórico exato

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

Como esta transformação específica não perdeu nenhuns bytes, o script de reprodução consegue revertê-la: codifica o texto incorreto novamente com cp1252e depois descodifica os bytes resultantes como UTF-8. O processo verifica ainda o texto recuperado face ao original.

Isto serve de prova para esta cadeia conhecida, e não como instrução para aplicar uma operação genérica de «reparação de mojibake» a qualquer SRT. Um ficheiro pode conter caracteres legítimos, históricos mistos ou texto já alterado por uma tentativa de reparação anterior. Dê sempre preferência ao ficheiro de origem intacto e ao processo normal de conversão. Se restar apenas o ficheiro com mojibake guardado, preserve-o e determine de que forma foi gerado antes de tentar uma transformação inversa numa cópia separada.

Carateres de substituição guardados: a letra em falta não está codificada aí

O exemplo de perda foi criado ao descodificar bytes Windows-1252 como UTF-8 com a substituição ativada, guardando depois o resultado. Carateres originais distintos transformaram-se no mesmo marcador � . O marcador guardado não contém informação suficiente para identificar que caráter original ocupava essa posição.

Não confunda isto com apenas ver � numa aplicação. Se os bytes originais permanecerem intactos, uma descodificação correta pode ainda recuperar o texto — tal como acontece com a nossa fonte Windows-1252. Inspecione essa fonte antes de declarar perda definitiva.

Se a única cópia restante tiver efetivamente substituído o texto em falta por U+FFFD ou pontos de interrogação literais, volte a exportar ou a obter uma fonte limpa, ou valide uma transcrição manual com material fiável. Um ponto de interrogação comum também pode ser pontuação legítima; a sua simples presença não prova nada. A substituição plausível gerada por um modelo é uma suposição, não dados recuperados do ficheiro.

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

Antes de aceitar o ficheiro reparado, compare palavras e símbolos representativos com a fonte fidedigna, confirme que as linhas de marcação e de carimbos de data/hora não se alteraram e abra o novo ficheiro na aplicação que o irá utilizar. O script preserva o texto descodificado; não é um validador de sintaxe SRT nem um teste de aceitação de reprodução.

Se agora consegue ler as legendas e não precisa de outro idioma, a tarefa está concluída. Se necessitar de rever o vídeo diretamente ou de fazer mais edições, a comparação de software de legendagem explica as diferentes funções de cada ferramenta.

Apenas quando o texto de origem for de confiança — e precisar realmente de outro idioma — avance para o Tradutor de Legendas do BookTranslator e para o fluxo de trabalho de tradução de legendas com IA. Trate a reparação de codificação, a tradução e a visualização da faixa final como tarefas distintas. O sucesso de uma não prova o das outras.