Unicode no SQL Server: caracteres, bytes e perda de texto

Trocar uma coluna para nvarchar não recupera texto já convertido em pontos de interrogação. Correção Unicode depende do percurso inteiro: decodificação, aplicação, parâmetros, expressões SQL, coluna e exportação precisam preservar os mesmos caracteres.

Separar caracteres de armazenamento

Em nvarchar(n), n representa pares de bytes UTF-16, não garante n caracteres visíveis. Caracteres suplementares podem precisar de duas unidades. Um caractere exibido também pode combinar vários pontos de código, como letra e acento. Limites visuais da aplicação e limites de armazenamento podem divergir.

DECLARE @text nvarchar(20)=N'café ';
SELECT LEN(@text) AS LengthWithoutTrailingSpaces,
       DATALENGTH(@text) AS StorageBytes;
DECLARE @emoji nvarchar(2)=N'😀';
SELECT LEN(@emoji COLLATE Latin1_General_100_CI_AS_SC) AS Characters,
       DATALENGTH(@emoji) AS StorageBytes;

A primeira medição mostra que LEN ignora espaços finais e DATALENGTH mede bytes. LEN sozinho não valida preservação exata. A segunda usa collation compatível com caracteres suplementares: o emoji conta como um caractere, mas ocupa quatro bytes em nvarchar.

N cria um literal Unicode. Sem esse prefixo, uma conversão por página de códigos pode perder caracteres antes da atribuição. Parâmetros da aplicação também devem usar o tipo Unicode previsto. Inclua texto não latino verdadeiro, não apenas nomes ASCII.

Comparar codificações com dados reais

SQL Server 2019 suporta UTF-8 para varchar sob collations apropriadas. Isso não transforma automaticamente colunas varchar existentes em Unicode. Collation e expressões intermediárias importam. Em varchar(n), n limita bytes; caracteres multibyte reduzem a quantidade armazenável.

UTF-8 pode economizar espaço em conteúdo predominantemente ASCII, mas outras escritas precisam de mais bytes. Compare valores e índices representativos sem presumir economia universal de metade. Versão, limites e compatibilidade de clientes fazem parte da escolha.

Mudar collation também afeta unicidade. Comparações sem distinção de acentos ou maiúsculas podem considerar iguais entradas diferentes. Textos visualmente idênticos podem ter sequências diferentes de pontos de código. Defina normalização e identidade explicitamente.

Verificar todo o percurso

Prepare acentos, cirílico, CJK, emoji, marcas combinantes, aspas e espaços finais significativos. Envie pela API real, inserção parametrizada, leitura, serialização e exportação. Compare sequência retornada e original, além de bytes quando necessário. Uma inserção correta testa somente uma etapa.

Antes de migrar, meça comprimentos máximos em bytes e valores perto do limite. Revise índices, restrições, colunas calculadas e integrações com parâmetros varchar. Uma cópia de teste com comparação de ida e volta detecta perdas invisíveis em contagens de linhas.

Se dados antigos já contêm substituições, procure a fonte original. Uma conversão de tipo não adivinha o texto perdido. Recupere a partir de fonte ou backup verificado e identifique linhas impossíveis de restaurar fielmente.

O objetivo é devolver a mesma sequência recebida, exceto pela normalização acordada. Teste também download e reimportação de arquivos. Acrescente valores exatamente no limite e outros acima dele para confirmar rejeição explícita, sem perda silenciosa. Verifique separadamente mensagens de erro da API e do banco para que o usuário receba uma explicação consistente. Driver e transformações importam tanto quanto a definição da coluna.

Confira também ordenação e chaves únicas após qualquer troca de collation.

Referências técnicas: Microsoft Learn: nvarchar · Microsoft Learn: Unicode and UTF-8 · Microsoft Learn: DATALENGTH.