Encoding , lc_collate e lc_ctype

1. Encoding , lc_collate e lc_ctype

Wa
LaraW

(usa Outra)

Enviado em 02/03/2017 - 15:13h

Boa Tarde, gostaria de saber exatamente para que serve essas opções ao criar um banco de dados:
Encoding , lc_collate e lc_ctype.

Gostaria de saber também, se posso recriar um mesmo banco, com essas opções diferentes?

Obrigada!!!


  


2. Re: Encoding , lc_collate e lc_ctype

Guilherme
Ghost_Shell

(usa Arch Linux)

Enviado em 02/03/2017 - 16:17h

LaraW escreveu:

Boa Tarde, gostaria de saber exatamente para que serve essas opções ao criar um banco de dados:
Encoding , lc_collate e lc_ctype.

Gostaria de saber também, se posso recriar um mesmo banco, com essas opções diferentes?

Obrigada!!!


Vê se esse artigo lhe ajuda:

https://www.postgresql.org/docs/9.3/static/locale.html

Keep it simple stupid!


3. Re: Encoding , lc_collate e lc_ctype

Wa
LaraW

(usa Outra)

Enviado em 02/03/2017 - 16:42h

Havia lido esse artigo e não entendi muito bem.
Pesquisei muito na internet e vi muitas explicações de como mudar essas opções, mas a maioria não explica de forma prática pra que exatamente elas servem. Obviamente tenho uma noção do que são, mas como tenho um banco de muita importância aqui na empresa e preciso fazer certas modificações nele, gostaria de ter certeza em que essas opções influenciam
Se tiver como me explicar da forma como você entende ficarei grata!




4. Re: Encoding , lc_collate e lc_ctype

Guilherme
Ghost_Shell

(usa Arch Linux)

Enviado em 02/03/2017 - 16:54h

LaraW escreveu:

Havia lido esse artigo e não entendi muito bem.
Pesquisei muito na internet e vi muitas explicações de como mudar essas opções, mas a maioria não explica de forma prática pra que exatamente elas servem. Obviamente tenho uma noção do que são, mas como tenho um banco de muita importância aqui na empresa e preciso fazer certas modificações nele, gostaria de ter certeza em que essas opções influenciam
Se tiver como me explicar da forma como você entende ficarei grata!



É como no linux, vai definir o locale. O idioma, formato data e hora essas coisas. Você só precisa alterar o valor dessas variáveis se você estiver tendo problema nesse sentido. Vou deixar a configuração do locale do archlinux para você dar uma olhada é bem completo.

Segue o link:

https://wiki.archlinux.org/index.php/locale

Para você ter uma saída prática sobre o assunto, abre um terminal e digita: locale

Você vai ver todas as variáveis lá com o seu devido valor:


A saída do meu locale:


LANG=pt_BR.UTF-8
LC_CTYPE=pt_BR.UTF-8
LC_NUMERIC="pt_BR.UTF-8"
LC_TIME="pt_BR.UTF-8"
LC_COLLATE="pt_BR.UTF-8"
LC_MONETARY="pt_BR.UTF-8"
LC_MESSAGES="pt_BR.UTF-8"
LC_PAPER="pt_BR.UTF-8"
LC_NAME="pt_BR.UTF-8"
LC_ADDRESS="pt_BR.UTF-8"
LC_TELEPHONE="pt_BR.UTF-8"
LC_MEASUREMENT="pt_BR.UTF-8"
LC_IDENTIFICATION="pt_BR.UTF-8"
LC_ALL=




Keep it simple stupid!


5. Re: Encoding , lc_collate e lc_ctype

Wa
LaraW

(usa Outra)

Enviado em 02/03/2017 - 17:02h

Você usa no Linux? Por que eu uso no Windows e digitei locale e não deu certo, não reconheceu o comando.

Obrigada!!!





6. Re: Encoding , lc_collate e lc_ctype

Wa
LaraW

(usa Outra)

Enviado em 02/03/2017 - 17:07h

Outra dúvida, o encoding é a mesma coisa?


7. Re: Encoding , lc_collate e lc_ctype

Guilherme
Ghost_Shell

(usa Arch Linux)

Enviado em 02/03/2017 - 17:19h

LaraW escreveu:

Outra dúvida, o encoding é a mesma coisa?


Todas essas váriaveis acima são variáveis de ambiente. O encode é para setar os caracteres. No caso eu estou usando o UTF-8, Você pode usar o iso. É como no html o charset UTF-8. Mas como eu disse se tudo estiver funcionando, o idioma estiver certo, sem problema com caracteres, todos os formatos hora, data , moeda. Não tem porque você alterar.

