Partilhar via

Suporte a agrupamento e Unicode

  • Artigo

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada SQL do AzureAzure Synapse AnalyticsAnalytics Platform System (PDW)ponto de extremidade de análise SQL no Microsoft FabricWarehouse no Microsoft Fabric

Os agrupamentos no SQL Server fornecem regras de classificação e propriedades de sensibilidade a maiúsculas e minúsculas e a acentos para os seus dados. Os agrupamentos usados com tipos de dados de caracteres, como char e varchar, ditam a página de código e os caracteres correspondentes que podem ser representados para esse tipo de dados.

Não importa se você está instalando uma nova instância do SQL Server, restaurando um backup de banco de dados ou conectando o servidor a bancos de dados cliente, é importante entender os requisitos de localidade, a ordem de classificação e a sensibilidade de maiúsculas e minúsculas e acentos dos dados com os quais você está trabalhando. Para listar os agrupamentos disponíveis em sua instância do SQL Server, consulte sys.fn_helpcollations.

Ao selecionar um agrupamento para seu servidor, banco de dados, coluna ou expressão, você está atribuindo determinadas características aos seus dados. Essas características afetam os resultados de muitas operações no banco de dados. Por exemplo, quando você constrói uma consulta usando ORDER BY, a ordem de classificação do conjunto de resultados pode depender do agrupamento aplicado ao banco de dados ou ditado em uma cláusula COLLATE no nível de expressão da consulta.

Para melhor usar o suporte a agrupamento no SQL Server, você deve entender os termos definidos neste artigo e como eles se relacionam com as características dos seus dados.

Termos de agrupamento

Colação

Um agrupamento especifica os padrões de bits que representam cada caractere em um conjunto de dados. Os agrupamentos também determinam as regras que classificam e comparam dados. O SQL Server dá suporte ao armazenamento de objetos com agrupamentos diferentes em um único banco de dados. Para colunas não-Unicode, a configuração de agrupamento especifica a página de código para os dados e quais caracteres podem ser representados. Os dados que você move entre colunas não-Unicode devem ser convertidos da página de código-fonte para a página de código de destino.

Transact-SQL resultados da instrução podem variar quando a instrução é executada no contexto de diferentes bancos de dados que têm configurações de agrupamento diferentes. Se possível, use um agrupamento padronizado para sua organização. Dessa forma, você não precisa especificar o agrupamento em cada caractere ou expressão Unicode. Se você precisar trabalhar com objetos que tenham configurações de agrupamento e página de código diferentes, codifique suas consultas para considerar as regras de precedência de agrupamento. Para obter mais informações, consulte Precedência de agrupamento.

As opções associadas a um agrupamento são sensibilidade a maiúsculas e minúsculas, sensibilidade de acento, sensibilidade kana, sensibilidade de largura e sensibilidade do seletor de variação. O SQL Server 2019 (15.x) apresenta uma opção adicional para codificação UTF-8.

Você pode especificar essas opções acrescentando-as ao nome do agrupamento. Por exemplo, a classificação Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_SC_UTF8 é sensível a maiúsculas, a acentos, a kana, a largura e é codificada em UTF-8. Como outro exemplo, o agrupamento Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS é insensível a maiúsculas e minúsculas, insensível a acentos, sensível a kana, sensível à largura, sensível ao seletor de variações e usa uma página de código herdada para varchar.

O comportamento associado a essas várias opções é descrito na tabela a seguir:

Opção Descrição
Sensível a maiúsculas e minúsculas (_CS) Distingue entre letras maiúsculas e minúsculas. Se essa opção estiver selecionada, as letras minúsculas classificam antes de suas versões maiúsculas. Se essa opção não estiver selecionada, a ordenação não diferenciará maiúsculas de minúsculas. Ou seja, o SQL Server considera as versões maiúsculas e minúsculas das letras idênticas para fins de classificação. Você pode selecionar explicitamente a insensibilidade a maiúsculas e minúsculas ao especificar _CI.
Sensível a acentos (_AS) Distingue entre caracteres acentuados e não acentuados. Por exemplo, a não é igual a ấ. Se essa opção não estiver selecionada, o agrupamento não diferenciará acentos. Ou seja, o SQL Server considera as versões acentuadas e não acentuadas das letras idênticas para fins de classificação. Você pode selecionar explicitamente a insensibilidade ao acento especificando _AI.
Sensível ao Kana (_KS) Distingue entre os dois tipos de caracteres kana japoneses: Hiragana e Katakana. Se essa opção não estiver selecionada, o agrupamento será insensível a kana. Ou seja, o SQL Server considera os caracteres Hiragana e Katakana iguais para fins de classificação. Omitir esta opção é a única forma de especificar a insensibilidade a diferenças entre kana.
Sensível à largura (_WS) Distingue entre caracteres de largura total e de meia largura. Se essa opção não estiver selecionada, o SQL Server considerará a representação de largura total e meia largura do mesmo caractere idêntica para fins de classificação. Omitir essa opção é o único método de especificar a insensibilidade à largura.
Sensível ao seletor de variantes (_VSS) Distingue entre vários seletores de variação ideográfica nos agrupamentos japoneses Japanese_Bushu_Kakusu_140 e Japanese_XJIS_140, que são introduzidos no SQL Server 2017 (14.x). Uma sequência de variação consiste em um caractere base mais um seletor de variação. Se essa opção de _VSS não estiver selecionada, o agrupamento será insensível ao seletor de variação, e o seletor de variação não será considerado na comparação. Ou seja, o SQL Server considera que os caracteres criados sobre o mesmo caractere base com diferentes seletores de variação são idênticos para fins de classificação. Para obter mais informações, consulte Unicode Ideographic Variation Database.

Não há suporte para agrupamentos sensíveis a variações (_VSS) em índices de pesquisa de texto completo. Os índices de pesquisa de texto completo suportam apenas as opções Accent-Sensitive (_AS), Kana-sensitive (_KS) e Width-sensitive (_WS). Os mecanismos de de integração do SQL Server XML e do Common Language Runtime (CLR) não oferecem suporte a seletores de variação (_VSS).
Binário (_BIN) 1 Classifica e compara dados em tabelas do SQL Server com base nos padrões de bits definidos para cada caractere. A ordem de classificação binária é sensível a maiúsculas e minúsculas e a acentos. Binary também é a ordem de classificação mais rápida. Para obter mais informações, consulte a seção agrupamentos binários neste artigo.
Ponto de código binário (_BIN2) 1 Classifica e compara dados em tabelas do SQL Server com base em pontos de código Unicode para dados Unicode. Para dados não-Unicode, o ponto de código binário usa comparações idênticas às de classificações binárias.

A vantagem de usar uma ordem de classificação de pontos de código binário é que não é necessário reordenar os dados em aplicações que comparam dados ordenados do SQL Server. Como resultado, uma ordem de classificação de pontos de código binário fornece desenvolvimento de aplicativos mais simples e possíveis aumentos de desempenho. Para obter mais informações, consulte a seção agrupamentos binários neste artigo.
UTF-8 (_UTF8) Permite que dados codificados UTF-8 sejam armazenados no SQL Server. Se essa opção não estiver selecionada, o SQL Server usará o formato de codificação não-Unicode padrão para os tipos de dados aplicáveis. Para obter mais informações, consulte a seção UTF-8 Support neste artigo.

1 Se o ponto de código binário ou binário estiver selecionado, as opções Diferencia maiúsculas de minúsculas (_CS), Acento (_AS), Kana (_KS) e Largura (_WS) não estarão disponíveis.

Exemplos de opções de agrupamento

Cada agrupamento é combinado como uma série de sufixos para definir a sensibilidade a maiúsculas e minúsculas, acentos, largura ou kana. Os exemplos a seguir descrevem o comportamento da ordem de classificação para várias combinações de sufixos.

