Início / dba / Perguntas / 199853
Accepted
Aram
Asked: 2018-03-10 13:10:58 +0800 CST

Classificação sensível ao acento

  • 772

Por que essas duas SELECTinstruções resultam em uma ordem de classificação diferente?

USE tempdb;
CREATE TABLE dbo.OddSort 
(
    id INT IDENTITY(1,1) PRIMARY KEY
    , col1 NVARCHAR(2)
    , col2 NVARCHAR(2)
);
GO
INSERT dbo.OddSort (col1, col2) 
VALUES (N'e', N'eA')
    , (N'é', N'éB')
    , (N'ë', N'ëC')
    , (N'è', N'èD')
    , (N'ê', N'êE')
    , (N'ē', N'ēF');
GO

SELECT * 
FROM dbo.OddSort 
ORDER BY col1 COLLATE Latin1_General_100_CS_AS;

╔════╦══════╦══════╗
║ id ║ col1 ║ col2 ║
╠════╬══════╬══════╣
║ 1 ║ e ║ eA ║
║ 2 ║ é ║ éB ║
║ 4 ║ è ║ èD ║ -- deve ser id 3?
║ 5 ║ ê ║ êE ║
║ 3 ║ ë ║ ë C ║
║ 6 ║ ē ║ ēF ║
╚════╩══════╩══════╝
SELECT * 
FROM dbo.OddSort 
ORDER BY col2 COLLATE Latin1_General_100_CS_AS;

╔════╦══════╦══════╗
║ id ║ col1 ║ col2 ║
╠════╬══════╬══════╣
║ 1 ║ e ║ eA ║
║ 2 ║ é ║ éB ║
║ 3 ║ ë ║ ë C ║
║ 4 ║ è ║ èD ║
║ 5 ║ ê ║ êE ║
║ 6 ║ ē ║ ēF ║
╚════╩══════╩══════╝
sql-server collation

2 respostas

  1. O comportamento que você está vendo aqui se deve, em um sentido geral, ao fato de que o Unicode Collation Algorithm (UCA) permite uma classificação complexa em vários níveis. Mais especificamente:

    1. Ordenação não é comparação:

      Determinar se duas strings são iguais ou diferentes é bastante simples (dado um local/idioma específico e um conjunto de sensibilidades). Mas determinar a ordem de 2 ou mais strings pode ser altamente complexo.

    2. A classificação é feita em uma série de etapas, com cada etapa aplicada à string inteira, não caractere por caractere:

      1. Padrão: ordena os caracteres de base (independentemente das diferenças de acento e maiúsculas)
      2. IF Sensível ao acento, aplique pesos de acento/diacrítico
      3. IF Sensível a maiúsculas e minúsculas, aplique pesos de revestimento

    Quando você classifica por col1(caractere único), primeiro determina que todos os caracteres têm o mesmo peso, pois são todos " e ". Em seguida, aplica os pesos acentos/diacríticos. Não há diferenças de caixa, então a terceira etapa não mudaria nada. Portanto, as únicas diferenças estão na etapa 2, e é por isso que há uma ordem preferencial para essas linhas com base em col1.

    Quando você classifica por col2(dois caracteres), primeiro determina que cada linha tem um peso diferente, pois ambos os caracteres são usados ​​para determinar o peso de classificação (por exemplo, " ea ", " eb ", etc). Em seguida, aplica os pesos acentos/diacríticos. Não há diferenças de caixa, então a terceira etapa não mudaria nada. Portanto, há diferenças nas etapas 1 e 2 desta vez. Mas como as diferenças na etapa 1 já foram aplicadas a cada string antes que os pesos da etapa 2 sejam considerados, os pesos da etapa 2 não têm nenhum efeito na ordenação; eles só se aplicariam se os pesos da etapa 1 para duas ou mais linhas fossem os mesmos.

    A adaptação a seguir do código de exemplo da pergunta ilustra o comportamento de classificação descrito acima. Adicionei algumas linhas adicionais e uma coluna adicional para ajudar a mostrar o impacto do Collation diferenciando maiúsculas de minúsculas (já que os dados de amostra originais são todos em minúsculas):

    CONFIGURAR

    USE [tempdb];