Keep it simple stupid!


8. Re: Encoding , lc_collate e lc_ctype

Paulo
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.


9. Re: Encoding , lc_collate e lc_ctype

Guilherme
Ghost_Shell

(usa Arch Linux)

Enviado em 02/03/2017 - 21:24h

paulo1205 escreveu:

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.


Caraca, excelente explicação. Transmitir conhecimento é um dom. :)

Aprendi bastante sobre esses detalhes de outros idiomas. THX.

Keep it simple stupid!


10. Re: Encoding , lc_collate e lc_ctype

Paulo
paulo1205

(usa Ubuntu)

Enviado em 03/03/2017 - 10:20h

Peço desculpa pelos erros de ortografia na mensagem anterior. Foram fruto de desatenção (sono).

Complemento algumas informações que eu acabei esquecendo de mencionar.

UTF-32 também tem problemas de disposição de bytes semelhantes aos que eu citei para UTF-16. Na hora de dispor os caracteres em arquivos ou em fluxos de rede, que são orientados a bytes, o caráter com valor 0x00102030 terá os bytes dispostos como “0x00, 0x10, 0x20, 0x30” (UTF-32BE) ou como “0x30, 0x20, 0x10, 0x00” (UTF-32LE)? A Internet preconiza a primeira forma, mas os nossos PCs baseados em Intel usam internamente a segunda forma. Quando converter, e quando não converter?

Dependendo da aplicação é possível imaginar um contexto em que poderia até valer a pena pagar por uma CPU que trabalhe nativamente com a mesma disposição usada na rede, para economizar a computação (i.e. energia) que seria necessária para ficar trocando bytes e posição ou convertendo para representações diferentes.

Ao menos por enquanto, o Unicode não define nenhum caráter após a posição 0x0010FFFF, o que significa que não são necessários mais do que 21 bits para representar qualquer dos seus caracteres. Com UTF-32, você estaria sempre “desperdiçando” 11 bits, sempre zerados, em cada caráter de 32 bits armazenado. Se você armazenar apenas texto latino, que se restringe aos valores na parte baixa da tabela de caracteres, esse “desperdício“ será maior ainda (ficando entre 23 a 25 bits).

Por outro lado, se você optar por uma codificação que use uma quantidade variável de bytes para representar cada caráter, a operação de comparação de caracteres pode se revelar mais custosa.

Particularmente no contexto de banco de dados, a collation pode fazer muita diferença no caso de buscas. Por exemplo: o que significa um “SELECT * FROM TABELA WHERE NOME LIKE '%a%'”? Eu entendo que essa consulta, num mundo perfeito, deveria pegar qualquer nome que contivesse a letra “a”, como maiúscula ou minúscula, com qualquer possível combinação de marcas diacríticas e qualquer variação de apresentação (subscrito, sobrescrito, meia-largura, dupla-largura, como símbolo matemático etc.), e eventualmente transliterações de “a” (com cada uma de suas variações) em outros idiomas. Obviamente que a forma e o contexto do dado vai limitar muitas dessas opções (usando o exemplo anterior, é improvável que um nome contenha letras em forma de subscrito ou em contexto matemático), mas o DBMS em si deveria estar pronto a tratar qualquer situação, para que eu, se quisesse, pudesse ter uma tabela com uma coluna capaz de armazenar equações matemáticas ou texto com múltiplos idiomas.

E mais: essa coluna deveria poder eventualmente ser criada e usada com índices. Dá para conjugar índices com collation e locales?

Sem dúvida, é um problema bem interessante e difícil. Eu não a menor ideia de como tratá-lo.

------------------------

Felizmente, porém, esse problema não deveria ser objeto de preocupação para um administrador de SO. Quem deveria determinar a parâmetros de locale a usar numa tabela, esquema ou banco deveria ser o arquiteto de dados, em conjunto com os arquitetos dos sistemas que usarem o banco.


11. Re: Encoding , lc_collate e lc_ctype

Wa
LaraW

(usa Outra)

Enviado em 03/03/2017 - 13:12h

Obrigada a vocês pela explicação. Paulo, realmente sua explicação foi bem completa. Vou ler com bastante calma.

Valeu demais!!!!


12. Re: Encoding , lc_collate e lc_ctype

Wa
LaraW

(usa Outra)

Enviado em 03/03/2017 - 13:15h

Obrigada também Ghost_Shell. Me ajudou bastante.



01 02



Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts