Por que os navegadores precisam receber a codificação de um arquivo?

Question

De acordo com esta documentação (entre muitos outros lugares, tenho certeza), é É muito importante declarar a codificação de caracteres usada em um determinado arquivo para o navegador.

A maioria dos editores de texto (e programas como file ) parecem detectar automaticamente a codificação de caracteres de um arquivo sem problemas.

Por que os navegadores precisam dessas informações declaradas no arquivo?

Eles parecem adivinhar muito bem quando nenhuma codificação é declarada, mas muitas vezes ainda parecem falhar em caracteres "especiais".

    

Answer 1

Eles não precisam , mas é recomendado dar essa informação, já que adivinhar o charset errado pode

• resulta em uma página ilegível (apenas parcial ou completamente em toda a página)
• introduzem possíveis vulnerabilidades no sistema

"Não há nada como texto simples."

Antes do advento do Unicode, os computadores usam várias páginas de código e esquemas de codificação para gravar scripts diferentes. Infelizmente, o ruim é que nenhuma informação de codificação está embutida no arquivo. Essa situação não desaparecerá e conjuntos de caracteres e codificações diferentes continuarão a existir. Um editor de texto terá que abrir o arquivo de texto com a codificação apropriada para obter os pontos de código reais e, em seguida, processá-lo no conjunto de caracteres correto. No entanto, como eles não têm ideia de em que codificação o arquivo está, eles precisam adivinhar ele usando heurística

This algorithm usually involves statistical analysis of byte patterns, like frequency distribution of trigraphs of various languages encoded in each code page that will be detected; such statistical analysis can also be used to perform language detection.

https://en.wikipedia.org/wiki/Charset_detection

O Firefox usa os Detectores do Mozset Charset . A forma como funciona é explicada aqui e você também pode alterar suas preferências heurísticas . O Chrome usou anteriormente o detector de UTI , mas mudou para CED quase 2 anos atrás

Na maioria das vezes eles adivinham as codificações corretamente, mas os algoritmos funcionam melhor para as palavras, de modo que podem falhar em muitos símbolos. As codificações Unicode são geralmente mais fáceis de adivinhar devido à maneira como o UTF-8/16/32 é codificado. Você também pode forçar uma codificação colocando uma BOM no início.

Mas no geral não há como adivinhar todas as codificações e charset de forma confiável, já que o mesmo fluxo de bytes pode ser válido em várias codificações ao mesmo tempo. No final, eles podem cometer erros assim , porque é só adivinhar mesmo assim! É também assim que o famoso Bush escondeu os fatos do erro ocorrido no Bloco de Notas anterior à Vista, quando a API IsTextUnicode pensa que uma O arquivo de texto ASCII simples é um arquivo UTF-16LE, pois o conteúdo do arquivo também parece OK em UTF-16LE.

A má adivinhação também introduz uma vulnerabilidade ao sistema como a exploração do Google UTF-7 na resposta de David. Como resultado, a codificação deve ser sempre explicitamente declarada.

O bom é que a maioria dos charsets concordam uns com os outros sobre os primeiros 127 pontos de código, então os navegadores podem apenas ler os primeiros bytes do cabeçalho com o charset padrão (ou qualquer apropriado) até ver a opção charset dentro de meta tag. Se o conjunto de caracteres estiver errado, ele reabrirá o arquivo usando o conjunto de caracteres fornecido no conteúdo do arquivo.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

Leia mais:

• O Mínimo Absoluto de Joel on Software Todo Desenvolvedor de Software Absolutamente, Positivamente Deve Saber Sobre Unicode e Conjuntos de Caracteres (Sem desculpas!)
• Unicode, UTF-8 e codificações de caracteres: O que todos desenvolvedor deve saber

Answer 2

Referência UTF-8: O segredo da codificação de caracteres

No embedded encoding

If this is the case, you'll want to add in the appropriate META tag to your website. It's as simple as copy-pasting the code snippet above and replacing UTF-8 with whatever is the mime name of your real encoding.

For all those skeptics out there, there is a very good reason why the character encoding should be explicitly stated. When the browser isn't told what the character encoding of a text is, it has to guess: and sometimes the guess is wrong. Hackers can manipulate this guess in order to slip XSS past filters and then fool the browser into executing it as active code. A great example of this is the Google UTF-7 exploit.

You might be able to get away with not specifying a character encoding with the META tag as long as your webserver sends the right Content-Type header, but why risk it? Besides, if the user downloads the HTML file, there is no longer any webserver to define the character encoding.