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.

Códigos de língua e território para o galego

Exiſte muita confuſão e deſinformação ſobre a codificação das variantes do galego na Informática. A única regra reconhecida é gl para língua e gl_ES para a variante oficial da Espanha; e há quem proponha pt_GL, gl_GZ ou pt_GZ para a variante portuguesa.

O problema é que a segunda parte do código de dialeto não designa a variante em si, mas o território onde é falada; e não existem os territórios GL ou GZ. Exiſte, sim, gl_ES e gl_PT; mas meſmo ißo é controverſo, viſto que galego e português ſão dois dialetos da meſma língua, em pé de igualdade com o português do Braſil. Talvez a ſolução mais correta foße pt_ES para o galego como eſcrito na Galícia eſpanhola, mas ißo deixaria o galego como eſcrito em Portugal ſem um código fácil, exigindo algo como pt_PT@gl.

Ißo torna o galaico‐português uma língua sui generis, com quatro codificações para três principais dialetos diferentes: gl_ES, gl_PT, pt_BR, pt_PT.