-- DROP TABLE dbo.OddSort;
CREATE TABLE dbo.OddSort
(
    id INT IDENTITY(1,1) PRIMARY KEY,
    col1 NVARCHAR(5) COLLATE Latin1_General_100_CS_AS,
    col2 NVARCHAR(5) COLLATE Latin1_General_100_CS_AS,
    col3 NVARCHAR(5) COLLATE Latin1_General_100_CS_AS
);
GO

INSERT dbo.OddSort (col1, col2, col3)
VALUES (N'e', N'eA', N'e A')
     , (N'ê', N'êE', N'ê E')
     , (N'é', N'éH', N'é H')
     , (N'ë', N'ëC', N'ë C')
     , (N'E', N'EG', N'E G')
     , (N'Ë', N'ëh', N'ë h')
     , (N'è', N'èD', N'è D')
     , (N'é', N'éB', N'é B')
     , (N'ë', N'ëH', N'ë H')
     , (N'ē', N'ēF', N'ē F');

    TESTE 1

    SELECT [id], [col1], UNICODE([col1]) AS [CodePoint]
FROM dbo.OddSort 
ORDER BY col1;

    Devoluções:

    id    col1    CodePoint
1     e       101
5     E       69
8     é       233
3     é       233
7     è       232
2     ê       234
4     ë       235
9     ë       235
6     Ë       203
10    ē       275

    O que podemos ver nos resultados acima:

    1. O Code Point não está determinando a ordem de classificação
    2. Os caracteres não acentuados são classificados antes dos caracteres acentuados (dentro da mesma letra: f ainda viria depois de todos eles). Claramente, os pesos de acento são aplicados antes dos pesos de maiúsculas e minúsculas.
    3. Minúsculas classifica antes de maiúsculas dentro do mesmo caractere acentuado (ou não acentuado) (ou seja, o e depois E , e o ë depois Ë ). Essa adaptação é usada pela maioria dos agrupamentos do Windows, enquanto a maioria dos agrupamentos do SQL Server classifica primeiro as maiúsculas.

    TESTE 2

    SELECT [id], [col2]
FROM dbo.OddSort 
ORDER BY col2;

    Devoluções:

    id    col2
1     eA
8     éB
4     ëC
7     èD
2     êE
10    ēF
5     EG
3     éH
6     ëh
9     ëH

    O que podemos ver nos resultados acima:

    1. A classificação de primeiro nível é realmente os personagens básicos. Se fossem acentos / diacríticos, as linhas ëC (id = 4), ēF (id = 10) e EG (id = 5) não estariam onde estão. Se fosse maiúscula, a linha EG (id = 5) não estaria onde está.
    2. A classificação de segundo nível é realmente os acentos / diacríticos. Isso explica porque as últimas três linhas são éH -> ëh -> ëH em vez de ëh -> éH -> ëH (ou seja, IDs 3 -> 6 -> 9 em vez de 6 -> 3 -> 9).
    3. A classificação de terceiro nível é realmente o invólucro. É por isso que as últimas 2 linhas são ëh -> ëH , já que as letras minúsculas são classificadas primeiro.

    TESTE 3

    SELECT [id], [col3]
FROM dbo.OddSort 
ORDER BY col3;

    Devoluções:

    id    col3
