Ordenação de bytes para caracteres multibyte no SQL Server versus Oracle

O agrupamento de uma coluna NVARCHAR/ NCHAR/ NTEXTnão tem relação com a codificação usada para armazenar os dados nessa coluna. NVARCHARos dados são sempre UTF-16 Little Endian (LE). O agrupamento de NVARCHARdados afeta apenas a classificação e a comparação. O agrupamento afeta a codificação dos VARCHARdados, pois o agrupamento determina a página de código usada para armazenar os dados nessa coluna/variável/literal, mas não estamos lidando com isso aqui.

Como sepupic mencionou , o que você está vendo quando visualiza os dados em formato binário é uma diferença de endianness (Oracle está usando Big Endian enquanto o SQL Server está usando Little Endian). NO ENTANTO, o que você está vendo quando visualiza a forma binária da string no Oracle não é como os dados estão realmente sendo armazenados. Você está usando AL32UTF8o que é UTF-8, que codifica esse caractere em 3 bytes, não em 2, como: E2, 97, A6.

Além disso, não é possível que os hashes sejam os mesmos para linhas de apenas "a", mas não quando incluem "◦", a menos que o hash no Oracle tenha sido feito sem conversão, portanto, usando a codificação UTF-8 e o hash no SQL Server convertendo acidentalmente para VARCHARprimeiro. Caso contrário, não há algoritmo de hash que se comporte como você está descrevendo, como você pode verificar executando o seguinte no SQL Server:

DECLARE @Algorithm NVARCHAR(50) = N'MD4';
SELECT HASHBYTES(@Algorithm, 0x3100), HASHBYTES(@Algorithm, 0x0031);
SET @Algorithm = N'MD5';
SELECT HASHBYTES(@Algorithm, 0x3100), HASHBYTES(@Algorithm, 0x0031);
SET @Algorithm = N'SHA1';
SELECT HASHBYTES(@Algorithm, 0x3100), HASHBYTES(@Algorithm, 0x0031);
SET @Algorithm = N'SHA2_256';
SELECT HASHBYTES(@Algorithm, 0x3100), HASHBYTES(@Algorithm, 0x0031);
SET @Algorithm = N'SHA2_512';
SELECT HASHBYTES(@Algorithm, 0x3100), HASHBYTES(@Algorithm, 0x0031);

No Oracle, você deve usar a CONVERTfunção para obter a string na AL16UTF16LEcodificação e, em seguida, fazer o hash desse valor. Isso deve corresponder ao que o SQL Server tem. Por exemplo, você pode ver as diferentes formas de codificação do White Bullet (U + 25E6) e como usar CONVERTjunto com AL16UTF16LEcorrigirá isso no dbfiddle e abaixo:

SELECT DUMP(CHR(14849958), 1016) AS "UTF8",
       DUMP(CHR(9702 USING NCHAR_CS), 1016) AS "UTF16BE",
       DUMP(CONVERT(CHR(9702 USING NCHAR_CS), 'AL16UTF16LE' ), 1016) AS "UTF16LE"
FROM DUAL;

SELECT DUMP('a' || CHR(14849958), 1016) AS "UTF8",
       DUMP('a' || CHR(9702 USING NCHAR_CS), 1016) AS "UTF16BE",
       DUMP(CONVERT('a' || CHR(9702 USING NCHAR_CS), 'AL16UTF16LE' ), 1016) AS "UTF16LE"
FROM DUAL;

Que retorna:

UTF8:     Typ=1 Len=3 CharacterSet=AL32UTF8: e2,97,a6
UTF16BE:  Typ=1 Len=2 CharacterSet=AL16UTF16: 25,e6
UTF16LE:  Typ=1 Len=2 CharacterSet=AL16UTF16: e6,25


UTF8:     Typ=1 Len=4 CharacterSet=AL32UTF8: 61,e2,97,a6
UTF16BE:  Typ=1 Len=4 CharacterSet=AL16UTF16: 0,61,25,e6
UTF16LE:  Typ=1 Len=4 CharacterSet=AL16UTF16: 61,0,e6,25

Como você pode ver na 3ª coluna, o conjunto de caracteres é relatado erroneamente como sendo Big Endian quando é claramente Little Endian com base na ordem dos dois bytes. Você também pode ver que ambos os caracteres são dois bytes em UTF-16, e a ordem de ambos é diferente entre Big e Little Endian, não apenas os caracteres que são > 1 byte em UTF-8.

Dado tudo isso, como os dados estão sendo armazenados como UTF-8, mas você os está vendo como UTF-16 Big Endian por meio da DUMPfunção, parece que você já está convertendo para UTF-16, mas provavelmente não percebendo que o padrão UTF-16 no Oracle é Big Endian.

Observando a definição "UTF-16" na página Glossário da documentação do Oracle , ela afirma (dividi as seguintes frases em duas partes para que seja mais fácil distinguir entre BE e LE):

AL16UTF16 implementa o esquema de codificação big-endian da forma de codificação UTF-16 (o byte mais significativo de cada unidade de código vem primeiro na memória). AL16UTF16 é um conjunto de caracteres nacional válido.

e:

AL16UTF16LE implementa o esquema de codificação UTF-16 little-endian. É um conjunto de caracteres somente de conversão, válido apenas em funções de conversão de conjunto de caracteres, como SQL CONVERTou PL/SQL UTL_I18N.STRING_TO_RAW.

PS Como você está usando AL32UTF8no Oracle, você deve usar o Latin1_General_100_CI_AS_SCagrupamento no SQL Server, não no Latin1_General_CI_AS. O que você está usando é mais antigo e não suporta totalmente caracteres suplementares (sem perda de dados se existirem, mas as funções internas os tratam como 2 caracteres em vez de uma única entidade).

O que você está vendo é uma Little-Endiancodificação que SQL Serverusa para armazenar Unicodecaracteres (mais precisamente, usa UCS-2 LE).

Mais Little-Endianaqui: Diferença entre a ordem Big Endian e Little Endian Byte

Eu não sei como foi possível isso

Quando uso DUMP no Oracle ou converto para VARBINARY no SQL Server os dados correspondem exatamente, exceto os bytes desse caractere

Todos os Unicodecaracteres armazenados em SQL Server, convertidos em binary, são "invertidos", quer dizer, para ver os códigos reais você deve dividi-los em grupos de 2 bytese inverter a ordem dentro de cada par.

Exemplo:

declare @str varchar(3) = 'abc';
declare @str_n nvarchar(3) = N'abc';

select cast(@str as varbinary(3));
select cast(@str_n as varbinary(6));

O resultado é

0x616263

0x610062006300

Como você vê no caso de Unicodebytes de caracteres serem invertidos: "a" é representado como 0x6100e não como 0x0061.

A mesma história é sobre o código 0x25E6real enquanto em representação você o vê como , ou seja .UnicodebinarySQL Server0xE625inverted