Len () против длины данных () в SQL Server 2005

Question

Недавно я столкнулся с проблемой при использовании len() в запросе для определения длины запроса, len() не учитывал конечные пробелы в значении. Но datalength() считает и пробелы в конце.

Означает ли это, что если я выполняю какую-либо операцию, которая имеет дело с фактической длиной значения, тогда я должен использовать dalalength() сверх len().

ex: Если мне нужно, чтобы значение определенного значения было длиной 10 символов. т.е. если значение имеет длину 3 символа, я должен добавить к нему 7 пробелов.

Answer 1

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

Answer 2

Да, это именно то, что вы должны сделать. Если вы хотите просто получить количество символов, исключая пробелы, вы должны использовать функцию LEN(), тогда как во всех остальных случаях DATALENGTH().

Даже LEN() документация содержит информацию о том, что для получения количества байтов, представляющих расширение, вы должны использовать DATALENGTH()

Вот ссылки на документы MSDN:

LEN ()

DATALENGTH ()

Answer 3

len подсчитывает количество используемых символов, а не требуемое хранилище, это будет еще более очевидно, когда вы используете nvarchar вместо varchar

len также не учитывает конечные пробелы

взгляните на это

declare @v nchar(5)
select @v ='ABC  '


select len(@v),datalength(@v)

и вывод для len равен 3, а вывод для длины данных = 10

Answer 4

Я собирался использовать Лен (Заменить ('бла-бла', '', '_') предложение, когда оно поразило меня, может быть более эффективным для использования. Просто отправляю сообщения на случай, если кто-то наткнется на эту ветку, как я.

len ('бла-бла' + '.') - 1

Answer 5

Просто используйте Replace ():

SELECT LEN(REPLACE(N'4 Trailing Spaces:    ', ' ', '_'))

Это заменит конечные пробелы символом, который LEN () будет фактически считать.

Проблема с DataLength () заключается в том, что вы должны следить за тем, является ли ваша строка Unicode (nChar, nVarChar) или ASCII (Char, VarChar), чтобы знать, нужно ли вам делить длину данных строки Unicode на 2.

Answer 6

К сожалению, не существует идеального решения, о котором я знаю.

Одно из предложенных решений, LEN(string + '.')-1 возвращает неверные результаты (-1), если строка имеет Unicode размера 4000 или не-Unicode и размера 8000. Это происходит потому, что объединение игнорируется. Вы можете преодолеть это, если хотите, приведя строку к строке размера MAX: LEN(CAST(string as nvarchar(max)) + '.')-1, но стоит ли это того?

Как уже упоминалось, DATALENGTH(string) возвращает количество байтов, использованных для хранения. Для строк Unicode может быть недостаточно разделить результат на 2: Суррогатные символы Unicode могут занимать более 16 бит.

В общем, помните об ограничениях каждого подхода и выберите то, во что вы верите, вызовет у вас меньше проблем.