如何在SQL Server中真正创建零长度二进制值？ODBC绑定实现遇异常

我之前在开发ODBC二进制类型绑定的时候也踩过一模一样的坑，咱们先拆解下你遇到的这个问题：

首先看你执行的SQL操作：

CREATE TABLE demo (bar BINARY)
GO
INSERT INTO demo VALUES (0x)
GO
(1 rows affected)
SELECT * FROM demo WHERE bar = 0x00
GO
bar
----
0x00
(1 rows affected)
SELECT DATALENGTH(bar) FROM demo WHERE bar = 0x00
GO

核心原因：固定长度BINARY类型的特性 #

这里的关键问题出在你用的BINARY类型上：

• SQL Server的BINARY是固定长度二进制类型，如果创建表时不指定长度，默认是BINARY(1)。
• 当你插入0x（空十六进制字面量）时，固定长度类型会自动用零字节填充到列的指定长度，所以最终存储的是一个单零字节（0x00），而不是你预期的长度为0的空二进制值。

解决办法：用VARBINARY存储可变长度二进制数据 #

如果你需要支持真正的空二进制值（长度为0），应该改用VARBINARY类型，它是可变长度的，不会自动填充零字节：

CREATE TABLE demo (bar VARBINARY)
GO
INSERT INTO demo VALUES (0x)
GO
SELECT DATALENGTH(bar) FROM demo
GO

执行这段代码后，DATALENGTH会返回0，而且用WHERE bar = 0x就能匹配到这条记录，不会和0x00混淆。

ODBC绑定层面的注意事项 #

在ODBC绑定参数的时候，还要配合类型做对应的处理：

• 对于BINARY类型，驱动会严格按照列的固定长度处理，即使你传入长度为0的缓冲区，也会被填充到列长度的零字节；
• 对于VARBINARY，需要正确设置参数的长度指示器（比如使用SQL_LEN_BINARY_ATTR(0)），明确告诉ODBC驱动这是一个长度为0的二进制值，避免驱动做默认填充。

简单来说，BINARY适合存储固定长度的二进制数据（比如哈希值），而VARBINARY才是存储可变长度、可能为空的二进制数据的正确选择。

内容的提问来源于stack exchange，提问作者Christopher Done