Administração de dados: codificação de caracteres
Codificação de caracteres. Não deve haver assunto mais insistente na lista brasileira de discussões. ASCII, Latin1 e UTF-8 estão sempre em discussão. Mas alguém pode dizer: ‘Isso não é um problema de administração de dados, mas físico! É uma questão do que é mais eficiente!’ Mas não — a codificação de caracteres limita o que pode ser codificado, e portanto um administrador de dados, sempre que possível, vai querer usar o que for mais flexível, que não estabeleça limites arbitrários.
Ainda tem gente brigando com bases de dados em ASCII. Tipicamente, porque instalou um sistema operacional sem configurar a língua, ficando com as configurações por omissão, ou seja, o local ‘C’. O problema é que o ASCII é 7 bits, portanto codifica apenas 128 caracteres — o que, devido a caracteres de controle, não imprimíveis, pontuação e acentuação para línguas mais votadas, não cobre todos os caracteres da língua portuguesa. Ou seja, é verboten!
A opinião mais corrente parece ser a de que ‘não se precisa mais que Latin1 no Brasil’. Errado! Latin1, cujo nome correto é ISO 8859-1, está obsoleto: por exemplo, não consegue codificar €, o símbolo do Euro. Ou seja, proibido também.
Então, dirão, vamos de Latin9, ISO 8859-15. Sim, é uma escolha razoável. Mas imagine que chegue um chinês maluco, goste de seu programa, e decida levá-lo para a China. Pena, você acabou de perder o negócio de sua vida. E se teu chefe decidir expandir negócios para a Índia, e descobrir que você criou um sistema que só serve para o Ocidente? Pena, você vai ter de procurar outro emprego.
Isso nos deixa com Unicode, do qual a escolha mais razoável no Ocidente é o UTF-8. Sim, UTF-16 é mais consistente, mas além de ser o único suportado pelo PostgreSQL, ocupa apenas um byte para os caracteres ocidentais, que costumam ser a grande maioria, exceto para aplicações estritamente locais do Oriente. E, se você tem algum problema em usar UTF-8… bom, ele suporta qualquer codificação, então certamente é um problema estritamente de aplicação, configuração, até um possível defeito no PostgreSQL ou alguma biblioteca relacionada, mas certamente não é um problema do UTF-8 em si.
Resumindo, a menos que você precise de algo muito, muito específico mesmo, faça-se um favor — Unicode na cabeça.
Postagens
4 commentaires:
e pra converter um banco de dados que hoje está em LATIN1 para UTF-8 é muito complicado? existe alguma ferramenta ou comandos ou maneira de fazer isso?
alguem sabe ou já teve que fazer?
A única maneira que conheço é pg_dumpall e restaurar. Mas pergunte na lista pgbr-geral, alguém lá já deve ter feito.
Legal Leandro,
Eu tive que aprender isso na prática. Quando cheguei na empresa onde trabalho atualmente o banco tinha sido criado sem análise alguma em ASCII e após alguma pesquisa e muita briga com o pessoal do desenvolvimento, eu consegui convertê-lo para ISO-8859-1.
Agora eu estou para converter para UTF-8. Não fiz de primeira pois nos testes que havia realizado tive problemas com algumas aplicações, mas é meu próximo passo. É sempre bom termos artigos como estes em nossos blogs para conscientizar os aspirantes a administradores de postgreSQL a começarem do jeito certo.
Quanto a questão do Fábio que acabou ficando meio incompleta, a resposta se resume aos comandos: pg_dumpall, já citado, e o comando iconv.
Eu postei em meu blog sobre esse comando, no final do mês passado (http://www.welrbraga.eti.br/blog/?p=66). Talvez um tutorial incluindo ambos os comandos em algum lugar de boa visibilidade para iniciantes em PostgreSQL com ambos os comandos mostrando o caminho completo fosse de bom grado.
Somente repare que, por você ter usado ISO 8559-1 em vez do -15, pode ter algum problema com caracteres como o € (Euro). Mas deve dar para contornar facilmente.
Postar um comentário