O ficheiro está bem, foi lido mal
O que um ficheiro de legendas guarda são bytes. Transformar bytes em caracteres exige saber em que codificação foram escritos: erras isso e saem caracteres ilegíveis. Não falta nem um byte ao ficheiro; lê-lo outra vez com a codificação certa e os caracteres voltam.
Isso divide o trabalho em dois: descobrir com que codificação começou e gravá-lo numa codificação que o teu leitor detete. O primeiro vem de descodificar a tentar e pontuar, o segundo de gravar uma cópia. Resolvem problemas diferentes.
Cinco aspetos, cinco causas
Os caracteres ilegíveis não nascem ao acaso: o aspeto entrega a causa:
- Blocos de letras acentuadas (`ä½ å¥½`): chinês em UTF-8 lido como codificação de um byte — o chinês leva três bytes por caráter em UTF-8, e ler byte a byte transforma cada byte na sua própria letra
- Filas de caracteres CJK sem um único comum: UTF-8 lido como GBK — os bytes reagrupam-se aos pares e cada par cai nalgum caráter raro
- Um monte de símbolos de moeda e matemáticos: os bytes caíram na zona dos símbolos, típico de ser lido como Mac Roman ou alguma variante de Latin-1
- Caracteres de controlo misturados: os bytes caíram na zona de controlo invisível e no ecrá aparecem como espaços vazios ou caixas
- O ponto de interrogação numa caixa `�`: esse é o caráter de substituição, não texto ilegível — significa «aqui havia um caráter e já se perdeu ao ler»
Porque o caráter de substituição não se corrige
O caráter de substituição é a linha divisória. Um `�` significa que os bytes já foram deitados fora num passo anterior (normalmente algum programa que leu o ficheiro e voltou a gravá-lo), e não ficou registo do que se perdeu. Aí não há nada de onde deduzir: ninguém consegue corrigir.
Por isso a página de correção trata dois casos de forma diferente. Envias um ficheiro e os bytes originais continuam intactos, o que permite experimentar cada codificação; se o texto colado já contém o caráter de substituição, diz-se claro: «não se pode corrigir, envia o ficheiro original».
E há o caso inverso: o conteúdo lê-se perfeitamente, mas o teu leitor continua a mostrar lixo. A culpa não é do ficheiro: o leitor escolheu mal a codificação. Editar o texto não serve de nada; grava uma cópia em UTF-8 com BOM ou GBK e dá-lhe essa.
O que se está a comparar ao corrigir
A ferramenta experimenta todas as codificações plausíveis e pontua cada resultado: quanto há de caracteres comuns, se há filas de acentos, filas de símbolos, se as filas CJK são muralhas de caracteres raros. O resultado com melhor pontuação sobe ao topo da lista.
Se nenhuma pontuação for claramente melhor, nada é recomendado: antes dizer-te «isto lê-se bem como está» do que empurrar-te algo que só vagamente parece uma língua. O texto estragado duas vezes (gravado mal uma vez e corrigido mal outra) recebe uma volta extra de dedução inversa sobre os primeiros candidatos.
Gravar a codificação certa acaba o trabalho
O texto corrigido ainda tem de ser gravado numa codificação que o teu leitor reconheça. Os leitores no Windows costumam confiar no BOM para detetar a codificação, por isso UTF-8 com BOM é o que dá menos trabalho; hardware antigo e alguns leitores regionais querem GBK. Podes escolher UTF-8, UTF-8 (com BOM), GBK, Big5, Shift_JIS ou EUC-KR, e serás avisado se algo não couber (GBK não leva coreano).
Ferramentas e guias relacionadas
O percurso completo, em Como corrigir legendas com caracteres ilegíveis; o que um ficheiro SRT guarda realmente, em O que há dentro de um ficheiro SRT; a codificação está bem mas o conteúdo está sujo (marcas de água, anúncios, indicações para surdos), Limpeza de legendas.