1. O problema

Já presenciei várias vezes uma cena que para mim estava pior que um Deja Vu. Alguém atende ao telefone e minutos depois grita “É aquele problema da acentuação de novo!”. Um problema que aparece freqüentemente assombrando desenvolvedores e clientes. Infelizmente na maioria dos casos os problemas são resolvidos da mesma forma como um encanador preguiçoso resolve um problema de encanamento: cola aqui, acolá, passa a fita e está pronto! O problema, às vezes, é pior do que se imagina, pois na maioria dos casos o site ou sistema funciona bem, com tudo rodando direitinho. Mas ninguém parou para pensar o que aconteceria se um árabe acessasse o mesmo. Ou um japonês… É muito comum entrarmos em sites de pessoas que moram do lado oposto do Greenwich e enxergar todos os caracteres estranhos e deformados, como se estivessem lhe xingando. Isso não é ruim apenas para usuários, mas para desenvolvedores. Se você desenvolve em PHP isso está mais próximo de você do que imagina. Já pensou em disponibilizar seu código para alguém do outro lado de mundo e ele não decifrar nada? Descubra, portanto, a solução Unicode.

2. Como funciona?

Tudo começou lá atrás, quando o Unix ainda estava sendo desenvolvido. Todos sabem que essa história se iniciou nos Estados Unidos, e sabem mais ainda que lá o que predomina é o bom e velho inglês. Ou seja, todas aquelas letras sem acento eram o que prevalecia no mundo da computação. Para cada uma daquelas letras havia um código – que ia do 32 ao 127. Mesmo antigos, esses códigos ainda existem. Os códigos anteriores ao 32 representam outros comandos como Return, indicação de começo de texto etc. – e todos esses códigos estão especificados em uma tabela conhecida como ASCII. Sendo assim o código 32 representa o espaço vazio, o 33 um ponto de exclamação (!), já o código 65 representa a letra A (maiúsculo) enquanto 97 representa a (minúsculo). Para armazenar esses códigos em um byte era necessário apenas 7 bits, o que deixava 1 bit sobrando. Problema: como um byte (ou 8 bits) consegue representar números que vão do 0 ao 255, muita gente se perguntou o que poderia ser feito com os códigos restantes (128 ao 255) da tabela ASCII. Muitos desenvolvedores resolveram fazer seu uso de forma desordenada, por exemplo, a IBM-PC lançou algo chamado de OEM (Original Equipment Manufacturer) e disponibilizava nele vários caracteres acentuados e para “desenhar linhas”, tudo beleza. Isso até os computadores começaram a ser vendidos fora dos Estados Unidos, fazendo com que surgisse todo tipo de caractere novo que se utilize do código 128 em diante. Sendo assim então surgiu o padrão ANSI, onde se convencionou que tudo abaixo do 128 permaneceria igual ao código estadunidense e, de 128 para cima, haveria um padrão de acordo com a localidade do usuário. Nem tudo são flores, pois aconteceu que em alguns países em que o alfabeto é imenso, não era possível representar todas a letras com apenas 8 bits. Algumas ações foram feitas para contornar esse problema, e tudo até que se resolveu… Até inventarem a Internet.

3. Unicode

Existem muita confusão a cerca do assunto: pessoas acham que Unicode é armazenar um caractere em 16 bits, o que é totalmente errado. O Unicode criou um conceito onde há algo chamado de code point. Assim todas as letras eram representadas por números em hexadecimal, que iam de 0 à 0x10FFFF (1.114.111 em decimal), e, com isso, mais caracteres poderiam ser incluídos e representados para qualquer computador em qualquer parte do mundo. Para isso, existem as codificações, ou seja, esses code point‘s precisam ser transportados em bytes e codificados de forma correta. Há vários tipos de codificação; cada uma com sua forma diferente, por exemplo, o UTF-8 utiliza-se de até 4 bytes (estritamente de 8 bits) para representar um só code point. Os primeiros caracteres (que vão do 0 ao 127) precisam apenas de 1 byte. Isso gerou uma melhor aceitação ao UTF-8, pois não haveria problema algum em codificar textos em inglês vindos do velho ASCII.

4. Não existe texto puro

Nada do que foi escrito até aqui vai ter valido a pena se o desenvolvedor não tiver em mente que texto puro não existe. Não existe aquele texto sem codificação, e ASCII não é texto puro. É necessário informar sempre qual a codificação usada. Os aplicativos que imprimem conteúdo precisam ter em seu cabeçalho qual a codificação usada, e os aplicativos que lêem precisam saber a codificação usada e ler corretamente. Em outras palavras, se você possui um site você precisa que seu site envie um cabeçalho informando qual o charset correto e o browser precisa entender e ler esse charset.

5. ISO-8859-1 x UTF-8