Sufixo de agrupamento do Windows Descrição da ordem de classificação
_BIN 1 Classificação binária
_BIN2 1, 2 Ordem de classificação de pontos de código binário
_CI_AI 2 Insensível a maiúsculas e minúsculas, acentos, kana e largura
_CI_AI_KS 2 Insensível a maiúsculas e minúsculas, insensível a acentos, sensível a kana, insensível à largura
_CI_AI_KS_WS 2 Insensível a maiúsculas e minúsculas, a acentos, sensível a kana, sensível a largura
_CI_AI_WS 2 Insensível a maiúsculas e minúsculas, a acentos, aos caracteres japoneses kana, sensível à largura
_CI_AS 2 Insensível a maiúsculas e minúsculas, sensível a acento, insensível a kana, insensível a largura
_CI_AS_KS 2 Insensível a maiúsculas e minúsculas, sensível a acentos, kana, insensível à largura
_CI_AS_KS_WS 2 Insensível a maiúsculas e minúsculas, sensível a acentos, kana e largura
_CI_AS_WS 2 Insensível a maiúsculas e minúsculas, sensível a acentos, insensível a kana, sensível a largura
_CS_AI 2 Sensível a maiúsculas e minúsculas, insensível a acentos, kana ou largura
_CS_AI_KS 2 Sensível a maiúsculas e minúsculas, insensível a acentos, sensível a kana, insensível a largura
_CS_AI_KS_WS 2 Sensível a maiúsculas e minúsculas, insensível a acentos, sensível a kana e largura
_CS_AI_WS 2 Sensível a maiúsculas e minúsculas, insensível a acentos, insensível a kana, sensível a largura
_CS_AS 2 Sensível a maiúsculas e minúsculas, sensível a acentos, insensível a kana, insensível a largura
_CS_AS_KS 2 Sensível a maiúsculas e minúsculas, sensível a acentos, sensível a kana, insensível a largura
_CS_AS_KS_WS 2 Sensível a maiúsculas e minúsculas, sensível a acentos, sensível a kana e sensível a largura
_CS_AS_WS 2 Sensível a maiúsculas/minúsculas, a acentos, insensível a kana, sensível à largura

1 Se o ponto de código binário ou binário estiver selecionado, as opções Diferencia maiúsculas de minúsculas (_CS), Acento (_AS), Kana (_KS) e Largura (_WS) não estarão disponíveis.

2 Adicionar a opção UTF-8 (_UTF8) permite codificar dados Unicode usando UTF-8. Para obter mais informações, consulte a seção UTF-8 Support neste artigo.

Conjuntos de agrupamento

O SQL Server dá suporte aos seguintes conjuntos de agrupamento:

Agrupamentos do Windows

Os agrupamentos do Windows definem regras para armazenar dados de caracteres baseados em uma localidade associada do sistema Windows. Para um agrupamento do Windows, você pode implementar uma comparação de dados não-Unicode usando o mesmo algoritmo que para dados Unicode. As regras de agrupamento base do Windows especificam qual alfabeto ou idioma é usado quando a classificação de dicionário é aplicada. As regras também especificam a página de código usada para armazenar dados de caracteres não-Unicode. A classificação Unicode e não-Unicode é compatível com comparações de strings numa versão específica do Windows. Isso fornece consistência entre os tipos de dados no SQL Server e permite que os desenvolvedores classifiquem cadeias de caracteres em seus aplicativos usando as mesmas regras usadas pelo SQL Server. Para obter mais informações, consulte nome de agrupamento do Windows.

Agrupamentos binários

Os agrupamentos binários classificam os dados com base na sequência de valores codificados definidos pela localidade e pelo tipo de dados. São sensíveis a maiúsculas e minúsculas. Um agrupamento binário no SQL Server define a localidade e a página de código ANSI que são usadas. Isso impõe uma ordem de classificação binária. Por serem relativamente simples, os agrupamentos binários ajudam a melhorar o desempenho do aplicativo. Para tipos de dados não-Unicode, as comparações de dados são baseadas nos pontos de código definidos na página de código ANSI. Para tipos de dados Unicode, as comparações de dados são baseadas nos pontos de código Unicode. Para agrupamentos binários em tipos de dados Unicode, a localidade não é considerada em classificações de dados. Por exemplo, Latin1_General_BIN e Japanese_BIN produzem resultados de classificação idênticos quando são usados em dados Unicode. Para obter mais informações, consulte nome de agrupamento do Windows.

Há dois tipos de agrupamentos binários no SQL Server:

  • Os agrupamentos BIN herdados, que realizavam uma comparação incompleta de ponto de código para ponto de código para dados Unicode. Os agrupamentos binários herdados compararam o primeiro caractere como WCHAR, seguido por uma comparação byte a byte. Em um agrupamento BIN, apenas o primeiro caractere é classificado de acordo com o ponto de código, e os caracteres restantes são classificados de acordo com seus valores de byte.

  • Os agrupamentos BIN2 mais recentes, que implementam uma comparação pura de pontos de código. Em um agrupamento BIN2, todos os caracteres são classificados de acordo com seus pontos de código. Como a plataforma Intel é uma arquitetura um pouco endiana, os caracteres de código Unicode são sempre armazenados com troca de bytes.

Colações do SQL Server

Os agrupamentos do SQL Server (SQL_*) fornecem compatibilidade de ordem de classificação com versões anteriores do SQL Server. As regras de classificação de dicionário para dados não-Unicode são incompatíveis com qualquer rotina de classificação fornecida pelos sistemas operacionais Windows. No entanto, a classificação de dados Unicode é compatível com uma versão específica das regras de classificação do Windows. Como os agrupamentos do SQL Server usam regras de comparação diferentes para dados não-Unicode e Unicode, você vê resultados diferentes para comparações dos mesmos dados, dependendo do tipo de dados subjacente.

Por exemplo, se estiver a usar a collation SQL SQL_Latin1_General_CP1_CI_AS, a cadeia de caracteres não-Unicode 'a-c' é menor do que a 'ab' porque o hífen (-) é classificado como um caráter separado que vem antes de b. No entanto, se você converter essas cadeias de caracteres em Unicode e executar a mesma comparação, a de cadeia de caracteres Unicode será considerada maior que , porque as regras de classificação Unicode usam uma de classificação de palavras que ignora o hífen.

Para obter mais informações, consulte Nome de agrupamento do SQL Server.

Durante a instalação do SQL Server, a configuração de agrupamento de instalação padrão é determinada pela localidade do sistema operacional (SO). Você pode alterar o agrupamento no nível do servidor durante a instalação ou alterando a localidade do sistema operacional antes da instalação. Por motivos de compatibilidade com versões anteriores, o agrupamento padrão é definido como a versão mais antiga disponível associada a cada localidade específica. Portanto, este nem sempre é o agrupamento recomendado. Para aproveitar ao máximo os recursos do SQL Server, altere as configurações de instalação padrão para usar agrupamentos do Windows. Por exemplo, para a localidade do SO "Inglês (Estados Unidos)" (página de código 1252), o agrupamento padrão durante a instalação é SQL_Latin1_General_CP1_CI_ASe pode ser alterado para sua contraparte de agrupamento do Windows mais próxima, Latin1_General_100_CI_AS_SC.

Ao atualizar uma instância em inglês do SQL Server, você pode especificar agrupamentos do SQL Server (SQL_*) para compatibilidade com instâncias existentes do SQL Server. Como o agrupamento padrão para uma instância do SQL Server é definido durante a instalação, certifique-se de especificar as configurações de agrupamento cuidadosamente quando as seguintes condições forem verdadeiras:

  • O código do aplicativo depende do comportamento de agrupamentos anteriores do SQL Server.
  • Você deve armazenar dados de caracteres que reflitam vários idiomas.

Níveis de agrupamento

Há suporte para agrupamentos de configuração nos seguintes níveis de uma instância do SQL Server:

Agrupamentos ao nível do servidor

O agrupamento de servidor padrão é determinado durante a instalação do SQL Server e se torna o agrupamento padrão dos bancos de dados do sistema e de todos os bancos de dados de usuários.

