Início / dba / Perguntas / 191595
Accepted
Álvaro González
Asked: 2017-11-24 07:46:44 +0800 CST

Não é possível atualizar "CO2" para "CO₂" na linha da tabela

  • 772

Dada esta tabela:

CREATE TABLE test (
    id INT NOT NULL,
    description NVARCHAR(100) COLLATE Modern_Spanish_CI_AS NOT NULL
);
INSERT INTO test (id, description) VALUES (1, 'CO2');

Percebi que não consigo corrigir um problema tipográfico:

SELECT * FROM test WHERE id = 1;
UPDATE test SET description = 'CO₂' WHERE id = 1;
SELECT * FROM test WHERE id = 1;

porque a atualização corresponde, mas não tem efeito:

id          description
----------- -----------
1           CO2

(1 affected rows)

(1 affected rows)

id          description
----------- -----------
1           CO2

(1 affected rows)

É como se o SQL Server determinasse que, como ₂ obviamente é apenas um minúsculo 2 , o valor final não será alterado, portanto não vale a pena alterá-lo.

Alguém poderia lançar alguma luz sobre isso e talvez sugerir uma solução alternativa (além de atualizar para um valor intermediário)?

sql-server sql-server-2008-r2

2 respostas

  1. Best Answer

    O subscrito 2 não faz parte do conjunto de caracteres varchar (em qualquer agrupamento, não apenas Modern_Spanish). Então, faça uma constante nvarchar:

    UPDATE test SET description = N'CO₂' WHERE id = 1;
    • 30

  2. @gbn já explicou o motivo básico e a correção, mas o motivo específico para o comportamento que você está vendo é este:

    1. Você está usando um VARCHARliteral (sem Nprefixo) em vez de um NVARCHARliteral (string com Nprefixo), portanto, o caractere Unicode será convertido em VARCHAR.
    2. VARCHARé uma codificação de 8 bits que é, na maioria dos casos, um byte por caractere, mas também pode ser dois bytes por caractere. Por outro lado, NVARCHARé uma codificação de 16 bits (UTF-16 Little Endian) que tem dois bytes ou quatro bytes por caractere.
    3. Devido à diferença no número de bytes disponíveis para usar para mapear caracteres, as codificações de 8 bits são, por sua própria natureza, muito mais limitadas no número de caracteres que podem ser mapeados. VARCHARdata é de até 256 caracteres para conjuntos de caracteres de byte único (a maioria deles) e até 65.536 caracteres para conjuntos de caracteres de byte duplo (apenas alguns deles). Por outro lado, NVARCHARos dados podem mapear pouco mais de 1,1 milhão de caracteres Unicode (embora pouco menos de 250k atualmente mapeados).
    4. Devido ao número limitado de mapeamentos que podem ser feitos com 8 bits/ VARCHARdados, diferentes agrupamentos de caracteres (com base em Idioma/Cultura) estão espalhados por várias "Páginas de Código" (ou seja, conjuntos de caracteres)
    5. Cada agrupamento especifica qual página de código, se houver, deve ser usada para VARCHARdados ( NVARCHARsão todos os caracteres)
    6. Ao converter uma string literal ou variável de NVARCHAR(ou seja, Unicode / UTF-16 / todos os caracteres) para VARCHAR(conjunto de caracteres com base na página de código que é especificada na maioria dos agrupamentos), o agrupamento padrão do banco de dados é usado
    7. Se a página de código do agrupamento que está sendo usado para a conversão não contiver o mesmo caractere, mas contiver um mapeamento de "melhor ajuste", o mapeamento de "melhor ajuste" será usado.
    8. Se a página de código do agrupamento que está sendo usado para a conversão não contiver o mesmo caractere ou contiver um mapeamento de "melhor ajuste", o caractere de "substituição" padrão será usado (mais comumente ?).

    Então, o que você está vendo é uma conversão NVARCHARpara VARCHARdevido à falta do Nprefixo na string literal. E a página de código do Collation padrão para o banco de dados não contém exatamente o mesmo caractere, mas um mapeamento de "melhor ajuste" foi encontrado, e é por isso que você está obtendo um 2em vez de um ?.

    Você pode ver esse efeito fazendo o seguinte teste simples:

    SELECT '₂', N'₂';

    Devoluções:

    2    ₂

    Para ser claro, SE a página de código do agrupamento padrão para o banco de dados contivesse exatamente o mesmo caractere, ela teria sido traduzida para o mesmo caractere nessa página de código. E, então, no seu caso, já que você está armazenando em uma NVARCHARcoluna, ele teria traduzido novamente, de volta ao caractere Unicode original. O exemplo final abaixo mostra esse comportamento.

    IMPORTANTE: Esteja ciente de que a conversão ocorre à medida que o literal da string está sendo interpretado, antes de ser armazenado na coluna. Isso significa que, mesmo que a coluna possa conter esse caractere, ela já terá sido convertida em outra coisa, com base no Collation padrão do banco de dados, tudo devido a deixar de fora o Nprefixo nessa string literal. E isso é exatamente o que você está (ou estava) experimentando.

    Por exemplo, se o agrupamento padrão do seu banco de dados fosse um dos agrupamentos coreanos (um dos quatro conjuntos de caracteres de byte duplo), você não teria visto esse problema, pois o caractere "Subscrito 2" está disponível nesse caractere definido (Página de código 949). Tente o seguinte teste para ver (ele usa o Collation da coluna em vez do Collation padrão do banco de dados, pois é mais fácil de mostrar):

    CREATE TABLE #TestChar
