Vídeo e legendas · Kit de ferramentas de legendas
Por que é vira é nas legendas: codificações de texto e como os navegadores as decodificam
· Como funciona
legendas codificação de caracteres processamento do navegador
Mojibake nas legendas quase sempre é uma incompatibilidade de codificação. Esta postagem explica como os bytes se tornam caracteres, por que UTF-8 e as páginas de código herdadas do Windows discordam e como uma ferramenta baseada em navegador decodifica um arquivo sem enviá-lo para qualquer lugar.
Os acentos são ruins, mas o momento é perfeito – como os problemas de codificação se apresentam
A revelação é que tudo, exceto os personagens, está bem. Os tempos são exatos, a ordem dos cue está correta, o arquivo é carregado e apenas as letras acentuadas estão erradas. Essa combinação exclui uma falha estrutural, porque um analisador que não pudesse ler o arquivo não teria produzido tempos corretos. O que deu errado aconteceu antes da análise, quando uma sequência de bytes foi transformada em uma sequência de caracteres.
Isso também explica por que a falha geralmente aparece no meio de um fluxo de trabalho e não na origem. O arquivo que parecia correto em um editor pode parecer errado no próximo, sem que nada tenha sido modificado. Nada o modificou; o segundo programa fez uma suposição diferente sobre o significado dos bytes.
Bytes versus caracteres — por que os mesmos bytes podem ser lidos como 'é' ou 'é' dependendo do decodificador
Um arquivo no disco é composto por bytes. Os caracteres só existem quando algo aplica uma codificação, que é uma tabela que mapeia sequências de bytes para caracteres. UTF-8 representa uma letra latina acentuada, como e-acute, como dois bytes. Windows-1252 representa a mesma letra que um único byte e dá aos dois bytes UTF-8 significados totalmente diferentes: o primeiro é um A maiúsculo com til e o segundo é um sinal de copyright.
Portanto, o familiar par distorcido não é corrupção. É uma leitura fiel e sem perdas dos bytes corretos na tabela errada. Cada byte sobreviveu; apenas a interpretação mudou. É por isso que o dano geralmente é reversível e é por isso que vale a pena identificar a direção da incompatibilidade, em vez de editar manualmente os caracteres visíveis.
UTF-8, Windows-1252 e amigos - as codificações dos arquivos de legenda realmente aparecem em
Os arquivos de legenda aparecem em um pequeno número de codificações. UTF-8 é o padrão moderno e o único que o WebVTT permite. Windows-1252 é comum em arquivos produzidos por ferramentas mais antigas da Europa Ocidental, e seu parente próximo ISO-8859-1 cobre grande parte do mesmo terreno. Arquivos de fontes da Europa Central, cirílica ou grega aparecem nas páginas de código correspondentes do Windows, e o material do Leste Asiático acrescenta vários outros.
Nenhuma dessas codificações registra sua própria identidade dentro do arquivo. Um arquivo SRT não contém nenhuma declaração da codificação usada para escrevê-lo, o que é a raiz de todo o problema: o leitor tem que decidir e não há nada oficial para ler.
A marca de ordem de bytes — uma dica útil para alguns jogadores e uma falha visível em outros
Uma marca de ordem de bytes é a única exceção parcial. É um caractere específico logo no início de um arquivo que, quando presente, sinaliza a codificação. Ele ajuda alguns jogadores e aparece em outros como um personagem perdido antes do primeiro índice de legenda, e é por isso que os arquivos que carregam um podem falhar em exatamente um programa e funcionar em qualquer outro lugar.
O analisador o remove antes de fazer qualquer outra coisa, porque uma marca deixada no lugar se liga ao primeiro número de índice e custa a primeira sugestão. A detecção de formato também foi escrita para tolerá-la, portanto, um arquivo WebVTT que começa com uma marca antes de seu cabeçalho ainda é reconhecido como WebVTT em vez de ser tratado como SRT.
Como um navegador decodifica um arquivo localmente — o TextDecoder API, e por que a detecção é uma suposição quando nenhuma codificação é declarada
Quando a ferramenta carrega um arquivo, ela chama o método de texto Arquivo API e esse método é especificado para decodificar como UTF-8. Não há parâmetro de codificação nem negociação. Um arquivo que realmente é UTF-8 é lido corretamente; um arquivo Windows-1252 contendo uma letra acentuada de byte único apresenta um byte que não pode iniciar uma sequência UTF-8 válida e o decodificador substitui um caractere de substituição em vez de adivinhar.
Vale a pena saber porque altera o sintoma. Ler um arquivo UTF-8 com uma tabela legada produz a familiar distorção de dois caracteres. Ler um arquivo legado como UTF-8 produz caracteres de substituição, os losangos pretos ou caixas vazias. A decodificação como algo diferente de UTF-8 requer nomear a codificação explicitamente por meio do decodificador do navegador API, e nomeá-la é a parte difícil: sem nenhuma declaração no arquivo, qualquer escolha automática é uma inferência a partir de padrões de bytes, que é uma suposição que geralmente está certa e ocasionalmente errada.
Exemplo resolvido: resgatando um arquivo Windows-1252 — identificando a codificação de origem e salvando-a novamente como UTF-8 antes da conversão
Para resgatar um arquivo legado, faça a conversão antes da legenda funcionar, e não depois. Abra-o em um editor que permita indicar a codificação em ambos os lados, peça para reabrir o arquivo como Windows-1252 e confirme se os caracteres acentuados aparecem corretamente. Se o fizerem, o palpite estava certo. Em seguida, salve o arquivo explicitamente como UTF-8.
Verifique em uma linha que você pode prever, e não no arquivo como um todo. Escolha uma sugestão contendo um sotaque que você sabe que deveria estar lá e verifique-o na saída convertida. Fazer isso primeiro significa que a ferramenta de legenda recebe um arquivo cujos bytes já correspondem à codificação que ela irá assumir, e a etapa de conversão não tem mais nada para dar errado.
O que isso não cobre – arquivos danificados por duas rodadas de conversão errada, onde os bytes originais já foram perdidos
Um arquivo que passou por duas conversões erradas é um problema diferente. Se um arquivo foi lido incorretamente e salvo nesse estado de leitura incorreta, os caracteres incorretos foram gravados como caracteres reais e os bytes originais não existem mais em nenhum lugar dele. Nesse ponto não há nada para reinterpretar, porque o arquivo agora contém genuinamente o texto distorcido.
Às vezes, esses casos são recuperáveis invertendo a sequência exata de codificações erradas, mas somente quando cada etapa é conhecida e nenhuma etapa perde informações. Um byte que se tornou um caractere de substituição desaparece permanentemente: a substituição é um único caractere que substitui um byte que o decodificador não pôde usar e não registra qual era o byte. A solução confiável é retornar ao arquivo original.
Conclusão: padronize em UTF-8 antes de converter - como o Subtitle Toolkit funciona em seu arquivo no navegador e por que a saída do WebVTT é UTF-8 por definição
Padronize em UTF-8 antes de converter qualquer coisa. O arquivo em si não contém nenhuma declaração de sua codificação, então cada programa que o abre está fazendo uma suposição, e a maneira de impedir que as suposições discordem é torná-las todas corretas. WebVTT elimina a ambiguidade por definição, uma vez que o formato requer UTF-8, que é uma razão prática para converter SRT em WebVTT para entrega na web.
A conversão é executada no arquivo na guia do navegador. Verifique o resultado em uma linha cujos acentos você pode prever, em vez de procurar por algo que pareça errado, porque é fácil assinar um arquivo com um punhado de palavras acentuadas em novecentas sugestões sem ter examinado a parte que falharia.