A tabela a seguir mostra as designações de agrupamento padrão, conforme determinado pela localidade do sistema operacional (SO), incluindo seus LCID (Identificadores de Código de Linguagem do Windows) e SQL:

Localidade do Windows Windows LCID SQL LCID Ordenação padrão
Africâner (África do Sul) 0x0436 0x0409 Latin1_General_CI_AS
Albanês (Albânia) 0x041c 0x041c Albanian_CI_AS
Alsaciano (França) 0x0484 0x0409 Latin1_General_CI_AS
Amárico (Etiópia) 0x045e 0x0409 Latin1_General_CI_AS
Árabe (Argélia) 0x1401 0x0401 Arabic_CI_AS
Árabe (Bahrein) 0x3c01 0x0401 Arabic_CI_AS
Árabe (Egito) 0x0c01 0x0401 Arabic_CI_AS
Árabe (Iraque) 0x0801 0x0401 Arabic_CI_AS
Árabe (Jordânia) 0x2c01 0x0401 Arabic_CI_AS
Árabe (Kuwait) 0x3401 0x0401 Arabic_CI_AS
Árabe (Líbano) 0x3001 0x0401 Arabic_CI_AS
Árabe (Líbia) 0x1001 0x0401 Arabic_CI_AS
Árabe (Marrocos) 0x1801 0x0401 Arabic_CI_AS
Árabe (Omã) 0x2001 0x0401 Arabic_CI_AS
Árabe (Qatar) 0x4001 0x0401 Arabic_CI_AS
Árabe (Arábia Saudita) 0x0401 0x0401 Arabic_CI_AS
Árabe (Síria) 0x2801 0x0401 Arabic_CI_AS
Árabe (Tunísia) 0x1c01 0x0401 Arabic_CI_AS
Árabe (E.U.A.) 0x3801 0x0401 Arabic_CI_AS
Árabe (Iémen) 0x2401 0x0401 Arabic_CI_AS
Arménio (Arménia) 0x042b 0x0419 Latin1_General_CI_AS
Assamese (Índia) 0x044d 0x044d Não disponível no nível do servidor
Azerbaijão (Azerbaijão, cirílico) 0x082c 0x082c Preterido, não disponível no nível do servidor
Azerbaijão (Azerbaijão, Latim) 0x042c 0x042c Preterido, não disponível no nível do servidor
Bashkir (Rússia) 0x046d 0x046d Latin1_General_CI_AI
Basco (Basco) 0x042d 0x0409 Latin1_General_CI_AS
Bielorrussa (Bielorrússia) 0x0423 0x0419 Cyrillic_General_CI_AS
Bangla (Bangladesh) 0x0845 0x0445 Não disponível no nível do servidor
Bengali (Índia) 0x0445 0x0439 Não disponível no nível do servidor
Bósnio (Bósnia e Herzegovina, cirílico) 0x201a 0x201a Latin1_General_CI_AI
Bósnio (Bósnia e Herzegovina, latino) 0x141a 0x141a Latin1_General_CI_AI
Bretão (França) 0x047e 0x047e Latin1_General_CI_AI
Búlgaro (Bulgária) 0x0402 0x0419 Cyrillic_General_CI_AS
Catalão (Catalão) 0x0403 0x0409 Latin1_General_CI_AS
Chinês (RAE de Hong Kong, RPC) 0x0c04 0x0404 Chinese_Taiwan_Stroke_CI_AS
Chinês (RAE de Macau) 0x1404 0x1404 Latin1_General_CI_AI
Chinês (RAE de Macau) 0x21404 0x21404 Latin1_General_CI_AI
Chinês (RPC) 0x0804 0x0804 Chinese_PRC_CI_AS
Chinês (RPC) 0x20804 0x20804 Chinese_PRC_Stroke_CI_AS
Chinês (Singapura) 0x1004 0x0804 Chinese_PRC_CI_AS
Chinês (Singapura) 0x21004 0x20804 Chinese_PRC_Stroke_CI_AS
Chinês (Taiwan) 0x30404 0x30404 Chinese_Taiwan_Bopomofo_CI_AS
Chinês (Taiwan) 0x0404 0x0404 Chinese_Taiwan_Stroke_CI_AS
Córsega (França) 0x0483 0x0483 Latin1_General_CI_AI
Croata (Bósnia e Herzegovina, latina) 0x101a 0x041a Croatian_CI_AS
Croata (Croácia) 0x041a 0x041a Croatian_CI_AS
Checo (República Checa) 0x0405 0x0405 Czech_CI_AS
Dinamarquês (Dinamarca) 0x0406 0x0406 Danish_Norwegian_CI_AS
Dari (Afeganistão) 0x048c 0x048c Latin1_General_CI_AI
Divehi (Maldivas) 0x0465 0x0465 Não disponível no nível do servidor
Neerlandês (Bélgica) 0x0813 0x0409 Latin1_General_CI_AS
Neerlandês (Países Baixos) 0x0413 0x0409 Latin1_General_CI_AS
Português (Portugal) 0x0c09 0x0409 Latin1_General_CI_AS
Inglês (Belize) 0x2809 0x0409 Latin1_General_CI_AS
Inglês (Canadá) 0x1009 0x0409 Latin1_General_CI_AS
Inglês (Caribe) 0x2409 0x0409 Latin1_General_CI_AS
Inglês (Índia) 0x4009 0x0409 Latin1_General_CI_AS
Inglês (Irlanda) 0x1809 0x0409 Latin1_General_CI_AS
Inglês (Jamaica) 0x2009 0x0409 Latin1_General_CI_AS
Inglês (Malásia) 0x4409 0x0409 Latin1_General_CI_AS
Inglês (Nova Zelândia) 0x1409 0x0409 Latin1_General_CI_AS
Inglês (Filipinas) 0x3409 0x0409 Latin1_General_CI_AS
Inglês (Singapura) 0x4809 0x0409 Latin1_General_CI_AS
Inglês (África do Sul) 0x1c09 0x0409 Latin1_General_CI_AS
Inglês (Trinidad e Tobago) 0x2c09 0x0409 Latin1_General_CI_AS
Inglês (Reino Unido) 0x0809 0x0409 Latin1_General_CI_AS
Inglês (Estados Unidos) 0x0409 0x0409 SQL_Latin1_General_CP1_CI_AS
Inglês (Zimbabué) 0x3009 0x0409 Latin1_General_CI_AS
Estónio (Estónia) 0x0425 0x0425 Estonian_CI_AS
Faroé (Ilhas Faroé) 0x0438 0x0409 Latin1_General_CI_AS
Filipino (Filipinas) 0x0464 0x0409 Latin1_General_CI_AS
Finlandês (Finlândia) 0x040b 0x040b Finnish_Swedish_CI_AS
Francês (Bélgica) 0x080c 0x040c French_CI_AS
Francês (Canadá) 0x0c0c 0x040c French_CI_AS
Francês (França) 0x040c 0x040c French_CI_AS
Francês (Luxemburgo) 0x140c 0x040c French_CI_AS
Francês (Mónaco) 0x180c 0x040c French_CI_AS
Francês (Suíça) 0x100c 0x040c French_CI_AS
Frísio (Países Baixos) 0x0462 0x0462 Latin1_General_CI_AI
Galego 0x0456 0x0409 Latin1_General_CI_AS
Georgiano (Geórgia) 0x10437 0x10437 Georgian_Modern_Sort_CI_AS
Georgiano (Geórgia) 0x0437 0x0419 Latin1_General_CI_AS
Alemão - Ordenação de Lista Telefónica (DIN) 0x10407 0x10407 German_PhoneBook_CI_AS
Alemão (Áustria) 0x0c07 0x0409 Latin1_General_CI_AS
Alemão (Alemanha) 0x0407 0x0409 Latin1_General_CI_AS
Alemão (Liechtenstein) 0x1407 0x0409 Latin1_General_CI_AS
Alemão (Luxemburgo) 0x1007 0x0409 Latin1_General_CI_AS
Alemão (Suíça) 0x0807 0x0409 Latin1_General_CI_AS
Grego (Grécia) 0x0408 0x0408 Greek_CI_AS
Groenlandês (Gronelândia) 0x046f 0x0406 Danish_Norwegian_CI_AS
Gujarati (Índia) 0x0447 0x0439 Não disponível no nível do servidor
Hausa (Nigéria, Latim) 0x0468 0x0409 Latin1_General_CI_AS
Hebraico (Israel) 0x040d 0x040d Hebrew_CI_AS
Hindi (Índia) 0x0439 0x0439 Não disponível no nível do servidor
Húngaro (Hungria) 0x040e 0x040e Hungarian_CI_AS
Classificação técnica húngara 0x1040e 0x1040e Hungarian_Technical_CI_AS
Islandês (Islândia) 0x040f 0x040f Icelandic_CI_AS
Igbo (Nigéria) 0x0470 0x0409 Latin1_General_CI_AS
Indonésio (Indonésia) 0x0421 0x0409 Latin1_General_CI_AS
Inuktitut (Canadá, Latino) 0x085d 0x0409 Latin1_General_CI_AS
Inuktitut (Syllabics) Canadá 0x045d 0x045d Latin1_General_CI_AI
Irlandês (Irlanda) 0x083c 0x0409 Latin1_General_CI_AS
Italiano (Itália) 0x0410 0x0409 Latin1_General_CI_AS
Italiano (Suíça) 0x0810 0x0409 Latin1_General_CI_AS
Japonês (Japão XJIS) 0x0411 0x0411 Japanese_CI_AS
Japonês (Japão) 0x040411 0x40411 Latin1_General_CI_AI
Kannada (Índia) 0x044b 0x0439 Não disponível no nível do servidor
Cazaque (Cazaquistão) 0x043f 0x043f Kazakh_90_CI_AS
Khmer (Camboja) 0x0453 0x0453 Não disponível no nível do servidor
K'iche (Guatemala) 0x0486 0x0c0a Modern_Spanish_CI_AS
Kinyarwanda (Ruanda) 0x0487 0x0409 Latin1_General_CI_AS
Konkani (Índia) 0x0457 0x0439 Não disponível no nível do servidor
Coreano (Ordenação de Dicionário da Coreia) 0x0412 0x0412 Korean_Wansung_CI_AS
Quirguistão (Quirguistão) 0x0440 0x0419 Cyrillic_General_CI_AS
Laos (RDP do Laos) 0x0454 0x0454 Não disponível no nível do servidor
Letão (Letónia) 0x0426 0x0426 Latvian_CI_AS
Lituano (Lituânia) 0x0427 0x0427 Lithuanian_CI_AS
Baixo Sorbiano (Alemanha) 0x082e 0x0409 Latin1_General_CI_AS
Luxemburguês (Luxemburgo) 0x046e 0x0409 Latin1_General_CI_AS
Macedónio (Macedónia do Norte) 0x042f 0x042f Macedonian_FYROM_90_CI_AS
Malaio (Brunei Darussalam) 0x083e 0x0409 Latin1_General_CI_AS
Malaio (Malásia) 0x043e 0x0409 Latin1_General_CI_AS
Malaiala (Índia) 0x044c 0x0439 Não disponível no nível do servidor
Maltês (Malta) 0x043a 0x043a Latin1_General_CI_AI
Maori (Nova Zelândia) 0x0481 0x0481 Latin1_General_CI_AI
Mapudungun (Chile) 0x047a 0x047a Latin1_General_CI_AI
Marathi (Índia) 0x044e 0x0439 Não disponível no nível do servidor
Mohawk (Canadá) 0x047c 0x047c Latin1_General_CI_AI
Mongol (Mongólia) 0x0450 0x0419 Cyrillic_General_CI_AS
Mongoliano (RPC) 0x0850 0x0419 Cyrillic_General_CI_AS
Nepalês (Nepal) 0x0461 0x0461 Não disponível no nível do servidor
Norueguês (Bokmål, Noruega) 0x0414 0x0414 Latin1_General_CI_AI
Norueguês (Nynorsk, Noruega) 0x0814 0x0414 Latin1_General_CI_AI
Occitano (França) 0x0482 0x040c French_CI_AS
Odia (Índia) 0x0448 0x0439 Não disponível no nível do servidor
Pashto (Afeganistão) 0x0463 0x0463 Não disponível no nível do servidor
Persa (Irão) 0x0429 0x0429 Latin1_General_CI_AI
Polaco (Polónia) 0x0415 0x0415 Polish_CI_AS
Português (Brasil) 0x0416 0x0409 Latin1_General_CI_AS
Português (Portugal) 0x0816 0x0409 Latin1_General_CI_AS
Punjabi (Índia) 0x0446 0x0439 Não disponível no nível do servidor
Quéchua (Bolívia) 0x046b 0x0409 Latin1_General_CI_AS
Quéchua (Equador) 0x086b 0x0409 Latin1_General_CI_AS
Quéchua (Peru) 0x0c6b 0x0409 Latin1_General_CI_AS
Romeno (Roménia) 0x0418 0x0418 Romanian_CI_AS
Romanche (Suíça) 0x0417 0x0417 Latin1_General_CI_AI
Russo (Rússia) 0x0419 0x0419 Cyrillic_General_CI_AS
Sahka (Rússia) 0x0485 0x0485 Latin1_General_CI_AI
Sami (Inari, Finlândia) 0x243b 0x083b Latin1_General_CI_AI
Sami (Lule, Noruega) 0x103b 0x043b Latin1_General_CI_AI
Sami (Lule, Suécia) 0x143b 0x083b Latin1_General_CI_AI
Sami (Norte, Finlândia) 0x0c3b 0x083b Latin1_General_CI_AI
Sami (Norte, Noruega) 0x043b 0x043b Latin1_General_CI_AI
Sami (Norte, Suécia) 0x083b 0x083b Latin1_General_CI_AI
Sami (Skolt, Finlândia) 0x203b 0x083b Latin1_General_CI_AI
Sami (Sul, Noruega) 0x183b 0x043b Latin1_General_CI_AI
Sami (Sul, Suécia) 0x1c3b 0x083b Latin1_General_CI_AI
Sânscrito (Índia) 0x044f 0x0439 Não disponível no nível do servidor
Sérvio (Bósnia e Herzegovina, cirílico) 0x1c1a 0x0c1a Latin1_General_CI_AI
Sérvio (Bósnia e Herzegovina, latino) 0x181a 0x081a Latin1_General_CI_AI
Sérvio (Sérvia, cirílico) 0x0c1a 0x0c1a Latin1_General_CI_AI
Sérvio (Sérvia, alfabeto latino) 0x081a 0x081a Latin1_General_CI_AI
Sesotho sa Leboa/Northern Sotho (África do Sul) 0x046c 0x0409 Latin1_General_CI_AS
Setswana/Tswana (África do Sul) 0x0432 0x0409 Latin1_General_CI_AS
Cingalês (Sri Lanka) 0x045b 0x0439 Não disponível no nível do servidor
Eslovaco (Eslováquia) 0x041b 0x041b Slovak_CI_AS
Esloveno (Eslovénia) 0x0424 0x0424 Slovenian_CI_AS
Espanhol (Argentina) 0x2c0a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Bolívia) 0x400a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Chile) 0x340a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Colômbia) 0x240a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Costa Rica) 0x140a 0x0c0a Modern_Spanish_CI_AS
Espanhol (República Dominicana) 0x1c0a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Equador) 0x300a 0x0c0a Modern_Spanish_CI_AS
Espanhol (El Salvador) 0x440a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Guatemala) 0x100a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Honduras) 0x480a 0x0c0a Modern_Spanish_CI_AS
Espanhol (México) 0x080a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Nicarágua) 0x4c0a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Panamá) 0x180a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Paraguai) 0x3c0a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Peru) 0x280a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Porto Rico) 0x500a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Espanha) 0x0c0a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Espanha, Classificação Tradicional) 0x040a 0x040a Traditional_Spanish_CI_AS
Espanhol (Estados Unidos) 0x540a 0x0409 Latin1_General_CI_AS
Espanhol (Uruguai) 0x380a 0x0c0a Modern_Spanish_CI_AS
Espanhol (Venezuela) 0x200a 0x0c0a Modern_Spanish_CI_AS
Swahili (Quênia) 0x0441 0x0409 Latin1_General_CI_AS
Sueco (Finlândia) 0x081d 0x040b Finnish_Swedish_CI_AS
Sueco (Suécia) 0x041d 0x040b Finnish_Swedish_CI_AS
Siríaco (Síria) 0x045a 0x045a Não disponível no nível do servidor
Tajiquistão (Tajiquistão) 0x0428 0x0419 Cyrillic_General_CI_AS
Tamazight (Argélia, Latin) 0x085f 0x085f Latin1_General_CI_AI
Tâmil (Índia) 0x0449 0x0439 Não disponível no nível do servidor
Tártaro (Rússia) 0x0444 0x0444 Cyrillic_General_CI_AS
Telugu (Índia) 0x044a 0x0439 Não disponível no nível do servidor
Tailandês (Tailândia) 0x041e 0x041e Thai_CI_AS
Tibetano (RPC) 0x0451 0x0451 Não disponível no nível do servidor
Turco (Turquia) 0x041f 0x041f Turkish_CI_AS
Turcomeno (Turquemenistão) 0x0442 0x0442 Latin1_General_CI_AI
Uigur (RPC) 0x0480 0x0480 Latin1_General_CI_AI
Ucraniano (Ucrânia) 0x0422 0x0422 Ukrainian_CI_AS
Alto Sorbian (Alemanha) 0x042e 0x042e Latin1_General_CI_AI
Urdu (Paquistão) 0x0420 0x0420 Latin1_General_CI_AI
Uzbeque (Uzbequistão, cirílico) 0x0843 0x0419 Cyrillic_General_CI_AS
Uzbeque (Uzbequistão, latim) 0x0443 0x0443 Uzbek_Latin_90_CI_AS
Vietnamita (Vietname) 0x042a 0x042a Vietnamese_CI_AS
Galês (Reino Unido) 0x0452 0x0452 Latin1_General_CI_AI
Wolof (Senegal) 0x0488 0x040c French_CI_AS
Xhosa/isiXhosa (África do Sul) 0x0434 0x0409 Latin1_General_CI_AS
Yi (RPC) 0x0478 0x0409 Latin1_General_CI_AS
Yoruba (Nigéria) 0x046a 0x0409 Latin1_General_CI_AS
Zulu/isiZulu (África do Sul) 0x0435 0x0409 Latin1_General_CI_AS

