Suporte a ordenações e Unicode

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do AzureAzure Synapse AnalyticsPDW (Analytics Platform System)Ponto de extremidade de SQL no Microsoft FabricWarehouse no Microsoft Fabric

As ordenações em SQL Server fornecem propriedades de regras de classificação, de diferenciação de maiúsculas e minúsculas e de diferenciação de acentos para seus dados. As ordenações usadas com tipos de dados de caractere, como char e varchar, determinam a página de código e os caracteres correspondentes que podem ser representados para esse tipo de dados.

Independentemente de você estar 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 estar ciente dos requisitos de localidade, da ordem de classificação e da diferenciação de maiúsculas e minúsculas e de acentos dos dados com os quais você está trabalhando. Para listar as ordenações disponíveis na instância do SQL Server, confira sys.fn_helpcollations (Transact-SQL).

Ao selecionar uma ordenação para o servidor, o banco de dados, a coluna ou a expressão, você atribui determinadas características aos dados. Essas características afetam os resultados de muitas operações no banco de dados. Por exemplo, ao construir uma consulta usando ORDER BY, a ordem de classificação do conjunto de resultados poderá depender da ordenação aplicada ao banco de dados ou determinada em uma cláusula COLLATE no nível de expressão da consulta.

Para usar melhor o suporte para ordenação 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 ordenação

Collation

Uma ordenação especifica os padrões de bit que representam cada caractere em um conjunto de dados. As ordenações também determinam as regras que classificam e comparam dados. SQL Server dá suporte ao armazenamento de objetos com ordenações diferentes em um banco de dados individual. Para colunas não Unicode, a configuração de ordenação especifica a página de códigos dos dados e quais caracteres podem ser representados. Os dados movidos entre colunas não Unicode precisam ser convertidos da página de código de origem para a página de código de destino.

Os resultados da instrução Transact-SQL podem variar quando a instrução for executada no contexto de diferentes bancos de dados que tenham configurações de ordenação diferentes. Se possível, use uma ordenação padronizada para sua organização. Desse modo, não será preciso especificar a ordenação em cada caractere ou expressão Unicode. Se você deve trabalhar com objetos que tenham configurações de ordenação e página de códigos diferentes, codifique suas consultas para considerar as regras da precedência de ordenação. Para obter mais informações, consulte Precedência de ordenação (Transact-SQL).

As opções associadas a uma ordenação são diferenciação de maiúsculas e minúsculas, de acentos, de caracteres Kana, de largura e de seletor de variação. O SQL Server 2019 (15.x) introduz uma opção adicional para codificação UTF-8.

Especifique essas opções acrescentando-as ao nome da ordenação. Por exemplo, a ordenação Japanese_Bushu_Kakusu_100_CS_AS_KS_WS_UTF8 diferencia maiúsculas de minúsculas, acentos, caracteres Kana, a largura e é codificado em UTF-8. Como outro exemplo, a ordenação Japanese_Bushu_Kakusu_140_CI_AI_KS_WS_VSS não diferencia maiúsculas de minúsculas, não diferencia acentos, mas diferencia caracteres Kana, a largura e o seletor de variação, além de usar a codificação não Unicode.

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

Opção Descrição
Case-sensitive (_CS) Faz distinção entre letras maiúscula e minúsculas. Se essa opção for selecionada, as letras minúsculas serão classificadas à frente das versões em letras maiúsculas. Se essa opção não for selecionada, a ordenação não diferenciará maiúsculas de minúsculas. Ou seja, o SQL Server considera as versões de letras maiúsculas e minúsculas como idênticas para fins de classificação. Você pode selecionar caso explicitamente a não diferenciação de maiúsculas e minúsculas especificando _CI.
Accent-sensitive (_AS) Faz distinção entre caracteres acentuados e não acentuados. Por exemplo, "a" não é igual a "ấ". Se essa opção não for selecionada, a ordenação não diferenciará acentos. Ou seja, o SQL Server considera as versões com e sem acentos como idênticas para fins de classificação. Você pode selecionar a não diferenciação de acentos especificando _AI.
Kana-sensitive (_KS) Distingue entre os dois tipos de caracteres kana japoneses: hiragana e katakana. Se essa opção não for selecionada, a ordenação não diferenciará caracteres Kana. Ou seja, o SQL Server considera que caracteres hiragana e katakana são iguais para fins de classificação. A omissão dessa opção é o único método de especificar a não diferenciação de caracteres Kana.
Width-sensitive (_WS) Faz distinção entre caracteres de largura inteira e de meia largura. Se essa opção não for selecionada, o SQL Server considerará as representações de largura inteira e de meia largura do mesmo caractere como idênticas para fins de classificação. A omissão desta opção é o único método de especificar a não diferenciação de largura.
Distinção de seletor de variação (_VSS) Distingue entre vários seletores de variação de ideograma nas ordenações de japonês Japanese_Bushu_Kakusu_140 e Japanese_XJIS_140, introduzidas 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 _VSS não for selecionada, a ordenação não diferenciará o seletor de variação e o seletor de variação não será considerado na comparação. Ou seja, o SQL Server considera caracteres que seguem o mesmo caractere base com seletores de variação distintos como sendo idênticos para fins de classificação. Para obter mais informações, confira Banco de dados de variação de ideograma Unicode.

