Início / dba / Perguntas / 48660
Accepted
usr
Asked: 2013-08-25 03:06:18 +0800 CST

A comparação do binário 0x e 0x00 acaba sendo igual no SQL Server

  • 772

Parece que o SQL Server considera 0x e 0x00 valores iguais:

SELECT CASE WHEN 0x = 0x00 THEN 1 ELSE 0 END

Isso gera 1.

Como posso obter um verdadeiro comportamento de comparação bit a bit binário? Além disso, quais são as regras exatas sob as quais dois (var)binaryvalores são considerados iguais?

Observe também o seguinte comportamento:

--prints just one of the values
SELECT DISTINCT [Data]
FROM (VALUES (0x), (0x00), (0x0000)) x([Data])

--prints the obvious length values 1, 2 and 3
SELECT DATALENGTH([Data]) AS [DATALENGTH], LEN([Data]) AS [LEN]
FROM (VALUES (0x), (0x00), (0x0000)) x([Data])

O pano de fundo da questão é que estou tentando deduplicar dados binários. Eu preciso de GROUP BYdados binários, não apenas comparar dois valores. Estou feliz por ter notado esse problema.

Observe que HASHBYTESisso não oferece suporte a LOBs. Eu também gostaria de encontrar uma solução mais simples.

sql-server sql-server-2012

2 respostas

  1. Best Answer

    Não consegui encontrar esse comportamento de comparação especificado em nenhum lugar no BOL.

    Mas a comparação de igualdade Connect Item Invalid para dados varbinary com zeros preenchidos à direita afirma que

    Basicamente, o padrão deixa para a implementação tratar as strings que diferem apenas por [trailing] 00como iguais ou menores. Nós o tratamos como iguais.

    O Connect Item também informa que a presença de zeros à direita é o único caso em que o SQL Server difere do comportamento de comparação byte a byte.

    Para distinguir entre dois valores binários no SQL Server que diferem apenas por 0x00caracteres à direita, você também pode adicionar DATALENGTHà comparação, conforme indicado em sua pergunta.

    A razão para preferir DATALENGTHem vez de LENgeralmente aqui é porque o último dá uma conversão implícita para varchare então você tem o problema com os espaços à direita.

    +-------------+--------------------+
| LEN(0x2020) | DATALENGTH(0x2020) |
+-------------+--------------------+
|           0 |                  2 |
+-------------+--------------------+

    Embora qualquer um funcione no seu caso de uso.

    • 5

  2. Curiosamente, os dois valores 0x0 e 0x00 são apenas representações de caracteres diferentes para o mesmo valor armazenado. Tente executar o trecho a seguir para provar isso a si mesmo.

    DECLARE @foo    sql_variant
,  @bar         sql_variant
,  @bat         sql_variant

SET @foo = 0x0
SET @bar = 0x00
SET @bat = 0x00000000

SELECT 'foo' AS 'Var',  @foo                AS 'Value'
,  SQL_VARIANT_PROPERTY(@foo, 'BaseType')   AS 'BaseType'
,  SQL_VARIANT_PROPERTY(@foo, 'Precisionh') AS 'Precision'
,  SQL_VARIANT_PROPERTY(@foo, 'Scale')      AS 'Scale'
,  SQL_VARIANT_PROPERTY(@foo, 'MaxLength')  AS 'MaxLength'
UNION
SELECT 'bar' AS 'Var',  @bar
,  SQL_VARIANT_PROPERTY(@bar, 'BaseType')
,  SQL_VARIANT_PROPERTY(@bar, 'Precisionh')
,  SQL_VARIANT_PROPERTY(@bar, 'Scale')
,  SQL_VARIANT_PROPERTY(@bar, 'MaxLength')
UNION
SELECT 'bat' AS 'Var',  @bat
,  SQL_VARIANT_PROPERTY(@bat, 'BaseType')
,  SQL_VARIANT_PROPERTY(@bat, 'Precisionh')
,  SQL_VARIANT_PROPERTY(@bat, 'Scale')
,  SQL_VARIANT_PROPERTY(@bat, 'MaxLength')

SELECT
   CASE
      WHEN @foo = @bar
      THEN 'equal' 
      ELSE 'NOT EQUAL' 
   END AS TestResults

    Posso entender por que o preenchimento zero surpreenderia as pessoas, mas esse tem sido o comportamento padrão há muito tempo, então acho que já esperava isso.

    -PatP

    • 3

relate perguntas