Depois de atribuir um agrupamento ao servidor, você pode alterá-lo somente exportando todos os objetos e dados do banco de dados, reconstruindo o banco de dados master e importando todos os objetos e dados do banco de dados. Em vez de alterar o agrupamento padrão de uma instância do SQL Server, você pode especificar o agrupamento desejado ao criar um novo banco de dados ou coluna de banco de dados.

Para consultar o agrupamento de servidores para uma instância do SQL Server, use a função SERVERPROPERTY:

SELECT CONVERT (NVARCHAR (128), SERVERPROPERTY('collation'));

Para consultar o servidor sobre todos os agrupamentos disponíveis, use a seguinte função interna fn_helpcollations():

SELECT *
FROM sys.fn_helpcollations();

Agrupamentos no Banco de Dados SQL do Azure

Você não pode alterar ou definir o agrupamento de servidor lógico no Banco de Dados SQL do Azure, mas pode configurar os agrupamentos de cada banco de dados para dados e para o catálogo. O agrupamento de catálogo determina o agrupamento de metadados do sistema, como identificadores de objeto. Ambos os agrupamentos podem ser especificados independentemente quando você criar o banco de dados no portal do Azure, em T-SQL com CREATE DATABASE, no PowerShell com New-AzSqlDatabase.

Colações na Instância Gerida SQL do Azure

