Como Resolver Problemas de Acentuações em seu Site

De Task Wiki
Ir para: navegação, pesquisa

O que fazer quando meu site exibe caracteres distorcidos ao invés de caracteres acentuados?

Um exemplo muito comum:


Ao invés de Apresentação, ele exibe Apresenta��o ou Apresentação.

No primeiro caso (Apresenta��o), sua página em ISO-8859-1 está obtendo a palavra Apresentação armazenada em UTF-8 da origem, seja ela do banco de dados ou de um XML, txt etc.

Já o segundo caso (Apresenta§Ã£o) é a sua página em UTF-8 exibindo a palavra Apresentação armazenada em ISO-8859-1 da origem.

Para que ocorra a exibição correta, deve-se armazenar novamente os dados com a codificação correta (o que é muito trabalhoso dependendo da quantidade de dados) ou trocar a codificação de exibição de seu site.

Para trocar a exibição, o cabeçalho HTML deverá estar como:

Para ISO-8859-1:
<source lang="php">
<html>
<head>
<title>Minha pagina</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</source>

Para UTF-8:
<source lang="php">
<html>
<head>
<title>Minha pagina</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</source>

Observação sobre a forma de salvar o arquivo: Mesmo que você especifique um dos cabeçalhos acima ou com o charset que deseja, o arquivo deve ser salvo na codificação equivalente ao charset especificado. Por exemplo, se você utiliza <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> , o arquivo deve ser salvo na codificação "ISO-8859-1, ou Latin1, ou Europeu Ocidental ISO (ou mesmo ANSI caso você use o Bloco de Notas do Windows)", mas se o charset for UTF-8, a codificação deverá ser Unicode / UTF-8 também. Lembrando que essa opção está disponível no editor de texto utilizado para editar o arquivo (notepad, notepad ++, gedit, textmate, textpad, vi, vim e vários outros).

Observação sobre o banco de dados: Não é sempre os collations ou encoding das bases o culpado. No caso do MySQL e do PostgreSQL, não haverá nenhum problema de exibição do caractere, mas na hora da busca ele pode não saber o que é o caractere acentuado. O SQL Server já é mais passível de exibir erros conforme o collation especificado.

Observação crítica: Mesmo que você especifique um dos cabeçalhos acima ou com o charset/encoding/collation que deseja, o usuário pode forçar um outro encoding clicando no menu Exibir > Codificação > (encoding que ele quiser) do navegador dele, neste caso, o navegador enviará os dados da forma como o usuário determinou. Uma das maneiras de se prevenir contra este tipo de ação é criar uma função que determine quais são os caracteres permitidos e substitua os demais por espaço, nulo, sublinhado, asterisco ou outro de sua preferência.

Sugestão de caracteres permitidos:
Números...............: 0123456789
Letras maiúsculas.....: ABCDEFGHIJKLMNOPQRSTUVWXYZ
Letras minúsculas.....: abcdefghijklmnopqrstuvwxyz
Caracteres especiais..: "'!@#$%&*()_-+={[}]|\<,>.:;?/ (o espaço é um caractere também)

E para ser usado com cautela:
Caracteres acentuados.: ÁÉÍÓÚ áéíóú ÂÊÔ âêô Àà Üü Çç Ññ ÃÕ ãõ

Nossa sugestão: Utilizar Códigos HTML para caracteres acentuados e Códigos HTML para caracteres especiais. O PHP (linguagem de programação) possui uma função que faz essa conversão para você. Veja htmlentities() no site oficial do PHP.

Importante: A criação da função é de responsabilidade do desenvolvedor e variará conforme a linguagem de programação utilizada no site.

No Fórum da Locaweb já existem desenvolvedores que estão compartilhando as suas soluções:
[Linguagens open-source][Linguagens Microsoft]

Por que são só os caracteres acentuados que estão sujeitos a terem problemas na exibição?
Não poderia estar acontecendo com os demais também?

Um caractere é armazenado, seja em arquivo ou em buffer, codificados.

Quando vemos um 'A' (maiúsculo), na verdade, estamos vendo o caractere de código 65 (0x41).
Um 'a' (minúsculo) não é um 'A' (maiúsculo), o código deste caractere é 97 (0x61).

Cada caractere tem o seu código, e todos os encodings por padrão são iguais até o caractere de número 127 (0x7F), a partir do caractere 128 (0x80) cada um possui suas particularidades.

O código do caractere 'Á' (maiúsculo com acento agudo) é diferente:
É 193 (0xC1) no encoding ISO-8859-1.
É 50049 (0xC381) no encoding UTF-8.

Então é a partir daí que começam os erros de exibição de caracteres, veja:

O caractere 193 (0xC1) está armazenado no arquivo ou no banco de dados:
Se a página for exibida em ISO-8859-1, veremos um 'Á', mas se for exibida em UTF-8, veremos um '�'.

O caractere 50049 (0xC381) está armazenado no arquivo ou no banco de dados:
Se a página for exibida em ISO-8859-1, veremos 'Á', mas se for exibida em UTF-8, veremos um 'Á'.

Afinal, qual a diferença entre os encodings?
Qual deles é o que eu devo utilizar?

A diferença do ISO-8859-1 e do UTF-8 é que um suporta até 256 caracteres (0 a 255, ou 0x00 a 0xFF) e o outro suporta até 65.536 caracteres (0 a 65535, ou 0x0000 a 0xFFFF).

O que leva alguns desenvolvedores a utilizarem o ISO-8859-1 é a economia de espaço, tráfego de rede e velocidade na exibição no caso de grandes quantidades de dados, pois um caractere UTF-8 chega a ter o dobro do tamanho de um caractere ISO-8859-1, em compensação, o UTF-8 suporta a maioria das letras, números e outros caracteres dos diversos países do mundo (se não forem todos), o que acaba fazendo do UTF-8 um padrão internacional.

Entretando, é aconselhável ser utilizado o UTF-8 somente quando se prevê que seu sistema lidará com textos em idiomas distintos, como japonês, chinês, árabe, russo, grego e outros cujos caracteres não são de origem romana, do contrário, você pode usar o ISO-8859-1, pois ele suporta os idiomas de origem latina (português, espanhol, francês e italiano) e também inglês, alemão, dinamarquês e dos demais países da Europa Ocidental.

Leitura recomendada

Existe um artigo bem completo escrito por Joel Spolsky que explica os conjuntos de caracteres e os problemas de acentuação que eles podem causar:

Disponível em “https://wiki.task.com.br/index.php?title=Como_Resolver_Problemas_de_Acentuações_em_seu_Site&oldid=3817”