Но определение varchar гласит, что он допускает строковые данные не в Юникоде . Но товарный знак (™) и зарегистрированный (®) символы Unicode символы . Противоречит ли определение свойству типа данных varchar?
Хотя другие ответы не являются правильными, я думаю, что это поможет указать на путаницу в базовой терминологии. Я подчеркнул два слова в приведенной выше цитате из вопроса в качестве примера этой путаницы. Когда документация по SQL Server говорит о Unicode и не-Unicode данных , они не говорят о символах . Они говорят о последовательности байтов, которые представляют определенные символы. Основное различие между типами Unicode ( NCHAR
, NVARCHAR
, XML
, и устаревшим / злой NTEXT
) и типами не-Unicode ( CHAR
, VARCHAR
и устаревший / злом TEXT
) является то , что типы из последовательности байт они могут хранить.
Типы, отличные от Unicode, хранят одну из нескольких 8-битных кодировок, а типы Unicode хранят одну 16-битную кодировку Unicode: UTF-16 Little Endian. Как уже упоминалось в других ответах, какие символы могут быть сохранены в 8-битной кодировке / кодировке, не относящейся к Юникоду, зависит от кодовой страницы, которая определяется с помощью сортировки. В то время как другие отметили, что значение байта «символа» может варьироваться в зависимости от кодовых страниц, на которых он обнаружен, значение байта может даже варьироваться в пределах одной и той же кодовой страницы при работе с одной из нескольких кодовых страниц EBCDIC (разновидности Windows- 1252), которые можно найти только в более старых версиях, которые не должны использоваться в действительности в SQL Server Collations (то есть, имена, начинающиеся с SQL_
).
Следовательно, определение является точным: любые символы, которые вы можете сохранить в не-Unicode-типе, всегда являются 8-битными (даже если они используют два 8-битных значения в комбинации как один «символ», что является Набор байтовых символов / кодовые страницы DBCS позволяют). И типы данных Unicode всегда 16-битные, даже если они иногда используют два 16-битных значения в комбинации как один «символ» (т. Е. Суррогатная пара, которая, в свою очередь, представляет дополнительный символ).
И, поскольку SQL Server изначально поддерживает кодировку UTF-8 VARCHAR
и CHAR
типы данных с SQL Server 2019,
VARCHAR
больше не может называться «не-Unicode». Итак, начиная с первой общедоступной бета-версии SQL Server 2019 в сентябре 2018 года, мы должны называть VARCHAR
его «8-битным типом данных», даже если речь идет о версиях, предшествующих SQL Server 2019. Эта терминология верна для всех 4 типов кодировок, которые можно использовать с VARCHAR
:
- Расширенный ASCII
- Двухбайтовые наборы символов (DBCS)
- EBCDIC
- UTF-8 (Юникод)
Только TEXT
тип данных (устарел начиная с SQL Server 2005, поэтому не используйте его) является «не-Unicode», но это лишь техническая составляющая, и ссылка на него как «8-битный тип данных» является точной.
NVARCHAR
, NCHAR
И NTEXT
могут быть отнесены к «UTF-16» или «16-битового типа данных». Я полагаю, что Oracle использует терминологию «только для Unicode» NVARCHAR
, но это не исключает возможности использования UTF-8 (также кодировки Unicode), который не будет работать, поэтому, вероятно, лучше придерживаться первые два варианта.
Подробнее о новых кодировках UTF-8 читайте в моем сообщении:
Собственная поддержка UTF-8 в SQL Server 2019: Спаситель или Лжепророк?
PS Я медленно работаю над обновлением документации по SQL Server, чтобы отразить эти изменения.
PPS Microsoft уже обновила некоторые страницы с информацией UTF-8, включая документацию по char и varchar, упомянутую в этом вопросе. Он больше не содержит фразу "не-Unicode". Но это только к вашему сведению; это не меняет вопроса, поскольку речь идет о кодировках не в Юникоде, содержащих символы, которые по ошибке считались единственными в Юникоде.