O agrupamento no nível do servidor na Instância Gerenciada SQL do Azure pode ser especificado quando a instância é criada e não pode ser alterado posteriormente.

Para obter mais informações, consulte Definir ou alterar o agrupamento do servidor.

Agrupamentos no nível de banco de dados

Ao criar ou modificar um banco de dados, você pode usar a cláusula COLLATE da instrução CREATE DATABASE ou ALTER DATABASE para especificar o agrupamento de banco de dados padrão. Se nenhum agrupamento for especificado, a base de dados será atribuída ao agrupamento do servidor.

Não é possível alterar o agrupamento de bancos de dados do sistema, a menos que você altere o agrupamento para o servidor.

  • No SQL Server e na Instância Gerenciada SQL do Azure, o agrupamento de banco de dados é usado para todos os metadados no banco de dados e o agrupamento é o padrão para todas as colunas de cadeia de caracteres, objetos temporários, nomes de variáveis e quaisquer outras cadeias de caracteres usadas no banco de dados.
  • No Banco de Dados SQL do Azure, não há agrupamento de servidor, portanto, cada banco de dados tem um agrupamento para dados e um agrupamento para o catálogo. O CATALOG_COLLATION é usado para todos os metadados no banco de dados e o agrupamento é o padrão para todas as colunas de cadeia de caracteres, objetos temporários, nomes de variáveis e quaisquer outras cadeias de caracteres usadas no banco de dados. O CATALOG_COLLATION é definido no momento da criação e não pode ser alterado.

Quando você altera o agrupamento de um banco de dados de usuário, pode haver conflitos de agrupamento quando consultas no banco de dados acessam tabelas temporárias. As tabelas temporárias são sempre armazenadas no banco de dados do sistema tempdb, que usa o agrupamento para a instância. As consultas que comparam dados de caracteres entre o banco de dados do usuário e o tempdb podem falhar se os agrupamentos causarem um conflito na avaliação dos dados de caracteres. Você pode resolver esse problema especificando a cláusula COLLATE na consulta. Para obter mais informações, consulte COLLATE.

Você pode alterar o agrupamento de um banco de dados de usuário usando uma instrução ALTER DATABASE semelhante ao exemplo de código a seguir:

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Importante

Alterar o agrupamento no nível do banco de dados não afeta os agrupamentos no nível da coluna ou no nível da expressão. Não afeta os dados nas colunas existentes.

Você pode recuperar o agrupamento atual de um banco de dados usando uma instrução semelhante ao exemplo de código a seguir:

SELECT CONVERT (NVARCHAR (128), DATABASEPROPERTYEX('database_name', 'collation'));

Agrupamentos em nível de coluna

Ao criar ou alterar uma tabela, você pode especificar agrupamentos para cada coluna de cadeia de caracteres usando a cláusula COLLATE. Se você não especificar um agrupamento, será atribuído à coluna o agrupamento padrão do banco de dados.

Você pode alterar o agrupamento de uma coluna usando uma instrução ALTER TABLE semelhante ao exemplo de código a seguir:

ALTER TABLE myTable ALTER COLUMN mycol NVARCHAR (10) COLLATE Greek_CS_AI;

Colações ao nível da expressão

Os agrupamentos no nível da expressão são definidos quando uma instrução é executada e afetam a maneira como um conjunto de resultados é retornado. Isso permite que os resultados de classificação de ORDER BY sejam específicos da localidade. Para implementar agrupamentos no nível da expressão, use uma cláusula COLLATE, como o exemplo de código a seguir:

SELECT name
FROM customer
ORDER BY name COLLATE Latin1_General_CS_AI;

Localidade

Uma localidade é um conjunto de informações associadas a um local ou a uma cultura. As informações podem incluir o nome e o identificador da língua falada, o script usado para escrever a língua e as convenções culturais. Os agrupamentos podem ser associados a uma ou mais localizações. Para obter mais informações, consulte Identificadores de Localidade atribuídos pela Microsoft.

Página de código