1     e A
8     é B
4     ë C
7     è D
2     ê E
10    ē F
5     E G
3     é H
6     ë h
9     ë H

    O que podemos ver nos resultados acima:

    1. A ordem de classificação é exatamente a mesma do Teste 2. A única diferença nos valores de teste aqui é que há um espaço entre cada caractere, eliminando a possibilidade de regras contextuais. Portanto, sabemos que o motivo da diferença na ordem de classificação para col2na pergunta é novamente devido à "Comparação de vários níveis" e não à "Sensibilidade contextual".

    Notas Adicionais:

    1. Com relação a obter as regras exatas, isso não é tão fácil quanto deveria ser. O problema em obter explicações concretas dessas regras é que as regras de classificação Unicode, embora definitivamente documentadas, são uma recomendação. Cabe aos fornecedores, como a Microsoft, implementar essas recomendações. A Microsoft não implementou as recomendações exatamente como indicado na documentação do Unicode, portanto, há uma desconexão (semelhante a como as especificações HTML ou CSS não são implementadas completamente, nem mesmo da mesma maneira, entre os fornecedores). Então, existem diferentes versões do Windows Collations (você está usando a versão 100que saiu com o SQL Server 2008) e que está vinculada a uma versão Unicode que é muito mais antiga que a versão atual do Unicode ou do ICU Collation demoestá usando. Por exemplo, a seção O que há de novo no SQL Server 2008 Collations da documentação "Collation and Unicode Support" para SQL Server 2008 apresenta 2 pontos muito interessantes sobre o que há de "novo" na _100_série Collations:

      1. Tabela de casos Unicode 5.0.

        O Unicode 5.0 foi publicado em julho de 2006 (bem, o banco de dados de caracteres foi lançado então, e a especificação completa seguiu no final de 2006). A versão atual é 10.0 que foi publicada em junho de 2017. E dado o padrão de lançamento dos últimos 4 anos, é provável que a versão 11.0 seja lançada em meados de 2018.

      2. A ponderação foi adicionada a caracteres anteriormente não ponderados que seriam comparados igualmente.

        Esses pesos foram mais do que provavelmente definidos no Padrão Unicode, mas não nesta implementação.

       
      Ainda assim, a documentação do UCA vinculada acima é um bom lugar para começar.

    2. As chaves de classificação usadas pelo Windows / .NET / SQL Server não são exatamente as mesmas mostradas no padrão Unicode (consulte a resposta de @Patrick) ou implementadas no ICU . Para ver o que o Windows / .NET / SQL Server usa, você pode tentar o método CompareInfo.GetSortKey . Criei uma UDF SQLCLR para passar esses valores e obter a chave de classificação. Observe que estou usando o SQL Server 2017 no Windows 10 com o .NET Framework 4.5 - 4.6.1 instalado, portanto, o .NET deve usar o Unicode 6.0.0. Além disso, Level4 não está sendo usado para essas strings.

      CHAR    L1     L2     L3     L4
e      0E21
E      0E21           12
ë      0E21    13
Ë      0E21    13     12

      Observar essas chaves de classificação para o Teste 1 e perceber que os níveis são classificados como várias colunas dentro de uma ORDER BYcláusula (L3 é classificado dentro dos mesmos valores de L2, que é classificado dentro dos mesmos valores de L1), deve ilustrar que o motivo do comportamento observado na pergunta é, de fato, a capacidade de classificação em vários níveis do Unicode. Da mesma maneira:

      CHAR       L1         L2       L3       L4
EG      0E210E25              1212
éH      0E210E2C      0E      0212
ëh      0E210E2C      13
ëH      0E210E2C      13      0212

      Observando algumas das chaves de classificação para o Teste 2, podemos ver que os caracteres básicos são classificados primeiro (L1), depois os acentos são classificados (L2) e, em seguida, as maiúsculas são classificadas (L3).

    3. Como o tipo de dados é NVARCHAR, estamos preocupados apenas com pontos de código Unicode e algoritmos de classificação, daí o uso da UNICODE()função em TEST 1. Embora as páginas de código sejam especificadas pela maioria dos agrupamentos, elas pertencem apenas aos VARCHARdados. Ou seja, enquanto a página de código 1252 é especificada pela Latin1_General*série de agrupamentos, isso pode ser ignorado aqui.

    4. Os pesos descritos na Default Unicode Collation Element Table (DUCET) ( Versão 5.0.0 , que deve mapear para a _100_série Collations) são adequados para o inglês dos EUA, mas não para outras localidades/idiomas. Outros idiomas precisam começar com o DUCET e, em seguida, aplicar regras de substituição específicas de localidade, conforme definido pelo projeto Common Locale Data Repository (CLDR). Pelo que posso dizer, as versões 1.4 / 1.4.1 foram lançadas em 2006. Para obter essas substituições, baixe o arquivo "core" do CLDR 1.4 em http://unicode.org/Public/cldr/1.4.0/core.zip , então, nesse arquivo zip, vá para a pasta de agrupamento e encontre o arquivo XML correspondente à localidade que está sendo usada. Esses arquivos contêm apenas as substituições e não são conjuntos completos de regras de agrupamento.

    • 16
  2. Best Answer

    Esta questão não está tão relacionada a bancos de dados, mas mais sobre manipulação e regras de Unicode.

    Com base em https://learn.microsoft.com/en-us/sql/t-sql/statements/windows-collation-name-transact-sql Latin1_General_100_CS_AS significa: "O agrupamento usa as regras de classificação do dicionário geral Latin1 e mapeia para a página de código 1252" com o acréscimo de CS = Case Sensitive e AS = Accent Sensitive.

    O mapeamento entre a página de código do Windows 1252 e Unicode ( http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP1252.TXT ) mostra os mesmos valores para todos os caracteres com os quais estamos lidando (exceto e com macron que não existe no mapeamento da Microsoft, então não faço ideia do que ele faz com este caso), então podemos nos concentrar nas ferramentas e terminologia Unicode por enquanto.

    Primeiro, deixe-nos saber exatamente com o que estamos lidando, para todas as suas strings:

    0065  LATIN SMALL LETTER E
