Всегда ли nvarchar хранит каждый символ в двух байтах? - PullRequest
11 голосов
/ 17 января 2011

Я (возможно, наивно) предполагал, что в SQL Server nvarchar будет хранить каждый символ в двух байтах.Но это не всегда так.Документация предполагает, что некоторые символы могут занимать больше байтов.У кого-нибудь есть окончательный ответ?

Ответы [ 3 ]

16 голосов
/ 17 января 2011

да, он использует 2 байта, использует длину данных для получения размера хранилища, вы не можете использовать LEN, потому что LEN просто считает символы, см. Здесь: Различия между LEN и DATALENGTH в SQL Server

DECLARE @n NVARCHAR(10)
DECLARE @v VARCHAR(10)

SELECT @n = 'A', @v='A'

SELECT  DATALENGTH(@n),DATALENGTH(@v)

---------
2 1

Вот что есть в Books On Line: http://msdn.microsoft.com/en-us/library/ms186939.aspx

Символьные типы данных, которые либо фиксированная длина, нчар или переменная длина, nvarchar, Unicode данные и использовать UNICODE UCS-2 набор символов.

нчар [(n)]

Unicode фиксированной длины символьные данные из n символов. н должен быть значением от 1 до 4000. Размер хранилища в два раза больше n байтов. ISO синонимы для nchar являются национальными символ и национальный характер.

nvarchar [(n | max)]

Unicode-символ переменной длины данные. n может быть значением от 1 до 4000. Макс указывает, что максимум Размер хранилища составляет 2 ^ 31-1 байт. объем хранилища, в байтах, в два раза количество введенных символов + 2 байт. Введенные данные могут быть 0 длина символов Синонимы ISO для nvarchar бывают разные национальные символы и национальный характер меняется.

При этом сжатие Юникода было введено в SQL Server 2008 R2, поэтому он может хранить ascii как 1 байт, о сжатии Юникода можно прочитать здесь

4 голосов
/ 17 января 2011

Мое понимание этой проблемы заключается в том, что сервер SQL использует UCS-2 для внутреннего использования, но его реализация UCS-2 была взломана для поддержки подмножества символов длиной до 4 байтов в наборе символов GB18030 , которые хранятся как UCS-2, но прозрачно преобразуются ядром базы данных обратно в многобайтовые символы при запросе.

Суррогатные / дополнительные символы не полностью поддерживаются - реализация ряда строковых функций сервера SQL нене поддерживает суррогатные пары, как подробно здесь .

4 голосов
/ 17 января 2011

Учитывая, что имеется более 65536 символов, должно быть очевидно, что символ не может вмещаться всего в два октета (то есть 16 бит).

SQL Server, как и большинство продуктов Microsoft (Windows, .NET, NTFS и & hellip;), использует UTF-16 для хранения текста, в котором символ занимает два или четыре октета, хотя, как указывает @SQLMenace, текущий версии SQL Server используют сжатие, чтобы уменьшить это.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...