Não há suporte para ordenações (_VSS) (diferenciação do seletor de variação) em índices de pesquisa de texto completo. Índices de pesquisa de texto completo dão suporte apenas às opções Diferenciação de Acentos (_AS), Diferenciação de caracteres Kana (_KS) e Diferenciação de largura (_WS). Os mecanismos de XML e CLR do SQL Server não dão 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 bit definidos para cada caractere. A ordem de classificação binária faz distinção entre maiúsculas e minúsculas e acentuação. Binário é também a ordem de classificação mais rápida. Para obter mais informações, confira a seção Ordenações primárias 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 que são idênticas àquelas das classificações binárias.

A vantagem de usar uma ordem de classificação ponto de código binário é que nenhuma reclassificação de dados será necessária em aplicativos que comparam dados classificados do SQL Server. Como resultado, uma ordem de classificação de ponto de código binário fornece desenvolvimento de aplicativos mais simples e possíveis aumentos de desempenho. Para obter mais informações, confira a seção Ordenações primárias neste artigo.
UTF-8 (_UTF8) Permite que dados codificados em UTF-8 sejam armazenados no SQL Server. Se essa opção não for 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, confira a seção Suporte a UTF-8 neste artigo.

1 Se Binário ou Ponto de código binário for selecionado, as opções Diferencia maiúsculas de minúsculas (_CS), Diferencia acentos (_AS), Diferencia caracteres Kana (_KS) e Diferencia a largura (_WS) não estarão disponíveis.

Exemplos de opções de ordenação

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

Sufixo de ordenação do Windows Descrição da ordem de classificação
_BIN1 Classificação binária
_BIN21, 2 Ordem de classificação do ponto de código binário
_CI_AI2 Não diferencia maiúsculas de minúsculas, acentos, caracteres Kana e a largura
_CI_AI_KS2 Não distingue maiúsculas e minúsculas, não distingue acentuação, distingue caracteres kana, não distingue largura
_CI_AI_KS_WS2 Não distingue maiúsculas e minúsculas, não distingue acentuação, distingue caracteres kana, distingue largura
_CI_AI_WS2 Não distingue maiúsculas e minúsculas, não distingue acentuação, não distingue caracteres kana, distingue largura
_CI_AS2 Não distingue maiúsculas e minúsculas, distingue acentuação, não distingue caracteres kana, não distingue largura
_CI_AS_KS2 Não distingue maiúsculas e minúsculas, distingue acentuação, distingue caracteres kana, não distingue largura
_CI_AS_KS_WS2 Não distingue maiúsculas e minúsculas, distingue acentuação, distingue caracteres kana, distingue largura
_CI_AS_WS2 Não distingue maiúsculas e minúsculas, distingue acentuação, não distingue caracteres kana, distingue largura
_CS_AI2 Distingue maiúsculas e minúsculas, não distingue acentuação, não distingue caracteres kana, não distingue largura
_CS_AI_KS2 Distingue maiúsculas e minúsculas, não distingue acentuação, distingue caracteres kana, não distingue largura
_CS_AI_KS_WS2 Distingue maiúsculas e minúsculas, não distingue acentuação, distingue caracteres kana, distingue largura
_CS_AI_WS2 Distingue maiúsculas e minúsculas, não distingue acentuação, não distingue caracteres kana, distingue largura
_CS_AS2 Distingue maiúsculas e minúsculas, distingue acentuação, não distingue caracteres kana, não distingue largura
_CS_AS_KS2 Distingue maiúsculas e minúsculas, distingue acentuação, distingue caracteres kana, não distingue largura
_CS_AS_KS_WS2 Distingue maiúsculas e minúsculas, distingue acentuação, distingue caracteres kana, distingue largura
_CS_AS_WS2 Distingue maiúsculas e minúsculas, distingue acentuação, não distingue caracteres kana, distingue largura

1 Se Binário ou Ponto de código binário for selecionado, as opções Diferencia maiúsculas de minúsculas (_CS), Diferencia acentos (_AS), Diferencia caracteres Kana (_KS) e Diferencia a largura (_WS) não estarão disponíveis.

2 A adição da opção UTF-8 (_UTF8) permite que você codifique dados Unicode usando UTF-8. Para obter mais informações, confira a seção Suporte a UTF-8 neste artigo.

Conjuntos de ordenações

O SQL Server oferece suporte aos seguintes conjuntos de ordenação:

ordenações do Windows

As ordenações do Windows definem regras para o armazenamento de dados de caractere baseados em uma localidade associada do sistema do Windows. No caso de uma ordenação do Windows, você pode implementar uma comparação de dados não Unicode usando o mesmo algoritmo dos dados Unicode. As regras de base da ordenação do Windows especificam qual alfabeto ou idioma é usado quando a classificação do dicionário é aplicada. As regras também especificam a página de código usada para armazenar dados de caractere não Unicode. As classificações Unicode e não Unicode são compatíveis com comparações de cadeias de caracteres em uma versão específica do Windows. Isso proporciona consistência entre os tipos de dados no SQL Server e permite que os desenvolvedores classifiquem as cadeias de caracteres nos aplicativos usando as mesmas regras utilizadas pelo SQL Server. Para obter mais informações, confira Nome de ordenação do Windows (Transact-SQL).