0041  LATIN CAPITAL LETTER A
00E9  LATIN SMALL LETTER E WITH ACUTE
0042  LATIN CAPITAL LETTER B
00EB  LATIN SMALL LETTER E WITH DIAERESIS
0043  LATIN CAPITAL LETTER C
00E8  LATIN SMALL LETTER E WITH GRAVE
0044  LATIN CAPITAL LETTER D
00EA  LATIN SMALL LETTER E WITH CIRCUMFLEX
0045  LATIN CAPITAL LETTER E
‎0113  LATIN SMALL LETTER E WITH MACRON
0046  LATIN CAPITAL LETTER F

    O algoritmo de agrupamento Unicode é descrito aqui: https://www.unicode.org/reports/tr10/

    Dê uma olhada na seção 1.3 "Sensibilidade contextual" que explica que a classificação não pode depender apenas de um caractere após o outro, pois algumas regras são sensíveis ao contexto.

    Observe também estes pontos em 1.8:

    Collation não é uma propriedade de strings. A ordem de agrupamento não é preservada em operações de concatenação ou substring, em geral.

    Por padrão, o algoritmo faz uso de três níveis totalmente personalizáveis. Para a escrita latina, esses níveis correspondem aproximadamente a:

    alphabetic ordering
diacritic ordering
case ordering.

    Mas o algoritmo por si só é um pouco denso. A essência disso é: Resumidamente, o Algoritmo de Agrupamento Unicode recebe uma string Unicode de entrada e uma Tabela de Elementos de Agrupamento, contendo dados de mapeamento para caracteres. Ele produz uma chave de classificação, que é uma matriz de inteiros de 16 bits sem sinal. Duas ou mais chaves de classificação assim produzidas podem ser comparadas binariamente para fornecer a comparação correta entre as strings para as quais foram geradas.

    Você pode ver as regras de classificação latinas específicas aqui: http://developer.mimer.com/collations/charts/latin.htm ou mais direta e especificamente para MS SQL: http://collation-charts.org/mssql/mssql. 0409.1252.Latin1_General_CS_AS.html

    Para o epersonagem que mostra:

    e E é É è ê ê Ê ë Ë

    Isso explica seus resultados ao fazer o pedido, col1exceto que ē não existe na página de código 1252, então não tenho absolutamente nenhuma ideia do que ele faz com ele.

    Ou se fizermos o algoritmo Unicode manualmente, usando o valor de chaves de DUCET em http://www.unicode.org/Public/UCA/latest/allkeys.txt :

    passo 1: Formulário de normalização D, então cada caso se torna:

    e => U+0065
é => U+0065 U+0301
ë => U+0065 U+0308
è => U+0065 U+0300
ê => U+0065 U+0302
ē => U+0065 U+0304

    passo 2, produzir matrizes de agrupamento (pesquisa no arquivo allkeys.txt)

    e => [.1D10.0020.0002]
é => [.1D10.0020.0002] [.0000.0024.0002]
ë => [.1D10.0020.0002] [.0000.002B.0002]
è => [.1D10.0020.0002] [.0000.0025.0002]
ê => [.1D10.0020.0002] [.0000.0027.0002]
ē => [.1D10.0020.0002] [.0000.0032.0002]

    Etapa 3, Chaves de classificação de formulário (para cada nível, pegue cada valor dentro de cada matriz de agrupamento, coloque 0000 como delimitador e comece novamente para o próximo nível)

    e => 1D10 0000 0020 0000 0002
é => 1D10 0000 0020 0024 0000 0002 0002
ë => 1D10 0000 0020 002B 0000 0002 0002
è => 1D10 0000 0020 0025 0000 0002 0002
ê => 1D10 0000 0020 0027 0000 0002 0002
ē => 1D10 0000 0020 0032 0000 0002 0002

    passo 4, Comparar chaves de classificação (comparação binária simples de cada valor um por um): O quarto valor é suficiente para classificar todos, então a ordem final se torna:

    e
