Olá povo!
Dando início ao meu novo calendário de postagens (pretendo publicar alguma coisa aqui uma vez por semana, pelo menos), dois temas que quero deixar bem evidente neste blog são: Desenvolvimento Web e Software Livre. Como esses caminhos vão se cruzar constantemente, nada melhor que começar o assunto falando do Sistema Operacional que na minha opinião é o mais adequado para Desenvolvimento Web com ferramentas livres: o Ubuntu Linux. Leia mais…
Trabalhar com UTF-8 no PHP pode dar algumas dores de cabeça pra quem é novo, e até mesmo para alguns mais velhinhos… O PHP trabalha por padrão com ISO-8859-1, que são os caracteres latinos que estamos acostumados. Entretanto, o UTF-8 tem uma abrangência maior de caracteres e o ideal seria que nos acostumássemos a usar este charset nas páginas.
Este pequeno tutorial tem como objetivo deixar bem claro quais os passos a se tomar para construir uma aplicação totalmente baseada no charset UTF-8, desde as páginas HTML, passando pelo PHP e por fim no MySQL.
Antes de tudo, aconselho que aprenda a criar os seus arquivos utilizando o UTF-8 sem BOM, que evitará dores de cabeça futuras quando estiver trabalhando com cookies, sessões e headers.
O segundo passo é definir, no PHP que o charset dos arquivos que serão gerados terão a codificação UTF-8, com o seguinte código:
<?php
ini_set('default_charset','UTF-8');
?>
Só setar o charset no PHP não adianta muito, pois alguns navegadores usam a codificação padrão da região do usuário, a não ser que o seguinte código esteja entre as tags <head> e </head>:
<meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
Com isso, você já pode trabalhar tranquilamente com UTF-8 e PHP sem ter problemas com os caracteres.
Alguns cuidados são necessários quando for trabalhar com o MySQL, entretanto. Vou ensinar como se faz pelo PHPMyAdmin, que acredito que todos que começaram a trabalhar com MySQL estão acostumados.
Em primeiro lugar, ao criar o seu banco de dados, já crie usando o collation utf8_general_ci. Se o banco de dados já tiver um collation definido, não é necessário definir o collation das tabelas, pois elas herdarão o do banco. Mas mesmo assim é bom especificar o charset e collation de cada tabela. Como? Assim:
CREATE TABLE Clientes (
id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
nome VARCHAR(60) NOT NULL,
PRIMARY KEY(id)
)
TYPE=InnoDB CHARACTER SET utf8 COLLATE utf8_general_ci;
Ok. Nossa tabela está trabalhando com UTF-8 agora. Podemos começar a programar e relaxar porque nossos problemas com charset estão resolvidos, certo?
A resposta é não.
Se você continuar a programar com o sistema assim, os dados do banco serão inseridos e consultados de maneira correta, mas você vai perceber problemas quando tentar fazer buscas com palavras acentuadas insensível a maiúsculas, por exemplo: Água, água e agua serão palavras totalmente diferentes, sem contar que a ordenação de resultados com palavras que começam com letras acentuadas sairá bem bagunçada, coma letra Ó vindo antes de B, por exemplo.
Esse é o problema que eu tive e que demorei eras pra descobrir. O banco estava OK, o PHP também, o mesmo com as páginas HTML… e quando eu inseria algum dado pelo PHPMyAdmin, este era inserido corretamente, o que significava que o problema não era no banco e sim na aplicação.
Depois de meses na verdade foram apenas algumas horas de pesquisa, desconfiei que havia algo na conexão com o MySQL que estava dando esse problema. Fui fuçar no Manual do PHP e encontrei a seguinte solução:
<?php
ini_set('default_charset','UTF-8'); // Para o charset das páginas e
mysql_set_charset('utf8'); // para a conexão com o MySQL
?>
Com isso todos os meus problemas foram resolvidos. Na verdade não, pois tive que alterar todos os campos acentuados da tabela…
Dá para usar a função mysql_client_encoding para identificar o charset da conexão com o MySQL, mas não acho necessário pra quem quer trabalhar diretamente com UTF-8 e não com vários charsets.
Acho que por enquanto é só. Até o próximo semestre! Brincadeira…
Acabei de colocar no ar a versão 1.1 do EmotiKut. A melhoria desta versão é que ele lista sempre os arquivos mais novos por primeiro. Assim sendo, quando alguém enviar um emoticon, ficará mais fácil de achar. Confira! (Senha "123")
Quando comecei a programar em PHP, não sabia muita coisa sobre codificações de caracteres e tudo mais. Aliás, não sei muita coisa até agora. Como todo bom usuário de Windows, tinha tudo pronto ali na minha frente e tudo rodava direitinho, até enviar os arquivos para um servidor Linux…
O grande problema começou quando comecei a usar por padrão a codificação Unicode, e a trabalhar direto com UTF-8. Logo na na primeira vez que chamei session_start(), apareceu a seguinte mensagem de erro:
Warning: session_start() [function.session-start]: Cannot send session cookie – headers already sent by (output started at /var/www/teste.php:1) in /var/www/teste.php on line 2
O curioso de tudo é que o session_start() só retorna erro se alguma coisa tiver sido enviada para o cliente antes de chamar essa função, mas vamos dar uma olhada no código:
<?php
session_start();
?>
Observe bem, não existe nada antes do código. Mas será que não mesmo? Sabemos que o PHP trabalha nativamente com a codificação ISO-8859-1 e que até o momento não tem um suporte muito bom para Unicode (UTF-8). Então através do Quanta, vamos “emular” o arquivo como se ele estivesse sendo visto pelo PHP, transformando a codificação dos caracteres para ISO-8859-1 através do comando Tools - Encoding - Western European:
<?php
session_start();
?>
Bingo! Já descobrimos o que está sendo enviado para o navegador. Aqueles caracteres estranhos  são os responsáveis pelo problema. Mas… o que são eles?
Através de algumas pesquisas no Google, descobri que esses caracteres são uma espécie de assinatura do Unicode, chamada BOM, que é onde quero chegar e a solução de todos os nossos problemas envolvendo UTF-8 e PHP.
De acordo com esta página, a BOM consiste numa sequencia de caracteres no início dos dados recebidos pelo navegador/agente, a qual define a ordem dos bytes e a forma de codificação. (minha tradução mal-feita).
Segundo a mesma página, não é necessário utilizar a BOM quando se estiver codificando em UTF-8, afinal ele é mais indicado para UTF-16 e UTF-32. O UTF-8 pode ou não usar BOM. No nosso caso, para resolver esse problema com o PHP, devemos programar em arquivos UTF-8 sem BOM. Como fazer isso?
Bom, o Quanta, pelo que eu sei, já faz esse tipo de conversão automaticamente. Desde que migrei para o Ubuntu, só tenho utilizado ele e não tenho tido problemas com codificação de caracteres. Se você utiliza o Windows, recomendo um ótimo editor que eu utilizava quando desenvolvia no Windows: o Notepad++. Existem outros, é claro, e cada desenvolvedor escolhe o que é melhor para si. Não tenho certeza, mas parece que o Dreamweaver tem a opção de salvar sem BOM, mas quero me ater a indicar software livre por aqui.
Para finalizar, quero indicar uma leitura interessante sobre codificação UTF-8, que encontrei quando procurava a solução desse problema. Um artigo que se chama O Mínimo Absoluto Que Todo Desenvolvedor de Software Absolutamente, Positivamente Precisa Saber Sobre Unicode e Conjuntos de Caracteres (Sem Desculpas!). Boa leitura!