Início / dba / Perguntas / 7346
Accepted
mKorbel
Asked: 2011-10-28 23:27:37 +0800 CST

Agrupamento/Charset do SQL Server 2005/2008 UTF-8

  • 772

Não consigo encontrar opção(ões) diretamente para definir UTF-8relacionadas 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 latinos e SQL.

Existe alguma opção para forçar/instalar esses agrupamentos / conjuntos de caracteres no mecanismo do SQL Server (para ambas as versões) 2005/2008 no sistema operacional Win2008

sql-server sql-server-2008

4 respostas

  1. Best Answer

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

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

    Observe que isso foi solicitado do MS no Connect e há um artigo antigo da base de conhecimento . E algumas informações neste blog também

    • 14

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

    1. Apenas os primeiros 128 pontos de código são de 1 byte (ou seja, o conjunto ASCII padrão de 7 bits)
    2. Os próximos quase 2.000 pontos de código são de 2 bytes, portanto, não há economia de espaço em UTF-16 /NVARCHAR
    3. Os 63k pontos de código restantes no BMP (ou seja, o intervalo U+0800 - U+FFFF) são todos 3 bytes, portanto, 1 byte maior que o mesmo caractere em UTF-16 / NVARCHAR.
    4. Apenas declare: os caracteres suplementares são 4 bytes em ambas as codificações, portanto, não há diferença de espaço lá
    5. Embora você possa economizar espaço usando UTF-8, há uma boa chance de você ter um impacto no 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 (que foram normalmente projetados em torno de ASCII e ASCII Extended -- Code Pages) usem Unicode sem quebrar nada ou exigir qualquer modificação de 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. O fato de que os dados que por acaso estão principalmente (ou inteiramente) dentro do intervalo ASCII padrão requerem menos espaço do 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 consequências/desvantagens dessa decisão. Isto énão é um recurso para uso geral.

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

    Se você não tiver uma necessidade explícita de Unicode trabalhando sem usar NVARCHARou literais de string prefixados com "N" maiúsculo, o único outro cenário em que o UTF-8 é um benefício é se você tiver MUITOS dados ASCII 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 armazenamento de colunas em cluster provavelmente não ajudará realmente).

    Para mais detalhes, veja meu post:

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

    • 3

  3. 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ê quiser armazenar texto codificado usando UTF-8, armazene-o como dados binários ( varbinary).

    • 2

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

    Mas minha produção estava no SQL Server 2008 e eventualmente não suportava o charset UTF-8. Aqui, eu pude ver tudo ???????????? como UTF-8 não é suportado no SQL 2008.

    O que eu fiz foi mudar tudo de 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

    • 0

relate perguntas