é
è
ê
ë
ē

    Da mesma forma para pedidos em col2:

    passo 1: NFD

    eA => U+0065 U+0041
éB => U+0065 U+0301 U+0042
ëC => U+0065 U+0308 U+0043
èD => U+0065 U+0300 U+0044
êE => U+0065 U+0302 U+0045
ēF => U+0065 U+0304 U+0046

    etapa 2: matrizes de agrupamento

    eA => [.1D10.0020.0002] [.1CAD.0020.0008]
éB => [.1D10.0020.0002] [.0000.0024.0002] [.1CC6.0020.0008]
ëC => [.1D10.0020.0002] [.0000.002B.0002] [.1CE0.0020.0008]
èD => [.1D10.0020.0002] [.0000.0025.0002] [.1CF5.0020.0008]
êE => [.1D10.0020.0002] [.0000.0027.0002] [.1D10.0020.0008]
ēF => [.1D10.0020.0002] [.0000.0032.0002] [.1D4B.0020.0008]

    step 3 : Form sort keys

    eA => 1D10 1CAD 0000 0020 0020 0000 0002 0008
éB => 1D10 1CC6 0000 0020 0024 0020 0000 0002 0002 0008
ëC => 1D10 1CE0 0000 0020 002B 0020 0000 0002 0002 0008
èD => 1D10 1CF5 0000 0020 0025 0020 0000 0002 0002 0008
êE => 1D10 1D10 0000 0020 0027 0020 0000 0002 0002 0008
ēF => 1D10 1D4B 0000 0020 0032 0020 0000 0002 0002 0008

    step 4 : Compare sort keys: The second value is enough to sort them all, and it is in fact already in increasing order, so the final order is indeed:

    eA
éB
ëC
èD
êE
ēF

    Update: adding Solomon Rutzky third case, which is trickier because of the space that enables new rules (I chose the "non-ignorable case"):

    step 1, NFD:

    è 1 => U+0065 U+0300 U+0020 U+0031
ê 5 => U+0065 U+0302 U+0020 U+0035
e 2 => U+0065 U+0020 U+0032
é 4 => U+0065 U+0301 U+0020 U+0034
ē 3 => U+0065 U+0304 U+0020 U+0033
ë 6 => U+0065 U+0308 U+0020 U+0036

    step 2, Produce collation arrays:

    è 1 => [.1D10.0020.0002] [.0000.0025.0002] [*0209.0020.0002] [.1CA4.0020.0002]
ê 5 => [.1D10.0020.0002] [.0000.0027.0002] [*0209.0020.0002] [.1CA8.0020.0002]
e 2 => [.1D10.0020.0002] [*0209.0020.0002] [.1CA5.0020.0002]
é 4 => [.1D10.0020.0002] [.0000.0024.0002] [*0209.0020.0002] [.1CA7.0020.0002]
ē 3 => [.1D10.0020.0002] [.0000.0032.0002] [*0209.0020.0002] [.1CA6.0020.0002]
ë 6 => [.1D10.0020.0002] [.0000.002B.0002] [*0209.0020.0002] [.1CA9.0020.0002]

    step 3, Form sort keys:

    è 1 => 1D10 0209 1CA4 0000 0020 0025 0020 0020 0000 0002 0002 0002 0002
ê 5 => 1D10 0209 1CA8 0000 0020 0027 0020 0020 0000 0002 0002 0002 0002
e 2 => 1D10 0209 1CA5 0000 0020 0020 0020 0000 0002 0002 0002
é 4 => 1D10 0209 1CA7 0000 0020 0024 0020 0020 0000 0002 0002 0002 0002
ē 3 => 1D10 0209 1CA6 0000 0020 0032 0020 0020 0000 0002 0002 0002 0002
ë 6 => 1D10 0209 1CA9 0000 0020 002B 0020 0020 0000 0002 0002 0002 0002

    step 4, Compare sort keys:

    Basically the third value determines the order, and it is in fact only based on the last digit, so the order should be:

    è 1
e 2
ē 3
é 4
ê 5
ë 6

    Second update based on Solomon Rutzky's comment about Unicode versions.

    I used the allkeys.txt data about latest Unicode version at this time, that is version 10.0

    If we need to take instead into account Unicode 5.1, this would be: http://www.unicode.org/Public/UCA/5.1.0/allkeys.txt

    I just checked, for all the characters above, the collation arrays are the following instead:

    e => [.119D.0020.0002.0065]