Uma página de código é um conjunto ordenado de caracteres de um determinado script no qual um índice numérico, ou valor de ponto de código, é associado a cada caractere. Uma página de código do Windows é normalmente referida como um conjunto de caracteres ou um conjunto de caracteres . As páginas de código são usadas para fornecer suporte para os conjuntos de caracteres e layouts de teclado que são usados por diferentes localidades do sistema Windows.

Ordem de classificação

A ordem de classificação especifica como os valores de dados são classificados. A ordem afeta os resultados da comparação de dados. Os dados são classificados usando agrupamentos e podem ser otimizados usando índices.

Suporte a Unicode

Unicode é um padrão para mapear pontos de código para caracteres. Como ele foi projetado para cobrir todos os caracteres de todos os idiomas do mundo, você não precisa de páginas de código diferentes para lidar com diferentes conjuntos de caracteres.

Noções básicas de Unicode

O armazenamento de dados em vários idiomas em um banco de dados é difícil de gerenciar quando você usa apenas dados de caracteres e páginas de código. Também é difícil encontrar uma página de código para o banco de dados que possa armazenar todos os caracteres específicos do idioma necessários. Além disso, é difícil garantir a tradução correta de caracteres especiais quando eles estão sendo lidos ou atualizados por uma variedade de clientes que estão executando várias páginas de código. Os bancos de dados que oferecem suporte a clientes internacionais devem sempre usar tipos de dados Unicode em vez de tipos de dados não-Unicode.

Por exemplo, considere um banco de dados de clientes na América do Norte que deve lidar com três idiomas principais:

  • Nomes e endereços em espanhol para México
  • Nomes e endereços franceses para Quebec
  • Nomes e endereços em inglês para o resto do Canadá e dos Estados Unidos

Ao usar apenas colunas de caracteres e páginas de código, você deve tomar cuidado para garantir que o banco de dados seja instalado com uma página de código que manipulará os caracteres dos três idiomas. Você também deve ter o cuidado de garantir a tradução correta de caracteres de qualquer um dos idiomas quando os caracteres são lidos por clientes que estão executando uma página de código para outro idioma.

Observação

As páginas de código que um cliente usa são determinadas pelas configurações do sistema operacional (SO). Para definir páginas de código de cliente no sistema operacional Windows, use Configurações Regionais no Painel de Controle.

Seria difícil selecionar uma página de código para tipos de dados de caracteres que suportassem todos os caracteres exigidos por um público mundial. A maneira mais fácil de gerenciar dados de caracteres em bancos de dados internacionais é sempre usar um tipo de dados que ofereça suporte a Unicode.

Tipos de dados Unicode

Se você armazenar dados de caracteres que reflitam vários idiomas no SQL Server (SQL Server 2005 (9.x) e posterior), use tipos de dados Unicode (nchar, nvarchare ntext) em vez de tipos de dados não-Unicode (char, varchare texto).

Observação

Para tipos de dados Unicode, a Engine de Base de Dados pode representar até 65.536 caracteres utilizando UCS-2, ou a gama completa do Unicode (1.114.112 caracteres) se forem utilizados caracteres suplementares. Para obter mais informações sobre como habilitar caracteres suplementares, consulte Supplementary Characters.

Como alternativa, a partir do SQL Server 2019 (15.x), se um agrupamento habilitado para UTF-8 (_UTF8) for usado, tipos de dados anteriormente não Unicode (char e varchar) se tornarão tipos de dados Unicode usando codificação UTF-8. O SQL Server 2019 (15.x) não altera o comportamento de tipos de dados Unicode existentes anteriormente (nchar, nvarchare ntext), que continuam a usar codificação UCS-2 ou UTF-16. Para obter mais informações, consulte Diferenças de armazenamento entre UTF-8 e UTF-16.

Considerações sobre Unicode

Limitações significativas estão associadas a tipos de dados não-Unicode. Isso ocorre porque um computador não-Unicode está limitado a usar uma única página de código. Você pode experimentar ganho de desempenho usando Unicode, porque requer menos conversões de página de código. Os agrupamentos Unicode devem ser selecionados individualmente no nível do banco de dados, coluna ou expressão, pois não são suportados no nível do servidor.

Quando você move dados de um servidor para um cliente, o agrupamento do servidor pode não ser reconhecido por drivers de cliente mais antigos. Isso pode ocorrer quando você move dados de um servidor Unicode para um cliente não-Unicode. Sua melhor opção pode ser atualizar o sistema operacional cliente para que os agrupamentos do sistema subjacente sejam atualizados. Se o cliente tiver software cliente de banco de dados instalado, você pode considerar a aplicação de uma atualização de serviço ao software cliente de banco de dados.

Dica

Você também pode tentar usar um agrupamento diferente para os dados no servidor. Escolha um agrupamento que mapeie para uma página de código no cliente. Para usar os agrupamentos UTF-16 disponíveis no SQL Server (SQL Server 2012 (11.x) e posterior) para melhorar a pesquisa e a classificação de alguns caracteres Unicode (somente agrupamentos do Windows), você pode selecionar um dos agrupamentos de caracteres suplementares (_SC) ou um dos agrupamentos da versão 140.

Para usar os agrupamentos UTF-8 disponíveis no SQL Server 2019 (15.x) e para melhorar a pesquisa e a classificação de alguns caracteres Unicode (somente agrupamentos do Windows), você deve selecionar agrupamentos habilitados para codificação UTF-8 (_UTF8).

  • O sinalizador UTF8 pode ser aplicado a:

    • Colações linguísticas que já suportam caracteres suplementares (_SC) ou estão adaptadas a seletores de variação (_VSS)
    • Agrupamento binário BIN2

  • O sinalizador UTF8 não pode ser aplicado a:

    • Ordenações linguísticas que não suportam caracteres suplementares (_SC) ou sensibilidade ao seletor de variação (_VSS)
    • Os agrupamentos binários BIN
    • Os agrupamentos SQL_*

Para avaliar problemas relacionados ao uso de tipos de dados Unicode ou não-Unicode, teste seu cenário para medir as diferenças de desempenho em seu ambiente. É uma boa prática padronizar o agrupamento usado em sistemas em toda a organização e implantar servidores e clientes Unicode sempre que possível.

Em muitas situações, o SQL Server interage com outros servidores ou clientes, e sua organização pode usar vários padrões de acesso a dados entre aplicativos e instâncias de servidor. Os clientes do SQL Server são um dos dois tipos principais:

  • clientes Unicode que usam OLE DB e ODBC (Conectividade de Base de Dados Aberta) versão 3.7 ou mais recente.
  • Clientes não-Unicode que usam DB-Library e ODBC versão 3.6 ou anterior.

A tabela a seguir fornece informações sobre como usar dados multilíngues com várias combinações de servidores Unicode e não-Unicode:

Servidor Cliente Benefícios ou limitações
Unicode Unicode Como os dados Unicode são usados em todo o sistema, esse cenário oferece o melhor desempenho e proteção contra corrupção de dados recuperados. Esta é a situação com ActiveX Data Objects (ADO), OLE DB e ODBC versão 3.7 ou posterior.
Unicode Fora do padrão Unicode Nesse cenário, especialmente com conexões entre um servidor que está executando um sistema operacional mais recente e um cliente que está executando uma versão anterior do SQL Server, ou em um sistema operacional mais antigo, pode haver limitações ou erros quando você move dados para um computador cliente. Os dados Unicode no servidor tentam corresponder a uma página de código equivalente num cliente que não utiliza Unicode, para converter os dados.
Fora do padrão Unicode Unicode Esta não é uma configuração ideal para usar dados multilíngues. Não é possível gravar dados Unicode no servidor não-Unicode. É provável que ocorram problemas quando os dados são enviados para servidores que estão fora da página de código do servidor.
Fora do padrão Unicode Fora do padrão Unicode Este é um cenário muito limitativo para dados multilingues. Você pode usar apenas uma única página de código.

Caracteres suplementares

