Agrupamento / conjunto de caracteres UTF-8 do SQL Server 2005/2008

Não consigo encontrar as opções diretamente para definir UTF-8rellated Collations/Charsetsno SQL Server 2005/2008, da mesma forma que é possível definir em outros mecanismos SQL, mas no SQL Server 2005/2008 existem apenas agrupamentos em latim e SQL.

Existe alguma opção para forçar / instalar esses agrupamentos / caracteres no mecanismo do SQL Server (para as duas ver.) 2005/2008 no sistema operacional Win2008

Não, não existe. O SQL Server não oferece suporte a UTF-8.

Você precisa definir suas colunas como nvarchar / nchar se desejar dados unicode. Observe que internamente o SQL Server armazena isso como UCS-2.

Observe que isso foi solicitado ao MS on Connect e existe um artigo mais antigo da KB . E algumas informações neste blog também

Você não pode instalar o UTF-8 como um conjunto de caracteres, porque não é um conjunto de caracteres, é uma codificação.

Se você deseja armazenar texto Unicode, use o nvarchartipo de dados.

Se você deseja armazenar texto codificado usando UTF-8, armazene-o como dados binários ( varbinary).

A partir do SQL Server 2019 (atualmente em beta / "Community Tech Preview"), há suporte nativo para o UTF-8 por meio de uma nova série de agrupamentos do UTF-8. NO ENTANTO, ter a capacidade de usar UTF-8 não significa que você deveria. Existem desvantagens definidas no uso de UTF-8, como:

1. Somente os primeiros 128 pontos de código têm 1 byte (ou seja, o conjunto ASCII padrão de 7 bits)
2. Os próximos quase 2000 pontos de código são 2 bytes, portanto, não há economia de espaço em relação ao UTF-16 / NVARCHAR
3. Os restantes 63k pontos de código no BMP (ou seja, o intervalo U + 0800 - U + FFFF) são todos de 3 bytes, portanto, 1 byte maior que o mesmo caractere em UTF-16 / NVARCHAR.
4. Basta dizer: Os caracteres suplementares têm 4 bytes em ambas as codificações, portanto, não há diferença de espaço.
5. Embora você possa economizar espaço usando o UTF-8, há uma chance muito boa de afetar o desempenho ao fazê-lo.

O que realmente se resume é o seguinte: UTF-8 é um design de formato de armazenamento para permitir que sistemas de 8 bits (normalmente projetados em torno do ASCII e ASCII Extended - Code Pages) usem o Unicode sem quebrar nada ou exigir qualquer modificação dos existentes arquivos para manter as coisas funcionando. O UTF-8 é maravilhoso para sistemas de arquivos e redes, mas os dados armazenados no SQL Server também não são. O fato de os dados estarem na sua maioria (ou inteiramente) dentro do intervalo ASCII padrão requer menos espaço que os mesmos dados quando armazenados como UTF-16 / NVARCHARé um efeito colateral. Claro, é um efeito colateral que pode ser útil, mas essa decisão precisa ser tomada por alguém que entenda os dados e as conseqüências / desvantagens dessa decisão. Isto énão é um recurso para uso geral.

Além disso, o principal caso de uso do UTF-8 (no SQL Server) é o código do aplicativo que já está usando o UTF-8, possivelmente já com outro RDBMS que o suporta, e não há desejo ou capacidade de atualizar o código do aplicativo / esquema do banco de dados para usar NVARCHARtipos de dados (para tabelas, variáveis, parâmetros etc.) ou prefixar literais de seqüência de caracteres com um "N" maiúsculo. O objetivo é o mesmo do motivo da existência do UTF-8: habilitar o código do aplicativo para usar Unicode sem alterar a estrutura geral ou tornar inválidos os dados existentes. Se isso descreve sua situação, use UTF-8, mas esteja ciente de que ainda existem alguns bugs / problemas.

Se você não tiver uma necessidade explícita de que o Unicode funcione sem usar NVARCHARliterais de seqüência de caracteres com prefixo "N" maiúsculo, o único outro cenário em que o UTF-8 é um benefício é se você tiver MUITOS dados ASCII na maioria das vezes padrão que precisam permitir Caracteres Unicode e você está usando NVARCHAR(MAX)(o que significa que a compactação de dados não funcionará), e a tabela é atualizada com frequência (portanto, o Índice de Colunas de Cluster em cluster provavelmente não vai realmente ajudar).

Para mais detalhes, consulte o meu post:

Suporte nativo a UTF-8 no SQL Server 2019: Salvador ou Falso Profeta?

No meu caso, tive que exibir caracteres árabes e meu banco de dados de desenvolvimento foi em 2014, aqui as coisas funcionaram bem. Aqui, na consulta, pude ver caracteres árabes e meu agrupamento foi SQL_Latin1_General_CP1256_CI_AS

Mas minha produção foi no SQL Server 2008 e, eventualmente, não suportou o conjunto de caracteres UTF-8. Aqui, eu pude ver tudo ??????????? como UTF-8 não é suportado no SQL 2008.

Tudo o que fiz foi alterar all varchar para nvarchar e pude ver o caractere árabe corretamente. Também altero meu agrupamento de banco de dados de 2008 para SQL_Latin1_General_CP1256_CI_AS