é => [.119D.0020.0002.0065] [.0000.0032.0002.0301]
ë => [.119D.0020.0002.0065] [.0000.0047.0002.0308]
è => [.119D.0020.0002.0065] [.0000.0035.0002.0300]
ê => [.119D.0020.0002.0065] [.0000.003C.0002.0302]
ē => [.119D.0020.0002.0065] [.0000.005B.0002.0304]

    and:

    eA => [.119D.0020.0002.0065] [.1141.0020.0008.0041]
éB => [.119D.0020.0002.0065] [.0000.0032.0002.0301] [.1157.0020.0008.0042]
ëC => [.119D.0020.0002.0065] [.0000.0047.0002.0308] [.116F.0020.0008.0043]
èD => [.119D.0020.0002.0065] [.0000.0035.0002.0300] [.1182.0020.0008.0044]
êE => [.119D.0020.0002.0065] [.0000.003C.0002.0302] [.119D.0020.0008.0045]
ēF => [.119D.0020.0002.0065] [.0000.005B.0002.0304] [.11D5.0020.0008.0046]

    and:

    è 1 => [.119D.0020.0002.0065] [.0000.0035.0002.0300] [*0209.0020.0002.0020] [.1138.0020.0002.0031]
ê 5 => [.119D.0020.0002.0065] [.0000.003C.0002.0302] [*0209.0020.0002.0020] [.113C.0020.0002.0035]
e 2 => [.119D.0020.0002.0065] [*0209.0020.0002.0020] [.1139.0020.0002.0032]
é 4 => [.119D.0020.0002.0065] [.0000.0032.0002.0301] [*0209.0020.0002.0020] [.113B.0020.0002.0034]
ē 3 => [.119D.0020.0002.0065] [.0000.005B.0002.0304] [*0209.0020.0002.0020] [.113A.0020.0002.0033]
ë 6 => [.119D.0020.0002.0065] [.0000.0047.0002.0308] [*0209.0020.0002.0020] [.113D.0020.0002.0036]

    which then compute to the following sorting keys:

    e => 119D 0000 0020 0000 0002 0000 0065
é => 119D 0000 0020 0032 0000 0002 0002 0000 0065 0301
ë => 119D 0000 0020 0047 0000 0002 0002 0000 0065 0308
è => 119D 0000 0020 0035 0000 0002 0002 0000 0065 0300
ê => 119D 0000 0020 003C 0000 0002 0002 0000 0065 0302
ē => 119D 0000 0020 005B 0000 0002 0002 0000 0065 0304

    and:

    eA => 119D 1141 0000 0020 0020 0000 0002 0008 0000 0065 0041
éB => 119D 1157 0000 0020 0032 0020 0000 0002 0002 0008 0000 0065 0301 0042
ëC => 119D 116F 0000 0020 0047 0020 0000 0002 0002 0008 0000 0065 0308 0043
èD => 119D 1182 0000 0020 0035 0020 0000 0002 0002 0008 0000 0065 0300 0044
êE => 119D 119D 0000 0020 003C 0020 0000 0002 0002 0008 0000 0065 0302 0045
ēF => 119D 11D5 0000 0020 005B 0020 0000 0002 0002 0008 0000 0065 0304 0046

    and:

    è 1 => 119D 0209 1138 0000 0020 0035 0020 0020 0000 0002 0002 0002 0002 0000 0065 0300 0020 0031
ê 5 => 119D 0209 113C 0000 0020 003C 0020 0020 0000 0002 0002 0002 0002 0000 0065 0302 0020 0035
e 2 => 119D 0209 1139 0000 0020 0020 0020 0000 0002 0002 0002 0000 0065 0020 0032
é 4 => 119D 0209 113B 0000 0020 0032 0020 0020 0000 0002 0002 0002 0002 0000 0065 0301 0020 0034
ē 3 => 119D 0209 113A 0000 0020 005B 0020 0020 0000 0002 0002 0002 0002 0000 0065 0304 0020 0033
ë 6 => 119D 0209 113D 0000 0020 0047 0020 0020 0000 0002 0002 0002 0002 0000 0065 0308 0020 0036

    which again gives these three sorted results:

    e
é
è
ê
ë
ē

    and

    eA
éB
ëC
èD
êE
ēF

    and

    è 1
e 2
ē 3
é 4
ê 5
ë 6
    • 13

relate perguntas