Codificação de caracteres

Executar código Lua a partir de arquivos-fonte é muito conveniente. Porém isso nos traz uma questão a mais para prestar atenção: a codificação dos caracteres utilizada no arquivo.

Vamos lembrar que em computação, tudo são conjuntos de bits (zeros e uns), e uma máquina não possui qualquer noção de caracteres. Portanto, nosso modo de representar caracteres em uma máquina é por meio de tabelas de conversão que determinam que cada caractere corresponde a um diferente conjunto de bits.

Por exemplo, a tabela ASCII é um padrão bastante popular e amplamente usada em sistemas operacionais. Ela determina, por exemplo, que o caractere a (minúsculo) seja representado pelo número 97 (que por sua vez em binário é representado por 1100001).

A tabela ASCII é um recurso relativamente simples, porém também possui algumas limitações: ela foi pensada para a língua inglesa. Isso significa, por exemplo, que não contempla alfabetos de outros idiomas, e nem mesmo oferece suporte a acentuação, ou cedilha, por exemplo (o que nos afeta).

Por este motivo, existem também outras tabelas de conversão, que oferecem suporte a convenções diferentes da tabela ASCII. O padrão Unicode, por exemplo, é muito mais sofisticado e possui suporte a virtualmente tudo o que existe em termos de caracteres.

No entanto, o Unicode não determina como a máquina fará a representação dos caracteres, ele apenas associa cada caractere ao que chamamos de ponto de código (uma representação única para cada caractere), e então existem diferentes esquemas de codificação que determinam como um ponto de código é traduzido para bits, sendo o UTF-8 um desses esquemas (e um dos mais populares).

Eu sei que esse é um tema complexo, mas o que quero que perceba é que existem diferentes maneiras de representar o texto na forma de bits, e isso afeta nossos arquivos, já que eles são compostos por caracteres.

Dependendo do editor de texto que utilizar, ele poderá ter alguma convenção de qual codificação de texto utilizar por padrão, e muitos permitem que você troque ou converta o arquivo para uma codificação diferente (o que é um recurso bastante útil).

Como tudo isso afeta Lua?

Bem, se você editar um arquivo-fonte usando UTF-8, por exemplo, e depois tentar executar esse arquivo em um terminal de comandos sem suporte a Unicode, poderá ver alguns caracteres estranhos na tela, ou até ter problemas de execução.

Isso pode ocorrer também se você editar o arquivo na sua máquina e transferí-lo para outra pessoa abrir em outro editor, com uma codificação diferente.

Por este motivo, é boa prática se restringir aos caracteres suportados pela tabela ASCII nos arquivos-fonte, e quando houver necessidade de manipulação de texto (em português, por exemplo), este texto deverá constar em arquivos separados da lógica principal do programa.

Isso é especialmente importante quando estiver criando programas que serão compartilhados entre usuários diferentes, em máquinas diferentes, ou que deverão oferecer suporte a idiomas diferentes.

Para suporte a múltiplos idiomas, podemos separar as partes específicas de idiomas distintos em arquivos identificados pelo idioma em questão (como pt_BR para português brasileiro, por exemplo), e convencionar o esquema de codificação utilizado para salvar esses arquivos.

Novamente afirmo que este é um tópico complexo e seria muita pretensão tentar oferecer uma receita simples que sirva para tudo. O que tento fazer aqui é alertar para a necessidade de prestar atenção à codificação em situações que possam envolver múltiplos usuários ou que eventualmente aprsentem “caracteres estranhos” na tela.

Isto inclusive não é uma limitação de Lua. No geral, linguagens de programação são compostas por caracteres, escritos em um arquivo-fonte, que estará sujeito a esse tipo de preocupação.