O Unicode Consortium aloca a cada caractere um ponto de código exclusivo, que é um valor no intervalo 000000 - 10FFFF. Os caracteres usados com mais freqüência têm valores de ponto de código no intervalo 000000 - 00FFFF (65.536 caracteres) que se encaixam em uma palavra de 8 bits ou 16 bits na memória e no disco. Este intervalo é geralmente designado como Plano Multilingue Básico (BMP).

Mas o Unicode Consortium estabeleceu 16 "planos" adicionais de caracteres, cada um do mesmo tamanho que o BMP. Esta definição permite que o Unicode tenha o potencial de representar 1.114.112 caracteres (ou seja, 216 * 17 caracteres) dentro do intervalo de pontos de código 000000 - 10FFFF. Caracteres com valor de ponto de código maior que 00FFFF requerem duas a quatro palavras consecutivas de 8 bits (UTF-8) ou duas palavras consecutivas de 16 bits (UTF-16). Esses caracteres localizados além do BMP são chamados caracteres suplementares, e as palavras adicionais consecutivas de 8 bits ou 16 bits são chamadas de pares substitutos . Para obter mais informações sobre caracteres suplementares, substitutos e pares substitutos, consulte o Unicode Standard.

O SQL Server fornece tipos de dados como nchar e nvarchar para armazenar dados Unicode no intervalo BMP (000000 - 00FFFF), que o Mecanismo de Banco de Dados codifica usando UCS-2.

O SQL Server 2012 (11.x) introduziu uma nova família de agrupamentos de caracteres suplementares (_SC) que podem ser usados com os nchar, nvarchare sql_variant tipos de dados para representar o intervalo de caracteres Unicode completo (000000 - 10FFFF). Por exemplo: Latin1_General_100_CI_AS_SC ou, se você estiver usando um agrupamento japonês, Japanese_Bushu_Kakusu_100_CI_AS_SC.

O SQL Server 2019 (15.x) estende o suporte suplementar a caracteres para os tipos de dados char e varchar com os novos agrupamentos habilitados para UTF-8 (_UTF8). Esses tipos de dados também são capazes de representar o intervalo completo de caracteres Unicode.

Observação

A partir do SQL Server 2017 (14.x), todos os novos agrupamentos oferecem suporte automaticamente a caracteres suplementares.

Ao utilizar caracteres suplementares:

  • Caracteres suplementares podem ser usados em operações de ordenação e comparação em versões de agrupamento 90 ou superiores.

  • Todos os agrupamentos da versão 100 suportam classificação linguística com caracteres suplementares.

  • Não há suporte para caracteres suplementares para uso em metadados, como nomes de objetos de banco de dados.

  • A bandeira SC pode ser aplicada a:

    • Colações da versão 90
    • Agrupamentos da versão 100

  • O sinalizador SC não pode ser aplicado a:

    • Agrupamentos do Windows sem versão da versão 80
    • As agregações binárias BIN ou BIN2
    • As colações SQL*
    • Agrupamentos da versão 140 (estes não precisam da bandeira SC, porque já suportam caracteres suplementares)

A tabela a seguir compara o comportamento de algumas funções de cadeia de caracteres e operadores de cadeia de caracteres quando eles usam caracteres suplementares com e sem um agrupamento com reconhecimento de caracteres suplementares (SCA):

Função ou operador de cadeia de caracteres Com uma colagem SCA Sem um agrupamento SCA
CHARINDEX

LEN
PATINDEX		 O par substituto UTF-16 é contado como um único ponto de código. O par substituto UTF-16 é contado como dois pontos de código.
ESQUERDA

SUBSTITUIR
REVERSO
DIREITO
SUBSTRING
COISAS		 Essas funções tratam cada par substituto como um único ponto de código e funcionam conforme o esperado. Essas funções podem dividir quaisquer pares substitutos e levar a resultados inesperados.
NCHAR Retorna o caractere que corresponde ao valor de ponto de código Unicode especificado no intervalo 0 - 0x10FFFF. Se o valor especificado estiver no intervalo 0 - 0xFFFF, um caractere será retornado. Para valores mais altos, o substituto correspondente é retornado. Um valor superior a 0xFFFF retorna NULL em vez do substituto correspondente.
UNICODE Retorna um ponto de código UTF-16 no intervalo 0 - 0x10FFFF. Retorna um ponto de código UCS-2 no intervalo 0 - 0xFFFF.
Combinação coringa de um caractere

Curinga - Caractere(s) que não correspondem a		 Caracteres suplementares são suportados para todas as operações curinga. Não há suporte para caracteres suplementares para essas operações curinga. Outros operadores curinga são suportados.

Suporte GB18030

GB18030 é um padrão separado que é usado na República Popular da China para codificar caracteres chineses. No GB18030, os caracteres podem ter 1, 2 ou 4 bytes de comprimento. O SQL Server fornece suporte para caracteres codificados em GB18030, reconhecendo-os quando entram no servidor a partir de um aplicativo do lado do cliente e convertendo-os e armazenando-os nativamente como caracteres Unicode. Depois de armazenados no servidor, eles são tratados como caracteres Unicode em quaisquer operações subsequentes.

Você pode usar qualquer ordenação chinesa, de preferência a versão 100 mais recente. Todas as classificações da versão 100 suportam classificação linguística com caracteres GB18030. Se os dados incluírem caracteres suplementares (pares substitutos), você poderá usar os agrupamentos SC disponíveis no SQL Server para melhorar a pesquisa e a classificação.

Observação

Certifique-se de que suas ferramentas de cliente, como o SQL Server Management Studio, usem a fonte Dengxian para exibir corretamente cadeias de caracteres que contenham caracteres codificados em GB18030.

Suporte a scripts complexos

O SQL Server pode dar suporte à entrada, armazenamento, alteração e exibição de scripts complexos. Os scripts complexos incluem os seguintes tipos:

  • Scripts que incluem a combinação de texto da direita para a esquerda e da esquerda para a direita, como uma combinação de texto em árabe e inglês.
  • Scripts cujos caracteres mudam de forma dependendo de sua posição, ou quando combinados com outros caracteres, como caracteres árabes, índicos e tailandeses.
  • Línguas, como o tailandês, que exigem dicionários internos para reconhecer palavras porque não há intervalos entre elas.

Os aplicativos de banco de dados que interagem com o SQL Server devem usar controles que ofereçam suporte a scripts complexos. Os controles de formulário padrão do Windows criados em código gerenciado são habilitados para scripts complexos.

Agrupamentos japoneses adicionados no SQL Server 2017

A partir do SQL Server 2017 (14.x), há suporte para novas famílias de agrupamento japonesas, com as permutações de várias opções (_CS, _AS, _KS, _WSe _VSS), bem como _BIN e _BIN2.

Para listar esses agrupamentos, você pode consultar o Mecanismo de Banco de Dados do SQL Server:

SELECT name,
       description
FROM sys.fn_helpcollations()
WHERE COLLATIONPROPERTY(name, 'Version') = 3;

Todas as novas ordenações têm suporte interno para caracteres suplementares, portanto, nenhuma das novas ordenações de 140 tem (ou precisa) da marca SC.

Esses agrupamentos são suportados em índices do Mecanismo de Banco de Dados, tabelas com otimização de memória, índices columnstore e módulos compilados nativamente.

Suporte UTF-8

O SQL Server 2019 (15.x) apresenta suporte total para a codificação de caracteres UTF-8 amplamente usada como uma codificação de importação ou exportação e como agrupamento em nível de banco de dados ou de coluna para dados de cadeia de caracteres. UTF-8 é permitido nos tipos de dados char e varchar e , e é ativado quando se cria ou altera a intercalação de um objeto para uma intercalação que tem um sufixo UTF8 . Um exemplo é a mudança de Latin1_General_100_CI_AS_SC para Latin1_General_100_CI_AS_SC_UTF8.

UTF-8 está disponível apenas para agrupamentos do Windows que oferecem suporte a caracteres suplementares, conforme introduzido no SQL Server 2012 (11.x). Os tipos de dados nchar e nvarchar permitem apenas a codificação UCS-2 ou UTF-16 e permanecem inalterados.

