Mas a definição de varchar diz que permite dados de string não unicode . Mas os símbolos de marca comercial (™) e registrada (®) são caracteres Unicode . A definição contradiz a propriedade do tipo de dados varchar?
Embora as outras respostas não estejam incorretas, acho que ajudaria a apontar uma confusão na terminologia básica. Eu enfatizei duas palavras na citação acima da pergunta como um exemplo dessa confusão. Quando a documentação do SQL Server fala de Unicode e não-Unicode de dados , eles são não falando sobre os personagens . Eles estão falando das seqüências de bytes que representam certos caracteres. A principal diferença entre os tipos de Unicode ( NCHAR
, NVARCHAR
,XML
, e a obsoleta / mal NTEXT
) e os tipos não-Unicode ( CHAR
, VARCHAR
e a obsoleta / mal TEXT
) é o que tipos de sequências de bytes que podem armazenar.
Os tipos não Unicode armazenam uma das várias codificações de 8 bits, enquanto os tipos Unicode armazenam uma única codificação Unicode de 16 bits: UTF-16 Little Endian. Como as outras respostas mencionaram, quais caracteres podem ser armazenados em uma codificação de 8 bits / não-Unicode depende da página de código, que é determinada pelo agrupamento. Enquanto outros observaram que o valor de byte de um "caractere" pode variar entre as páginas de código em que ele se encontra, o valor de byte pode até variar dentro da mesma página de código ao lidar com uma das várias páginas de código EBCDIC (variações do Windows- 1252), que são encontrados apenas nos mais antigos, não devem realmente ser usados Collations do SQL Server (ou seja, aqueles com nomes começando comSQL_
).
Portanto, a definição é precisa: todos os caracteres que você pode gerenciar para armazenar em um tipo não Unicode são sempre de 8 bits (mesmo que usem dois valores de 8 bits em combinação como um "caractere" único, que é o que o Double- As páginas de código do Byte Character Set / DBCS permitem). E os tipos de dados Unicode são sempre de 16 bits, mesmo que às vezes usem dois valores de 16 bits em combinação como um "caractere" único (ou seja, um par substituto que, por sua vez, representa um Caractere Suplementar).
E, devido ao suporte nativo do SQL Server à codificação UTF-8 para VARCHAR
e CHAR
tipos de dados a partir do SQL Server 2019,
VARCHAR
não pode mais ser chamado de "não Unicode". Portanto, começando com a primeira versão beta pública do SQL Server 2019 em setembro de 2018, devemos nos referir VARCHAR
como um "tipo de dados de 8 bits", mesmo quando falamos em termos de versões anteriores ao SQL Server 2019. Essa terminologia é válida para todos os quatro tipos de codificações que podem ser usadas comVARCHAR
:
- ASCII estendido
- Conjuntos de caracteres de byte duplo (DBCS)
- EBCDIC
- UTF-8 (Unicode)
Apenas o TEXT
tipo de dados (descontinuado no SQL Server 2005, portanto, não o use) é "não Unicode", mas isso é apenas um detalhe técnico, e a referência a ele como "tipo de dados de 8 bits" é precisa.
NVARCHAR
,, NCHAR
e NTEXT
pode ser referido como "UTF-16" ou "tipo de dados de 16 bits". A Oracle, acredito, usa a terminologia de "somente Unicode" paraNVARCHAR
, mas isso não descarta claramente a possibilidade de usar UTF-8 (também uma codificação Unicode), que não funcionará, portanto, provavelmente é melhor as duas primeiras opções.
Para detalhes sobre as novas codificações UTF-8, consulte o meu post:
Suporte nativo a UTF-8 no SQL Server 2019: Salvador ou falso profeta?
PS: Estou trabalhando lentamente na atualização da documentação do SQL Server para refletir essas alterações.
PPS A Microsoft já atualizou algumas páginas com informações UTF-8, incluindo a documentação char e varchar mencionada na pergunta. Ele não contém mais a frase "não Unicode". Mas isso é apenas um FYI; isso não muda a questão, pois trata-se de codificações não Unicode contendo caracteres que, por engano, foram pensados apenas como Unicode.