Ordenações primárias

Os dados classificados de ordenações primárias na sequência de valores codificados definidos pelo tipo de localidade e dados. Eles diferenciam maiúsculas de minúsculas. Uma ordenação primária 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. Como são relativamente simples, as ordenações primárias ajudam melhorar o desempenho do aplicativo. Para tipos de dados não Unicode, as comparações de dados têm como base os pontos de código definidos na página de código ANSI. Para tipos de dados Unicode, as comparações de dados têm como base os pontos de código Unicode. Para ordenações primárias em tipos de dados Unicode, a localidade não é considerada nas classificações de dados. Por exemplo, Latin1_General_BIN e Japanese_BIN geram resultados de classificação idênticos quando usados em dados Unicode. Para obter mais informações, confira Nome de ordenação do Windows (Transact-SQL).

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

  • As ordenações BIN herdadas, que executavam uma comparação de ponto de código para ponto de código incompleta para dados Unicode. Essas ordenações primárias herdadas comparavam o primeiro caractere como WCHAR, seguido por uma comparação byte por byte. Em uma ordenação BIN, apenas o primeiro caractere é classificado de acordo com o ponto de código e os caracteres restantes são classificados de acordo com os respectivos valores de bytes.

  • As ordenações BIN2 mais recentes, que implementam uma comparação de ponto de código puro. Em uma ordenação BIN2, todos os caracteres são classificados de acordo com os respectivos pontos de código. Já que a plataforma Intel é uma arquitetura little endian, os caracteres de código Unicode são sempre trocados por bytes armazenados.

ordenações do SQL Server

As ordenações (SQL_*) do SQL Server oferecem compatibilidade de ordem de classificação com versões anteriores do SQL Server. As regras de classificação do dicionário para dados não Unicode são incompatíveis com as rotinas de classificação fornecidas 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 as ordenações 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 você estiver usando a ordenação SQL SQL_Latin1_General_CP1_CI_AS, a string não Unicode 'a-c' será menor que a string 'ab' porque o hífen (-) é classificado como um caractere separado que vem antes de b. No entanto, se você converter essas cadeias de caracteres em Unicode e realizar a mesma comparação, a cadeia de caracteres Unicode N'a-c' será considerada maior que N'ab', pois as regras de classificação Unicode usam uma classificação de palavras que ignora o hífen.

Para obter mais informações, confira Nome de ordenação do SQL Server (Transact-SQL).

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

Observação

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

  • Seu código de aplicativo depende do comportamento de ordenações anteriores do SQL Server.
  • Você deve armazenar dados de caractere que refletem vários idiomas.

Níveis de ordenação

Há suporte para configurar ordenações nos seguintes níveis de uma instância do SQL Server:

Ordenações no nível do servidor

A ordenação do servidor padrão é determinada durante a instalação do SQL Server e se torna a ordenação padrão dos bancos de dados do sistema e de todos os bancos de dados de usuário.

A seguinte tabela mostra as designações de ordenação padrão conforme determinado pela localidade do sistema operacional, incluindo os respectivos LCIDs (identificadores de código de idioma) do Windows e do SQL:

Localidade do Windows LCID do Windows LCID do SQL 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 (Catar) 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 (EAU) 0x3801 0x0401 Arabic_CI_AS
Árabe (Iêmen) 0x2401 0x0401 Arabic_CI_AS
Armênio (Armênia) 0x042b 0x0419 Latin1_General_CI_AS
Assamês (Índia) 0x044d 0x044d Indisponível no nível do servidor
Azerbaijano (Azerbaijão, cirílico) 0x082c 0x082c Preterido, não disponível no nível do servidor
Azerbaijano (Azerbaijão, latino) 0x042c 0x042c Preterido, não disponível no nível do servidor
Bashkir (Rússia) 0x046d 0x046d Latin1_General_CI_AI
Basco (País Basco) 0x042d 0x0409 Latin1_General_CI_AS
Bielorrusso (Belarus) 0x0423 0x0419 Cyrillic_General_CI_AS
Bangla (Bangladesh) 0x0845 0x0445 Indisponível no nível do servidor
Bengali (India) 0x0445 0x0439 Indisponí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 (Catalunha) 0x0403 0x0409 Latin1_General_CI_AS
Chinês (RAE de Hong Kong, RPC) 0x0c04 0x0404 Chinese_Taiwan_Stroke_CI_AS
Chinese (Macao SAR) 0x1404 0x1404 Latin1_General_CI_AI
Chinese (Macao SAR) 0x21404 0x21404 Latin1_General_CI_AI
Chinês (China) 0x0804 0x0804 Chinese_PRC_CI_AS
Chinês (China) 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
Corso (França) 0x0483 0x0483 Latin1_General_CI_AI
Croata (Bósnia e Herzegovina, Latino) 0x101a 0x041a Croatian_CI_AS
Croata (Croácia) 0x041a 0x041a Croatian_CI_AS
Tcheco (República Tcheca) 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 Indisponível no nível do servidor
Holandês (Bélgica) 0x0813 0x0409 Latin1_General_CI_AS
Holandês (Países Baixos) 0x0413 0x0409 Latin1_General_CI_AS
Inglês (Austrália) 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 (Zimbábue) 0x3009 0x0409 Latin1_General_CI_AS
Estoniano (Estônia) 0x0425 0x0425 Estonian_CI_AS
Feroês (Ilhas Faroe) 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
Frisão (Holanda) 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 – classificação do catálogo telefônico (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 (Groenlândia) 0x046f 0x0406 Danish_Norwegian_CI_AS
Gujarati (Índia) 0x0447 0x0439 Indisponível no nível do servidor
hauçá (Nigéria, Latino) 0x0468 0x0409 Latin1_General_CI_AS
Hebraico (Israel) 0x040d 0x040d Hebrew_CI_AS
Híndi (Índia) 0x0439 0x0439 Indisponí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 (silábico) 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
canarim (Índia) 0x044b 0x0439 Indisponível no nível do servidor
Cazaque (Cazaquistão) 0x043f 0x043f Kazakh_90_CI_AS
Khmer (Camboja) 0x0453 0x0453 Indisponível no nível do servidor
Quiché (Guatemala) 0x0486 0x0c0a Modern_Spanish_CI_AS
Quiniaruanda (Ruanda) 0x0487 0x0409 Latin1_General_CI_AS
Konkani (Índia) 0x0457 0x0439 Indisponível no nível do servidor
Coreano (classificação de dicionário coreano) 0x0412 0x0412 Korean_Wansung_CI_AS
Quirguiz (Quirguistão) 0x0440 0x0419 Cyrillic_General_CI_AS
Laosiano (RDP do Laos) 0x0454 0x0454 Indisponível no nível do servidor
Letão (Letônia) 0x0426 0x0426 Latvian_CI_AS
Lituano (Lituânia) 0x0427 0x0427 Lithuanian_CI_AS
Sorábio baixo (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 Indisponí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
Marati (Índia) 0x044e 0x0439 Indisponível no nível do servidor
moicano (Canadá) 0x047c 0x047c Latin1_General_CI_AI
Mongol (Mongólia) 0x0450 0x0419 Cyrillic_General_CI_AS
Mongol (RPC) 0x0850 0x0419 Cyrillic_General_CI_AS
Nepalês (Nepal) 0x0461 0x0461 Indisponí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
occitânico (França) 0x0482 0x040c French_CI_AS
Oriá (Índia) 0x0448 0x0439 Indisponível no nível do servidor
Pashto (Afeganistão) 0x0463 0x0463 Indisponível no nível do servidor
Persa (Irã) 0x0429 0x0429 Latin1_General_CI_AI
Polonês (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
panjabi (Índia) 0x0446 0x0439 Indisponí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 Indisponí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, latino) 0x081a 0x081a Latin1_General_CI_AI
soto setentrional (Á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 Indisponí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
Suaíle (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 Indisponível no nível do servidor
Tadjique (Tadjiquistão) 0x0428 0x0419 Cyrillic_General_CI_AS
Tamazirte (Argélia, latino) 0x085f 0x085f Latin1_General_CI_AI
Tâmil (Índia) 0x0449 0x0439 Indisponível no nível do servidor
Tatárico (Rússia) 0x0444 0x0444 Cyrillic_General_CI_AS
Télugo (Índia) 0x044a 0x0439 Indisponível no nível do servidor
Tailandês (Tailândia) 0x041e 0x041e Thai_CI_AS
Tibetano (RPC) 0x0451 0x0451 Indisponível no nível do servidor
Turco (Turquia) 0x041f 0x041f Turkish_CI_AS
Turcomeno (Turcomenistão) 0x0442 0x0442 Latin1_General_CI_AI
Uighur (RPC) 0x0480 0x0480 Latin1_General_CI_AI
Ucraniano (Ucrânia) 0x0422 0x0422 Ukrainian_CI_AS
Sorábio Alto (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, latino) 0x0443 0x0443 Uzbek_Latin_90_CI_AS
Vietnamita (Vietnã) 0x042a 0x042a Vietnamese_CI_AS
Galês (Reino Unido) 0x0452 0x0452 Latin1_General_CI_AI
uolofe (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
Ioruba (Nigéria) 0x046a 0x0409 Latin1_General_CI_AS
Zulu/isiZulu (África do Sul) 0x0435 0x0409 Latin1_General_CI_AS

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

Para consultar a ordenação do servidor para uma instância do SQL Server, use a função SERVERPROPERTY:

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

Para consultar o servidor por todas as ordenações disponíveis, use a seguinte função interna fn_helpcollations():

SELECT * FROM sys.fn_helpcollations();

Ordenações no Banco de Dados SQL do Azure

Você não pode alterar ou definir a ordenação do servidor lógico no Banco de Dados SQL do Azure, mas pode configurar as ordenações de cada banco de dados para dados e para o catálogo. A ordenação do catálogo determina a ordenação dos metadados do sistema, como identificadores de objetos. Ambas as ordenações podem ser especificadas de maneira independente quando você cria o banco de dados no portal do Azure, em T-SQL com CREATE DATABASE e no PowerShell com New-AzSqlDatabase.

Ordenações na instância gerenciada do Azure SQL

A ordenação em nível de servidor na Instância Gerenciada de SQL do Azure pode ser especificada quando a instância é criada e não pode ser alterada posteriormente.

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

Ordenações do nível do banco de dados

Ao criar ou modificar um banco de dados, use a cláusula COLLATE da instrução CREATE DATABASE ou ALTER DATABASE para especificar a ordenação de banco de dados padrão. Se nenhuma ordenação for especificada, o banco de dados receberá a ordenação do servidor.

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

  • No SQL Server e na Instância Gerenciada de SQL do Azure, a ordenação do banco de dados é usada para todos os metadados no banco de dados, e a ordenação é o padrão para todas as colunas de cadeia de caracteres, objetos temporários, nomes de variáveis e qualquer outra cadeia de caracteres usada no banco de dados.
  • No Banco de Dados SQL do Azure, não há ordenação de servidor e, portanto, cada banco de dados tem uma ordenação para dados e uma ordenação para o catálogo. CATALOG_COLLATION é usado para todos os metadados do banco de dados, e a ordenação é o padrão para todas as colunas de cadeia de caracteres, objetos temporários, nomes de variáveis e qualquer outra cadeia de caracteres usada no banco de dados. CATALOG_COLLATION é definido na criação e não pode ser alterado.

Quando você altera a ordenação de um banco de dados de usuário, pode haver conflitos de ordenação quando consultas no banco de dados acessam tabelas temporárias. Tabelas temporárias são sempre armazenadas no banco de dados do sistema tempdb, que usa a ordenação da instância. Consultas que comparam dados de caracteres entre o banco de dados do usuário e tempdb podem falhar quando as ordenações causam conflito na avaliação dos dados de caracteres. Resolva esse problema especificando a cláusula COLLATE na consulta. Para obter mais informações, confira COLLATE (Transact-SQL).

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

ALTER DATABASE myDB COLLATE Greek_CS_AI;

Importante

A alteração da ordenação no nível de banco de dados não afeta as ordenações no nível de coluna ou de expressão. Isso não afeta os dados em colunas existentes.

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

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

Ordenações em nível de coluna

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

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

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

Ordenações no nível da expressão

As ordenações no nível de expressão são definidas quando uma instrução é executada e afetam o modo como um conjunto de resultados é retornado. Isso permite que os resultados da classificação ORDER BY sejam específicos da localidade. Para implementar ordenações em nível de expressão, use uma cláusula COLLATE como o seguinte exemplo de código:

SELECT name FROM customer ORDER BY name COLLATE Latin1_General_CS_AI;    

Localidade

Uma localidade é um conjunto de informações associadas a uma localização ou uma cultura. As informações podem incluir o nome e o identificador do idioma falado, o script usado para escrever o idioma e as convenções culturais. As ordenações podem ser associadas a uma ou mais localidades. Para obter mais informações, consulte o artigo sobre IDs de localidade atribuídas pela Microsoft.

Página de código

Uma página de código é um conjunto de caracteres ordenado 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 geralmente é referenciada como um conjunto decaracteres. As páginas de código são usadas para oferecer suporte aos conjuntos de caracteres e layouts de teclado usados por diferentes localidades de sistema do 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 com o uso de ordenações e podem ser otimizados com o uso de índices.

Suporte de Unicode

O Unicode é um padrão para mapear pontos de código para caracteres. Como ele foi projetado para abranger todos os caracteres de todos os idiomas do mundo, você não precisa ter páginas de código diferentes para manipular 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 administrar 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 necessários específicos a um idioma. Além disso, é difícil garantir a tradução correta de caracteres especiais quando eles são lidos ou atualizados por uma variedade de clientes que executam várias páginas de código. Bancos de dados que oferecem suporte a clientes internacionais sempre deveriam 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 o México
  • Nomes e endereços em francês 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 manipule os caracteres dos três idiomas. Você também precisa tomar cuidado para garantir a tradução correta de caracteres de um dos idiomas, quando os caracteres forem lidos por clientes que executam uma página de código de outro idioma.

Observação

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

É difícil selecionar uma página de código para tipos de dados de caractere que dará suporte a todos os caracteres necessários para um público-alvo mundial. A maneira mais fácil de gerenciar dados de caractere em bancos de dados internacionais é sempre usar um tipo de dados com suporte a Unicode.

Tipos de dados Unicode

Se você armazenar dados de caractere que refletem várias linguagens no SQL Server (SQL Server 2005 (9.x) e posterior), use tipos de dados Unicode (nchar, nvarchar e ntext) em vez de tipos de dados não Unicode (char, varchar e text).

Observação

No caso dos tipos de dados Unicode, o Mecanismo de Banco de Dados poderá representar até 65.536 caracteres usando o UCS-2 ou o intervalo completo de Unicode (1.114.112 caracteres) se caracteres suplementares forem usados. Para obter mais informações sobre como habilitar caracteres suplementares, confira Caracteres suplementares.

Como alternativa, no SQL Server 2019 (15.x) em diante, se uma ordenação habilitada para UTF-8 (_UTF8) for usada, os tipos de dados que eram não Unicode (char e varchar) se tornarão tipos de dados Unicode usando codificação UTF-8. SQL Server 2019 (15.x) não altera o comportamento dos tipos de dados Unicode anteriormente existentes (nchar, nvarchar e ntext), que continuam usando a codificação UCS-2 ou UTF-16. Para obter mais informações, confira Diferenças de armazenamento entre UTF-8 e UTF-16.

Considerações sobre Unicode

Limitações consideráveis estão associadas a tipos de dados não Unicode. Isso ocorre porque um computador não Unicode fica limitado a usar uma única página de código. Você pode ter um ganho de desempenho com o uso de Unicode, porque ele exige menos conversões de página de código. As ordenações Unicode precisam ser selecionadas individualmente no nível de banco de dados, coluna ou expressão, porque não há suporte para elas no nível de servidor.

Quando você move dados de um servidor para um cliente, a ordenação do servidor pode não ser reconhecida por drivers de cliente mais antigos. Isso pode ocorrer quando você move dados de um servidor Unicode para um cliente não Unicode. A melhor opção pode ser atualizar o sistema operacional do cliente para que as ordenações de sistema subjacentes sejam atualizadas. Se houver um software de cliente de banco de dados instalado no cliente, você deverá considerar a possibilidade de aplicar uma atualização de serviço a esse software.

Dica

Você também pode tentar usar uma ordenação diferente para os dados no servidor. Escolha uma ordenação que mapeia para uma página de código no cliente.

Para usar as ordenações UTF-16 disponíveis no SQL Server (SQL Server 2012 (11.x) e posterior) visando melhorar a pesquisa e a classificação de alguns caracteres Unicode (somente ordenações do Windows), selecione uma das ordenações de caracteres suplementares (_SC) ou uma das ordenações da versão 140.

Para usar as ordenações UTF-8 disponíveis no SQL Server 2019 (15.x) e melhorar a pesquisa e a classificação de alguns caracteres Unicode (somente ordenações do Windows), você precisará selecionar ordenações habilitadas para codificação UTF-8 (_UTF8).

  • O sinalizador de UTF8 pode ser aplicado a:

    • Ordenações linguísticas que já têm suporte para _SC (caracteres suplementares) ou com o reconhecimento de _VSS (diferenciação de seletor de variação)
    • Ordenação binária BIN2
  • O sinalizador de UTF-8 não pode ser aplicado a:

    • Ordenações linguísticas que não têm suporte para _SC (caracteres suplementares) ou com o reconhecimento de _VSS (diferenciação de seletor de variação)
    • As ordenações binárias BIN
    • As ordenações do SQL_*

Para avaliar os 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 a ordenação usada nos sistemas de sua organização e implantar servidores e clientes Unicode sempre que possível.

Na maioria das situações, o SQL Server interage com outros servidores ou clientes, e a sua organização poderá usar vários padrões de acesso a dados entre aplicativos e instâncias de servidor. ClientesSQL Server são de um destes dois tipos principais:

  • Clientes Unicode que usam o OLE DB e o ODBC versão 3.7 ou posterior.
  • Clientes não Unicode que usam a DB-Library e o ODBC versão 3.6 ou anterior.

A seguinte tabela 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, este cenário fornece o melhor desempenho e proteção contra danos de dados recuperados. É isso o que acontece com a ADO (ActiveX Data Objects), o OLE DB e o ODBC versão 3.7 ou posterior.
Unicode Não Unicode Neste cenário, principalmente em conexões entre um servidor que executa um sistema operacional mais recente e um cliente que executa uma versão anterior do SQL Server ou em um sistema operacional mais antigo, pode haver limitações ou erros ao mover os dados para um computador cliente. Os dados Unicode no servidor tentam mapear para uma página de código correspondente no cliente não Unicode para converter os dados.
Não Unicode Unicode Essa não é uma configuração ideal para o uso de dados multilíngues. Não é possível gravar dados Unicode no servidor não Unicode. É provável que ocorram problemas quando os dados forem enviados para servidores que estejam fora da página de código do servidor.
Não Unicode Não Unicode Este é um cenário muito limitado para dados multilíngues. Você pode usar uma única página de código.

Caracteres suplementares

O Unicode Consortium aloca para cada caractere um ponto de código exclusivo, que é um valor no intervalo 000000–10FFFF. Os caracteres usados com mais frequência têm valores de ponto de código no intervalo 000000–00FFFF (65.536 caracteres) que se ajustam a uma palavra de 8 ou 16 bits na memória e no disco. Geralmente, esse intervalo é designado como BMP (Plano Multilíngue Básico).

No entanto, o Consortium Unicode estabeleceu 16 "planos" adicionais de caracteres, cada um com o mesmo tamanho do BMP. Essa definição permite ao Unicode o potencial para representar 1.114.112 caracteres (ou seja, 216 * 17 caracteres) dentro do intervalo do ponto de código 000000–10FFFF. Caracteres com valor de ponto de código maior que 00FFFF exigem de 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 de caracteres suplementares, e as palavras adicionais consecutivas de 8 ou 16 bits são chamadas de pares alternativos. Para obter mais informações sobre caracteres complementares, substitutos e pares alternativos, consulte o Padrão Unicode.

O SQL Server fornece tipos de dados, como nchar e nvarchar, para armazenar dados Unicode no intervalo do 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 ordenações de caracteres suplementares (_SC) que podem ser usadas com os tipos de dados nchar, nvarchar e sql_variant para representar o intervalo completo de caracteres Unicode (000000–10FFFF). Por exemplo: Latin1_General_100_CI_AS_SC ou, se você estiver usando uma ordenação de japonês, Japanese_Bushu_Kakusu_100_CI_AS_SC.

SQL Server 2019 (15.x) estende o suporte a caracteres suplementares aos tipos de dados char e varchar com as novas ordenações habilitadas para UTF-8 (_UTF8). Esses tipos de dados também podem representar o intervalo completo de caracteres Unicode.

Observação

No SQL Server 2017 (14.x) em diante, todas as novas ordenações da versão automaticamente dão suporte a caracteres suplementares.

Se você usar caracteres suplementares:

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

  • Todas as ordenações de versão 100 dão suporte à classificação linguística com caracteres suplementares.

  • Os caracteres suplementares não são compatíveis para uso em metadados, como em nomes de objetos de banco de dados.

  • O sinalizador de SC pode ser aplicado a:

    • Ordenações da versão 90
    • Ordenações da versão 100
  • O sinalizador de SC não pode ser aplicado a:

    • Ordenações do Windows sem versão na versão 80
    • As ordenações primárias BIN ou BIN2
    • As ordenações do SQL*
    • Ordenações da versão 140 (elas não precisam do sinalizador de SC, pois já dão suporte a caracteres suplementares)

A seguinte tabela compara o comportamento de alguns operadores e funções de cadeia de caracteres quando eles usam caracteres suplementares com e sem uma ordenação SCA (reconhecimento de caracteres suplementares):

Operador ou função de cadeia de caracteres Com uma ordenação de SCA Sem uma ordenação de SCA
CHARINDEX

LEN

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

REPLACE

REVERSE

RIGHT

SUBSTRING

STUFF
Essas funções tratam cada par alternativo como um único ponto de código e funcionam conforme esperado. Essas funções podem dividir qualquer par alternativo e levar a resultados inesperados.
NCHAR Retorna o caractere que corresponde ao valor do 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, é retornado o substituto correspondente. Um valor mais alto que 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.
Corresponder a um caractere curinga

Curinga – caracter(es) para não corresponder
Há suporte para caracteres suplementares para todas as operações de curingas. Não há suporte para caracteres suplementares nessas operações de curingas. Há suporte para outros operadores curinga.

Suporte a GB18030

GB18030 é um padrão separado usado na República Popular da China para codificar caracteres chineses. Em GB18030, caracteres podem ter 1, 2 ou 4 bytes em comprimento. OSQL Server oferece suporte a caracteres GB18030 codificados, reconhecendo-os quando eles entram no servidor, provenientes de um aplicativo cliente, convertendo-os e armazenando-os nativamente como caracteres Unicode. Depois de serem armazenados no servidor, eles são tratados como caracteres Unicode em todas as operações seguintes.

Você pode usar qualquer ordenação em chinês, preferivelmente a mais recente versão 100. Todas as ordenações de versão 100 dão suporte à classificação linguística com caracteres GB18030. Se os dados incluírem caracteres suplementares (pares alternativos), você poderá usar as ordenações de SC disponíveis no SQL Server para melhorar a pesquisa e a classificação.

Observação

Verifique se as ferramentas de cliente, como SQL Server Management Studio, usam a fonte Dengxian para exibir corretamente cadeias de caracteres que contêm caracteres codificados em GB18030.

Suporte a script complexo

OSQL Server oferece suporte à inserção, armazenamento, alteração e exibição de scripts complexos. Scripts complexos incluem os seguintes tipos:

  • Scripts que incluem uma 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 alteram de forma de acordo com sua posição ou quando combinados com outros caracteres, como caracteres árabes, índicos e tailandeses.
  • Idiomas, como o tailandês, que exigem dicionários internos para reconhecer palavras, porque não há nenhuma quebra entre eles.

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

Ordenações de japonês adicionadas ao SQL Server 2017 (14.x)

A partir do SQL Server 2017 (14.x), há suporte para novas famílias de ordenação em japonês, com as permutações de várias opções (_CS, _AS, _KS, _WS e _VSS), bem como _BIN e _BIN2.

Para listar essas ordenações, 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, de modo que nenhuma das novas ordenações da versão 140 tem (ou precisa de) sinalizador de SC.

Essas ordenações são compatíveis com índices, tabelas com otimização de memória, índices columnstore e módulos compilados nativamente no Mecanismo de Banco de Dados.

Suporte para UTF-8

O SQL Server 2019 (15.x) apresenta suporte completo para a codificação de caracteres UTF-8 amplamente utilizada como codificação de importação ou exportação e como ordenação em nível de coluna ou de banco de dados para dados de cadeia de caracteres. O UTF-8 é permitido nos tipos de dados char e varchar e é habilitado quando você cria ou altera a ordenação de um objeto para um ordenação que tem um sufixo UTF8. Um exemplo é alterar LATIN1_GENERAL_100_CI_AS_SC para LATIN1_GENERAL_100_CI_AS_SC_UTF8.

O UTF-8 só está disponível para ordenações do Windows que dão 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 de SQL do Azure também oferecem suporte a UTF-8 no nível do banco de dados e da coluna, enquanto a Instância Gerenciada de SQL também oferece esse suporte no nível do servidor.

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

O Unicode Consortium aloca para 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 em UTF-8 e UTF-16 estão disponíveis para representar o intervalo completo:

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

A seguinte tabela 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 armazenamento1 com UTF-8 Bytes de armazenamento1 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–03FFFF2

040000–10FFFF2
65.536–262.1432

262.144–1.114.1112
4 4

1Bytes de armazenamento referem-se ao tamanho do byte codificado, e não ao tamanho do armazenamento em disco do tipo de dados. Para saber mais sobre tamanhos de armazenamento em disco, confira os tipos de dados nchar e nvarchar e char e varchar.

2 O intervalo do ponto de código para caracteres suplementares.

Dica

É comum pensar, em CHAR(n) e VARCHAR(n) ou em NCHAR(n) e NVARCHAR(n), que ndefine o número de caracteres. Isso ocorre porque, no exemplo de uma coluna CHAR(10), 10 caracteres ASCII no intervalo 0–127 podem ser armazenados usando uma ordenação como Latin1_General_100_CI_AI, porque cada caractere desse intervalo usa apenas 1 byte.

No entanto, em CHAR(n) e VARCHAR(n), n define o tamanho da cadeia de caracteres em bytes (0–8.000), e em NCHAR(n) e NVARCHAR(n), n define o tamanho da cadeia de caracteres em pares de bytes (0–4.000). n nunca define números de caracteres que podem ser armazenados.

Como você acabou de ver, a escolha do tipo de dados e da codificação Unicode apropriados pode proporcionar uma economia significativa de armazenamento ou aumentar o volume de armazenamento atual, dependendo do conjunto de caracteres em uso. Por exemplo, quando você usa uma ordenação de latim que é habilitada para UTF-8, como Latin1_General_100_CI_AI_SC_UTF8, uma coluna CHAR(10) armazena 10 bytes e pode conter 10 caracteres ASCII no intervalo 0–127. Porém, ela pode conter apenas cinco caracteres no intervalo de 128 a 2047 e apenas três caracteres no intervalo de 2048 a 65535. Por comparação, como uma coluna NCHAR(10) armazena 10 pares de bytes (20 bytes), ela pode armazenar 10 caracteres no intervalo de 0–65.535.

Antes de optar por usar a codificação UTF-8 ou UTF-16 para um banco de dados ou uma coluna, considere a distribuição dos dados de cadeia de caracteres que serão armazenados:

  • Se a maioria estiver no intervalo 0–127 do ASCII (como o inglês), cada caractere exigirá 1 byte com UTF-8 e 2 bytes com UTF-16. O uso de UTF-8 proporciona vantagens de armazenamento. A alteração de um tipo de dados de coluna existente com caracteres ASCII no intervalo 0–127 de NCHAR(10) para CHAR(10) e o uso de uma ordenação habilitada para UTF-8 representam 50% de redução nos requisitos de armazenamento. Essa redução ocorre porque NCHAR(10) exige 20 bytes para armazenamento, em comparação com CHAR(10), que exige 10 bytes para a mesma representação de cadeia de caracteres Unicode.
  • Acima do intervalo do ASCII, quase todos os scripts com base latina, além do 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 a maioria for de scripts do Leste da Ásia (como coreano, chinês e japonês), cada caractere exigirá 3 bytes com UTF-8 e 2 bytes com UTF-16. O uso de UTF-16 proporciona vantagens de armazenamento.
  • Os caracteres no intervalo de 010000–10FFFF exigem 4 bytes tanto em UTF-8 quanto em UTF-16. Nesses casos, não há diferenças de armazenamento para tipos de dados comparáveis (por exemplo, entre o uso de char ou nchar).

Para ver outras considerações, confira o artigo Gravar instruções Transact-SQL internacionais.

Converter em UTF-8

Como em CHAR (n) e VARCHAR (n) ou em NCHAR (n) e NVARCHAR (n), o n define o tamanho de armazenamento em 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 para evitar o truncamento de dados.

Por exemplo, considere uma coluna definida como NVARCHAR (100) que armazena 180 bytes de caracteres japoneses. Neste exemplo, os dados da coluna atualmente são 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 evitar o truncamento de dados, pois o novo tipo de dados só pode armazenar 200 bytes, mas os caracteres japoneses exigem 3 bytes quando codificados em UTF-8. Portanto, a coluna deve ser definida como VARCHAR (270) para evitar a perda de dados por truncamento de dados.

Portanto, é necessário saber com antecedência qual é o tamanho do byte projetado para a definição da coluna antes de converter os dados existentes em UTF-8 e ajustar o tamanho do novo tipo de dados de acordo. Confira o script Transact-SQL ou o SQL Notebook no GitHub de exemplos de dados, que usa a função DATALENGTH e a instrução COLLATE para determinar os requisitos de comprimento de dados corretos para operações de conversão UTF-8 em um banco de dados existente.

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

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

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

Para obter mais informações, confira o seguinte conteúdo relacionado:

Confira também