(
    [8bit_Latin1_General-1252] VARCHAR(2) COLLATE Latin1_General_100_CI_AS_SC,
    [8bit_Korean-949] VARCHAR(2) COLLATE Korean_100_CI_AS_SC,
    [UTF16LE_Latin1_General-1252] NVARCHAR(2) COLLATE Latin1_General_100_CI_AS_SC
);

INSERT INTO #TestChar VALUES (N'₂', N'₂', N'₂');

SELECT * FROM #TestChar;

    Devoluções:

    8bit_Latin1_General-1252    8bit_Korean-949    UTF16LE_Latin1_General-1252
2                           ₂                  ₂

    Como você pode ver, o Latin1_General Collations, que usa a página de código 1252 (mesma página de código que o Modern_SpanishCollations usa) para VARCHARdados, não tem uma correspondência exata, mas eles têm um mapeamento de "melhor ajuste" (que é o que você está vendo ). MAS, os agrupamentos coreanos, que usam a página de código 949 para VARCHARdados, têm uma correspondência exata para o caractere "Subscrito 2".

    Para ilustrar ainda mais, podemos criar um novo banco de dados com um Collation padrão de um dos Collations coreanos e, em seguida, executar o SQL exato que está na pergunta:

    CREATE DATABASE [TestKorean-949] COLLATE Korean_100_CI_AS_KS_WS_SC;
ALTER DATABASE [TestKorean-949] SET RECOVERY SIMPLE;
GO

USE [TestKorean-949];

CREATE TABLE test (
    id INT NOT NULL,
    description NVARCHAR(100) COLLATE Modern_Spanish_CI_AS NOT NULL
);
INSERT INTO test (id, description) VALUES (1, 'CO2');


SELECT * FROM test WHERE id = 1;
UPDATE test SET description = 'CO₂' WHERE id = 1;
SELECT * FROM test WHERE id = 1;

    Devoluções:

    id  description
1   CO2


id  description
1   CO₂

    ATUALIZAR

    Para quem estiver interessado em descobrir mais sobre o que exatamente está acontecendo aqui (ou seja, todos os detalhes sangrentos), veja a investigação em duas partes que acabei de postar:

    • 22

relate perguntas