Apesar de problemas de codificação ocorrerem em todo o mundo, no Brasil temos um problema um pouco mais especifico. É comum ver por ai sites que possuem problemas de acentuação por conta de má decodificação. Muitos desenvolvedores ainda insistem em usar a codificação ISO-8859-1, que é uma das codificações ASCII antecedente ao Unicode, no qual os códigos acima de 128 representavam caracteres acentuados ou qualquer outro caractere latino. Para o fim desse problema, é necessário que os desenvolvedores saibam o que causa o problema e adotem qualquer padrão Unicode. Hoje o UTF-8 é o mais usado e possui maior suporte dentre as aplicações Web existentes.

6. Como solucionar meus problemas?

A primeira coisa a fazer é tentar adotar o Unicode em tudo que você usar. Busque no seu editor de texto ou IDE preferido como configurar para que ele trabalhe com UTF-8. Não adianta você escrever um arquivo em ISO-8859-1 enquanto tudo que for ler tenta interpretar UTF-8. É preciso também que os arquivos HTML informem ao navegador que o conteúdo a ser impresso é codificado em UTF-8. Para isso é necessário adicionar a todas suas páginas uma tag META no cabeçalho, como mostrado a baixo:

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

Quem trabalha com Web sabe que é comum problemas de codificação quando se fala em AJAX. Isso tanto na hora de salvar os dados quanto na hora de exibi-los. Tal fato acontece por que a codificação padrão usada para requisições assíncronas nos browsers é UTF-8. O PHP recebe os dados com os acentos normalmente, o problema maior é quando os dados são inseridos no banco de dados. Se o banco de dados está configurado para usar latin1 (que equivale a ISO-8859-1), então os dados vindos do AJAX, que não sofrem nenhum tipo de decodificação no PHP (veja a função utf8_decode), têm problemas na acentuação. Isso conseqüentemente implica na exibição desses dados que vêm do AJAX. Você não é obrigado, toda vida que for inserir dados no banco, decodificá-los. Isso porque toda sua aplicação agora está no padrão Unicode. Basta você dizer ao seu banco de dados que trabalhe assim também. Para quem trabalha com MySQL, infelizmente sua instalação padrão configura para latin1. Portanto, toda vez que uma conexão nova for feita ao MySQL pelo PHP, execute o seguinte comando como se estivesse fazendo um select:

SET NAMES ‘utf8′;

Ficaria assim no PHP:

mysql_query ( "SET NAMES ‘utf8′;" );

Assim o MySQL sabe que essa é a codificação que ele terá que usar tanto para retornar os dados como para gravá-los.

Considerações finais

Atenção: essas explicações são o mínimo que um desenvolvedor deve saber sobre codificação de arquivos. O padrão Unicode deve ser adotado para que problemas como esses sejam resolvidos. É importante lembrar que tanto como a aplicação que imprime, como a que lê o conteúdo precisar saber qual o tipo de codificação será usada. Por isso, vale ressaltar que no desenvolvimento do site/sistema é imprescindível que tudo esteja usando a mesma codificação, sobretudo o editor de texto, como a base de dados e os cabeçalhos enviados.

Não é fácil manter uma loja online. Para isso é necessário se preocupar com várias coisas como a forma como serão realizados pagamentos, as formas como será enviado o produto, controle de fraude, e o mais importante: a plataforma que gerenciará a loja.

Antes comércio eletrônico era apenas coisa de gente grande e para manter uma plataforma era necessário uma mão de obra grande e cara. Hoje não temos mais tanto este problema com o surgimento de várias plataformas de e-commerce open source, onde a que entre elas mais se destaca é o Magento.

O Magento é uma ferramenta Open Source desenvolvida pela Varien, empresa que age desde 2001 no segmento de e-commerce. Ele é escrito em PHP utilizando o banco de dado MySQL o que traz muitas vantagens, pois PHP é a linguagem de programação mais utilizada na Web, possuindo uma comunidade forte e ativa.

O Magento possui duas versões: a Community e a Enterprise. A primeira é a versão gratuita, disponibilizada para a comunidade sob a licensa OSL 3.0 que em resumo diz que o software pode ser distribuído desde que se mantenha a referência de seus autores. Já a segunda versão é paga e conta com recursos avançados que a versão Community não tem. Ela é recomendada para quem necessita de um suporte rápido(dado pela própria Varien) e de recursos avançados que lojas grandes possuem. Veja um comparativo das duas versões.

Veja algumas funcionalidades que o Magento possui em sua versão Community:

• Gerenciamento de Sites
  – É possivel gerenciar vários sites e várias lojas com apenas um Magento instalado.
  – Faça update da ferramente com apenas um clique.
• Gerenciamento de Catálogo
  – Importação e exportação de produtos do catálogo em lote
  – Suporte a preços especiais. Por exemplo, grupo de usuário X terá 10% de desconto ou levando 5 peças cada produto fica por Y reais.
• Navegação de produtos
  – Produtos relacionados
  – Venda cruzada
  – Venda casada
  – Tags
  – Avaliação dos usuários
  – Comparação de produtos
• Outros
  – Suporte à SEO
  – Relatórios
  – Criação de produtos baixaveis(downloadable products)
  – Integrado com Google Analytics
  – Relatório de vendas
  – Veja mais