paulo1205
(usa Ubuntu)
Enviado em 02/03/2017 - 20:00h
Encoding indica qual a representação que cada caráter deve ter. O mesmo caráter pode ser codificado com diferentes representações binárias. O caráter “ã“, por exemplo, ocupa a posição 225 na tabela de caracteres reconhecidos pelo Unicode, pode ser representado com um único byte de oito bits (desde que você não use os caracteres do Unicode com índice de 256 em diante), com um byte de valor 225. Com a codificação UTF-8 (que utiliza um byte para caracteres com índice entre 0 e 127, dois bytes para índices de 128 a 2047, três bytes para os de índice 2048 a 65535, e quatro bytes para os caracteres com índice 65536 em diante), ele seria composto pelos bytes 195 e 163. Se você preferir usar palavras de 16 bits em lugar de bytes de 8 bits, poderia querer usar UTF-16 (que utiliza uma palavra para os caracteres com índices de 0 a 55295 e 57344 a 65535, e duas palavras para os demais caracteres), e o nosso “
ã” seria representado pelo valor inteiro de 16 bits 225. No entanto, ao gravar tais dados em arquivos, que são medidos em bytes de 8 bits, teria ainda de escolher se a semi-palavra de oito bits mais significativa viria primeiro (UTF-16 BE) ou depois (UTF-16 LE) da semi-palavra menos significativa). Existe também UTF-32, que usa sempre 32 bits para qualquer caráter.
Se o UTF-32 é o que tem menos limitações e complicações de conversão, então o melhor seria usá-lo sempre, não?
Não necessariamente, porque se a maioria do texto que você tiver de representar usar apenas caracteres nas primeiras posições da tabela de símbolos, você gastaria muito mais espaço em disco e em memória usando quatro bytes em lugares em que um ou dois teriam sido suficientes (e os demais guardam apenas bits sempre zerados). Além disso, provavelmente a maioria dos seus clientes, das aplicações do mundo real, feitas em Java, .NET, C++ etc., utilizaria UTF-8, UTF-16 ou mesmo alguma representação exclusivamente com oito bits (como Windows-1252 ou ISO-8859-*), e você acabaria tendo de sofrer conversões entre representações de qualquer maneira.
LC_CTYPE diz respeito a quais atributos cada caráter deve possuir numa detrminada língua e/ou representação. Por exemplo, se você estiver usando uma língua europeia, os únicos caracteres que você entende que podem formar um número serão aqueles no conjunto “
0123456789”. Em outras palavras, apenas os caracteres desse conjunto terão o atributo “algarismo” ligado quando você avaliar tais caracteres, de acordo com os critérios do seu idioma. No entanto, se você estivesse usando um idioma asiático, possivelmente gostaria de considerar como algarismos também (ou talvez exclusivamente) os caracteres usados para escrever números nesse idioma. Outros atributos incluem se o caráter é ou não uma letra, se é maiúsculo, minúsculo ou se essa distinção não existe, se é um caráter de pontuação, espaçamento ou controle, entre outros. Além disso, diz respeito também a LC_CTYPE eventuais regras para conversão entre maiúsculas e minúsculas e transliterações.
LC_COLLATE diz respeito a critérios de ordenação e/ou equivalências. Em Português, por exemplo, considera-se que letras com marcas diacríticas (acentos, til, cedilha etc.) têm o mesmo valor que a letra base, que eventualmente recebeu uma marca a mais. Nessa língua, “roca” e “roça” aparecem, no dicionário, ambas à frente antes de “rocambole” ou de “roceiro”. Outros idiomas podem ter outras regras. Por exemplo, em Espanhol, as letras “n” e “ñ” são consideradas distintas, e o alfabeto tem oficialmente 27 letras, e, num dicionário, “
nunca” vem antes de “
ñandú”, que vem antes de “
obra” (e até 1994, os dígrafos
ch e
ll também eram tratados de forma semelhante: com “
chavo” aparecendo no dicionário após “
cuyo”, e “
llama” após “
luz” -- felizmente isso mudou!). Outras línguas europeias também têm regras semelhantes (por exemplo, em sueco, as letras “å”, “ä” e “ö” aparecem após o “z” no alfabeto, totalizando 29 letras; em holandês, “
ij” pode, dependendo do contexto, ser tratado como “i” seguido de “j”, ou como substituto ou equivalente a “y”). No que diz respeito a transliteração, em Português pode ser aceitável reescrever “açúcar” como “
acucar” numa representação que não disponha dos caracteres acentuados mas possua todos os caracteres base. Em outros contextos e/ou em outros idiomas, pode ser preferível dizer que a transliteração não é possível.
--------------------
Muitos aspectos de localização e de internacionalização se confundem. E a coisa fica ainda mais confusa se você levar aspectos culturais que vão além da língua escrita, pura e simplesmente.