O Banco de Dados SQL do Azure e a Instância Gerenciada SQL do Azure também oferecem suporte a UTF-8 no nível de banco de dados e coluna, enquanto a Instância Gerenciada SQL também oferece suporte a isso em nível de servidor.

Diferenças de armazenamento entre UTF-8 e UTF-16

O Unicode Consortium aloca a cada caractere um ponto de código exclusivo, que é um valor no intervalo 000000 - 10FFFF. Com o SQL Server 2019 (15.x), as codificações UTF-8 e UTF-16 estão disponíveis para representar o intervalo completo:

  • Com a codificação UTF-8, os caracteres no intervalo ASCII (000000 - 00007F) requerem 1 byte, os pontos de código 000080 - 0007FF requerem 2 bytes, os pontos de código 000800 - 00FFFF requerem 3 bytes e os pontos de código 0010000 - 0010FFFF requerem 4 bytes.
  • Com a codificação UTF-16, os pontos de código 000000 - 00FFFF requerem 2 bytes e os pontos de código 0010000 - 0010FFFF requerem 4 bytes.

A tabela a seguir lista os bytes de armazenamento de codificação para cada intervalo de caracteres e tipo de codificação:

Intervalo de códigos (hexadecimal) Intervalo de códigos (decimal) Bytes de armazenamento 1 com UTF-8 Bytes de armazenamento 1 com UTF-16
000000 - 00007F 0 - 127 1 2
000080 - 00009F
0000A0 - 0003FF
000400 - 0007FF		 128 - 159
160 - 1,023
1,024 - 2,047		 2 2
000800 - 003FFF
004000 - 00FFFF		 2,048 - 16,383
16,384 - 65,535		 3 2
010000 - 03FFFF 2

040000 - 10FFFF 2		 65.536 - 262.143 2
262.144 - 1.114.111 2		 4 4

1bytes de armazenamento referem-se ao comprimento codificado em bytes, não ao tamanho de armazenamento em disco do tipo de dados. Para obter mais informações sobre tamanhos de armazenamento em disco, consulte nchar e nvarchar e char e varchar.

2 O intervalo de pontos de código para caracteres suplementares.

Dica

É uma perceção comum, em char e varchar ou em nchar e nvarchar, que n define o número de caracteres. Isso ocorre porque, no exemplo de uma coluna de char(10) , 10 caracteres ASCII no intervalo 0 - 127 podem ser armazenados usando um agrupamento como , porque cada caractere nesse intervalo usa apenas 1 byte. No entanto, em char e varchar, n define o tamanho da cadeia em bytes (0 - 8.000), e em nchar e nvarchar, n define o tamanho da cadeia em pares de bytes (0 - 4.000). n nunca define o número de caracteres que podem ser armazenados.

Escolher a codificação Unicode apropriada e o tipo de dados pode proporcionar economias significativas de armazenamento ou aumentar sua pegada de armazenamento atual, dependendo do conjunto de caracteres em uso. Por exemplo, quando você usa um agrupamento latino habilitado para UTF-8, como , uma coluna de char(10) armazena 10 bytes e pode conter 10 caracteres ASCII no intervalo de 0 a 127. Mas ele pode conter apenas cinco caracteres no intervalo 128 - 2047 e apenas três caracteres no intervalo 2048 - 65535. Em comparação, como uma coluna nchar(10) armazena 10 pares de bytes (20 bytes), ela pode conter 10 caracteres no intervalo 0 - 65535.

Antes de decidir se deseja usar a codificação UTF-8 ou UTF-16 para um banco de dados ou coluna, considere a distribuição de dados de cadeia de caracteres que serão armazenados:

  • Se estiver principalmente no intervalo ASCII de 0 a 127 (como o inglês), cada caractere requer 1 byte com UTF-8 e 2 bytes com UTF-16. O uso do UTF-8 oferece benefícios de armazenamento. Alterar um tipo de dados de coluna existente com caracteres ASCII no intervalo de 0 a 127 de nchar(10) para char(10)e usar um agrupamento habilitado para UTF-8 se traduz em uma redução de 50% nos requisitos de armazenamento. Essa redução ocorre porque nchar(10) requer 20 bytes para armazenamento, em comparação com char(10), que requer 10 bytes para a mesma representação de cadeia de caracteres Unicode.
  • Acima do intervalo ASCII, quase todos os scripts baseados em latim e grego, cirílico, copta, armênio, hebraico, árabe, siríaco, Tāna e N'Ko exigem 2 bytes por caractere em UTF-8 e UTF-16. Nesses casos, não há diferenças significativas de armazenamento para tipos de dados comparáveis (por exemplo, entre o uso de char ou nchar).
  • Se for principalmente script do Leste Asiático (como coreano, chinês e japonês), cada caractere requer 3 bytes com UTF-8 e 2 bytes com UTF-16. O uso do UTF-16 oferece benefícios de armazenamento.
  • Os caracteres no intervalo 010000 - 10FFFF requerem 4 bytes em UTF-8 e UTF-16. Nesses casos, não há diferenças de armazenamento para tipos de dados comparáveis (por exemplo, entre usar char ou nchar).

Para outras considerações, consulte Write International Transact-SQL Statements.

Converter para UTF-8

Como char e varchar ou em nchar e nvarchar, o n define o tamanho de armazenamento de bytes, não o número de caracteres que podem ser armazenados, é importante determinar o tamanho do tipo de dados para o qual você deve converter. Os caracteres que excederem o tamanho devem ser truncados.

Por exemplo, considere uma coluna definida como nvarchar(100) que armazena 180 bytes de caracteres japoneses. Neste exemplo, os dados da coluna são atualmente codificados usando UCS-2 ou UTF-16, que usa 2 bytes por caractere. Converter o tipo de coluna em varchar(200) não é suficiente para impedir o truncamento de dados, porque o novo tipo de dados só pode armazenar 200 bytes, mas os caracteres japoneses exigem 3 bytes quando codificados em UTF-8. A coluna deve ser definida como varchar(270) para evitar a perda de dados através do truncamento de dados.

Portanto, você deve saber com antecedência qual é o tamanho de byte projetado para a definição de coluna, antes de converter dados existentes para UTF-8, e ajustar o novo tamanho de tipo de dados de acordo. Consulte o script Transact-SQL ou o Bloco de Anotações SQL noGitHub Data Samples, que usam a função DATALENGTH e a instrução COLLATE, para determinar os requisitos de comprimento de dados apropriados para operações de conversão UTF-8 em um banco de dados existente.

Para alterar o agrupamento de colunas e o tipo de dados em uma tabela existente, use um dos métodos descritos em Definir ou alterar o agrupamento de colunas.

Para alterar o agrupamento de banco de dados, permitindo que novos objetos herdem o agrupamento de banco de dados por padrão, ou para alterar o agrupamento de servidor, permitindo que novos bancos de dados herdem o agrupamento do sistema por padrão, consulte a seção Tarefas relacionadas deste artigo.

Tarefa Artigo
Descreve como definir ou alterar o agrupamento da instância do SQL Server. Alterar o agrupamento do servidor não altera o agrupamento de bancos de dados existentes. Definir ou alterar o agrupamento do servidor
Descreve como definir ou alterar o agrupamento de um banco de dados de usuário. A alteração de um agrupamento de banco de dados não altera o agrupamento de colunas de tabela existentes. Definir ou alterar o agrupamento do banco de dados
Descreve como definir ou alterar o agrupamento de uma coluna no banco de dados. Definir ou alterar o agrupamento de colunas
Descreve como retornar informações de colação ao nível do servidor, da base de dados ou da coluna. Exibir informações de agrupamento
Descreve como escrever instruções Transact-SQL que são mais portáteis de um idioma para outro ou oferecem suporte a vários idiomas com mais facilidade. Escrever declarações Transact-SQL internacionais
Descreve como alterar o idioma das mensagens de erro e as preferências de como os dados de data, hora e moeda são usados e exibidos. Definir um idioma de sessão

Conteúdo relacionado