Início / dba / Perguntas / 240930
Accepted
rookie099
Asked: 2019-06-20 06:22:07 +0800 CST

PostgreSQL: diferença entre collations 'C' e 'C.UTF-8'

  • 772

No PostgreSQL, qual é a diferença entre collations Ce C.UTF-8?

Ambos aparecem em linhas de pg_collation. Talvez C.UTF-8seja o mesmo que Ccom a codificação UTF-8independentemente ou qual seja a codificação real de um banco de dados?

postgresql collation

3 respostas

  1. Best Answer

    A documentação do PostgreSQL deixa muito a desejar (só falando ? ).

    Para começar, há apenas uma codificação para um banco de dados específico, portanto, Ce C.UTF-8em seu banco de dados UTF-8, ambos estão usando a codificação UTF-8.

    Para agrupamentos libc : normalmente os nomes de agrupamentos, por convenção , são realmente nomes de duas partes da seguinte estrutura:

    {locale_name}.{encoding_name}

    Um "locale" (ou seja, "cultura") é o conjunto de regras específicas do idioma para classificação ( LC_COLLATE) e capitalização ( LC_CTYPE). Mesmo que às vezes haja sobreposição, isso realmente não tem nada a ver com a forma como esses dados são armazenados.

    Uma "codificação" é como os dados são armazenados (ou seja, qual seqüência de bytes equivale a qual caractere). Mesmo que às vezes haja sobreposição, isso realmente não tem nada a ver com as regras de classificação e capitalização de qualquer idioma específico que usa a codificação (algumas codificações podem ser usadas por vários idiomas que podem ter regras bastante diferentes em um ou ambos essas áreas).

    Para ilustrar, considere armazenar dados coreanos:

    • ko_KRé a localidade.
    • As codificações possíveis que funcionam com esta localidade são:
      • EUC_KR(Extended UNIX Code-KR)
      • JOHAB
      • UHC(Código Hangul Unificado / Windows949)
      • UTF8(codificação de 8 bits do Unicode)

    Considere também o seguinte, retirado da documentação " Collation Support: libc collations " (ênfase adicionada):

    Por exemplo, o sistema operacional pode fornecer um código de idioma chamado de_DE.utf8. initdbentão criaria um agrupamento nomeado de_DE.utf8para codificação UTF8... Ele também criaria um agrupamento com a .utf8tag retirada do nome. Portanto, você também pode usar o agrupamento sob o nome de_DE, que é menos complicado de escrever e torna o nome menos dependente de codificação ...

    ...

    Em qualquer banco de dados específico, apenas os agrupamentos que usam a codificação desse banco de dados são de interesse. Outras entradas em pg_collationsão ignoradas. Assim, um nome de agrupamento removido, como de_DEpode ser considerado exclusivo em um determinado banco de dados, mesmo que não seja globalmente exclusivo. O uso dos nomes de agrupamentos removidos é recomendado, pois isso fará com que uma coisa a menos que você precise alterar se decidir alterar para outra codificação de banco de dados. Observe, no entanto, que os agrupamentos default, Ce POSIXpodem ser usados ​​independentemente da codificação do banco de dados.

    Ou seja, em um banco de dados que usa a codificação UTF-8 en_USe en_US.UTF8são equivalentes. MAS, entre esse banco de dados e um banco de dados que usa a LATIN1codificação, os en_USagrupamentos não são equivalentes.

    Então, isso significa que Ce C.UTF-8são a mesma coisa?

    NÃO, isso seria muito fácil!!! A Cordenação é uma exceção ao comportamento indicado acima. O Cagrupamento é um conjunto simples de regras que está disponível independentemente da codificação do banco de dados, e o comportamento deve ser consistente entre as codificações (o que é possível apenas reconhecendo o alfabeto inglês dos EUA — "az" e "AZ" — como "letras" , e classificando por valor de byte, que deve ser o mesmo para as codificações disponíveis para você).

    O C.UTF-8agrupamento é, na verdade, um conjunto de regras ligeiramente aprimorado, em comparação com as Cregras básicas. Essa diferença pode ser vista em pg_collationuma vez que os valores para as colunas collcollatee collctypesão diferentes entre as linhas para Ce C.UTF-8.

    Eu montei um conjunto de consultas de teste para ilustrar algumas das semelhanças e diferenças entre esses dois agrupamentos, bem como em comparação com en_GB(e implicitamente en_GB.utf8). Comecei com as perguntas fornecidas na resposta de Daniel Vérité , aprimorei-as para ficar mais claro sobre o que está e o que não está sendo mostrado e adicionei algumas perguntas. Os resultados nos mostram que:

    1. Ce C.UTF-8são, na verdade, conjuntos de regras diferentes, mesmo que apenas ligeiramente diferentes, com base em seus respectivos valores nas colunas collcollatee em (consulta final)collctypepg_collation
    2. C.UTF-8expande os caracteres que são considerados "letras"
    3. C.UTF-8, ao contrário C(mas como en_GB), reconhece pontos de código Unicode inválidos (ou seja, U+0378) e os classifica para o topo
    4. C.UTF-8, like C(mas diferente en_GBde ), classifica caracteres de letras não inglesas dos EUA por ponto de código
    5. ucs_basicparece ser equivalente a C(o que é indicado na documentação)

    Você pode encontrar e executar as consultas em: db<>fiddle

    • 18

  2. Talvez seja o caso de C.UTF-8 ser o mesmo que C com codificação UTF-8

    Não. Considere, por exemplo, estas diferenças em um banco de dados UTF-8, no Debian 10 Linux:

    postgres=# select upper('é' collate "C"), upper('é' collate "C.UTF-8");
 upper | upper 
-------+-------
 é     | É
(1 row)

postgres=# select ('A' < E'\u0378' collate "C"),
                  ('A' < E'\u0378' collate "C.UTF-8");
 ?column? | ?column? 
----------+----------
 t        | f
(1 row)

    (U+0378 não corresponde a nenhum caractere válido em Unicode).

    Outro exemplo com um caractere Unicode válido (o lado esquerdo é 'THUMBS UP SIGN' U+1F44D ):

    => select '?' < 'A' collate "C";
 ?column? 
----------
 f
(1 row)

=> select '?' < 'A' collate "C.UTF-8";
 ?column? 
----------
 t
(1 row)

    Quando lc_collatefor "C" (ou "POSIX"), a comparação é feita internamente pelo PostgreSQL. Nesse caso, ele compara as representações de bytes das strings usando memcmp.

    Nos demais casos em que libc é o provedor ( collprovider='c'em pg_collation), a comparação é feita pela strcoll_lbiblioteca C, então o próprio PostgreSQL não é responsável pelo resultado e, como mostram os contra-exemplos acima, não há razão para acreditar que será idêntico.

    Isso é verdade pelo menos para agrupamentos apoiados por libc. A partir da versão 10 do Postgres, os agrupamentos ICU podem ser usados. Esses agrupamentos são consistentes em todos os sistemas operacionais.

    Os detalhes sangrentos podem ser encontrados no código-fonte em backend/utils/adtvarlena.c , especialmente a varstrmp_cmpfunção.

    • 8

  3. Na documentação do postgresql, https://www.postgresql.org/docs/11/collation.html :

    23.2.2.1. Agrupamentos padrão

    Em todas as plataformas, os agrupamentos denominados default, C e POSIX estão disponíveis. Agrupamentos adicionais podem estar disponíveis dependendo do suporte do sistema operacional. A ordenação padrão seleciona os valores LC_COLLATE e LC_CTYPE especificados no momento da criação do banco de dados. Os agrupamentos C e POSIX especificam o comportamento “C tradicional”, no qual apenas as letras ASCII de “A” a “Z” são tratadas como letras, e a classificação é feita estritamente por valores de byte de código de caractere.

    Além disso, o nome de agrupamento padrão SQL ucs_basic está disponível para codificação UTF8. É equivalente a C e classifica por ponto de código Unicode.

    Então, se meu entendimento estiver correto, C é ASCII, não UTF8.

    • 1

relate perguntas