A partir do SQL Server 2019, ele oferece suporte a UTF-8 como agrupamento. No entanto, de acordo com as seguintes consultas:
SELECT COLLATIONPROPERTY('Arabic_100_CS_AS_KS_WS_SC_UTF8', 'CodePage')
SELECT COLLATIONPROPERTY('Latin1_General_100_CS_AS_KS_WS_SC_UTF8', 'CodePage');
ambos retornam a página de código 65001
que é Unicode no Windows. Além disso, todos os novos _UTF8
agrupamentos usam a página de código 65001
:
SELECT * FROM sys.fn_helpcollations() WHERE name LIKE '%_UTF8';
Existem diferenças entre usar Arabic_100_CS_AS_KS_WS_SC_UTF8
e Latin1_General_100_CS_AS_KS_WS_SC_UTF8
como agrupamento?
Sim, todos os
_UTF8
agrupamentos usam a página de código 65001, pois essa é a página de código para UTF-8. Você pode até usar 65001 em uma janela DOS / Command através de:embora nem todos os programas e fontes funcionem perfeitamente com ele.
Para
_UTF8
agrupamentos, a página de código não é controlada pela cultura (ou seja,Latin1_General
vsArabic
) como é para não_UTF8
agrupamentos porque as páginas de código indicam a codificação específica de 8 bits usada paraVARCHAR
dados (ou seja, dados de caracteres de 8 bits). Para codificações de 8 bits não Unicode, a cultura geralmente está vinculada à página de código que é o conjunto de caracteres (por exemplo, Latin1 é a página de código Windows-1252 que possui caracteres diferentes no intervalo 128-255 do que Windows-1255, que é o código página para hebraico). Mas para UTF-8, é a codificação de 8 bits para o conjunto de caracteres singular e abrangente que é Unicode.No que diz respeito às diferenças entre
Arabic_100_CS_AS_KS_WS_SC_UTF8
eLatin1_General_100_CS_AS_KS_WS_SC_UTF8
ir, seriam realmente apenas as regras específicas da cultura para classificação e comparação de vários personagens. É claro que essas duas linguagens não compartilham nenhum caractere, mas ainda pode haver diferenças na forma como alguns pontos de código são tratados.Examinando o arquivo "Tabela de peso de classificação do Windows Server 2008" (que é o que os
_100_
agrupamentos de versão se baseiam principalmente, pelo que me disseram), não consigo encontrar nenhuma diferença de classificação/comparação entre esses dois agrupamentos. Então, eles são provavelmente os mesmos em termos de comportamento. No entanto, eles não são os mesmos no sentido de que eles ainda têm um LCID diferente (o identificador de localidade/cultura), portanto, converter seus valores para não UTF8VARCHAR
pode resultar em perda/corrupção de dados e qualquer processo/funcionalidade olhando para o agrupamento para determinar que algum outro comportamento pode se comportar de maneira diferente.Dito isto, encontrei um exemplo de uma diferença de comportamento para caracteres árabes ao usar um agrupamento Urdu, pois esses agrupamentos têm algumas modificações nos pesos de classificação padrão (9 registrados no arquivo "Tabela de peso de classificação do Windows Server 2008") .
Olhando para o caractere "Teh Marbuta" (U+0629), ele tem um peso de 29 na tabela padrão (ou seja, a tabela usada para inglês dos EUA / Latin1), que tem um peso de classificação menor que o caractere "Peheh" (U +06A6), que tem um peso padrão de 137. O 41 indica em qual "script" o caractere está, e ambos são caracteres arábicos. No entanto, os agrupamentos Urdu modificam o peso de classificação de "Teh Marbuta" (U+0629) para 183, que então tem um peso de classificação maior que "Peheh" (U+06A6), ainda sendo 137.
Se classificarmos esses dois caracteres usando
Latin1_General_100_CS_AS_KS_WS_SC_UTF8
ouArabic_100_CS_AS_KS_WS_SC_UTF8
, devemos obter o comportamento padrão. E, mesmo se usarmos umYakut
agrupamento, que usa o script cirílico e tem suas próprias modificações nos pesos de classificação padrão, ele não modifica nenhum desses caracteres arábicos, portanto, eles devem se comportar da mesma forma que ao usar umLatin1_General
ouArabic
agrupamento:Todas as três consultas mostradas acima retornam os seguintes resultados:
No entanto, quando mudamos para um
Urdu
agrupamento, a ordem desses dois caracteres realmente muda:retorna:
Por fim, lembre-se de que, embora seja raro encontrar isso, os agrupamentos também podem afetar os mapeamentos de maiúsculas/minúsculas. Eu acredito que isso está confinado apenas a collations
Azeri_*
eTurkish
, e apenas para as letras 'i' e 'I' (essas culturas têm um 'I' maiúsculo pontilhado e um 'i' minúsculo sem ponto), mas ainda é melhor Esteja ciente do potencial:retorna: