Binary(16) 字段截断 Guid 的尾随零

在 C# 中，我有一个byte[]名为 UniqueId 的字段。我将此字段作为 Binary(16) 存储在 SQL Server 数据库 (EF6) 中。

我注意到有时，存储的 guid 是 15 个字节而不是 16 个字节。当我这样做时，这会导致以下异常var guid = new Guid(uniqueId)从数据库检索值后：

System.ArgumentException：GUID 的字节数组必须恰好为 16 字节长。

经过调查后，我注意到每当我生成的 guid 在十六进制末尾包含“00”时，SQL 就会截断它！

Example:

生成的 Guid（通过 Guid.NewGuid）：FF96F954777E8941A04774CD157C5C00（16字节）

在 SQL Server 中存储二进制 (16)：0xFF96F954777E8941A04774CD157C5C（15字节）

如果您注意到的话，00最后被截断。因此，如果我查询该字段并尝试将其字节转换为 Guid，我将得到一个System.ArgumentException.

还有其他人遇到这个问题吗？解决方法是什么？我正在考虑一个包装Guid不断生成引导，直到它没有尾随零，但这看起来很hacky。

更新1：既然你们要求了，我运行了SQL分析器，这是EF生成的SQL（精简版）：

exec sp_executesql N'INSERT [dbo].[customers]([UniqueId])
VALUES (@0)',N'@0 varbinary(max)',@0=0xFF96F954777E8941A04774CD157C5C00

您会看到此行为BINARY(16) if the ANSI_PADDING该列的设置是OFF并且该列允许NULL ().

理想情况下，修复它需要更改表定义，以便该列使用uniqueidentifier数据类型或至少有ANSI_PADDING on.

要改变ANSI_PADDING语义将涉及SET ANSI_PADDING ON然后添加一个新的binary(16)列 - 从旧列填充它，然后删除并重命名。这是如果您的应用程序可以容忍可能的列重新排序，如果它无法处理这种重新排序并且UniqueId不是您创建新表并迁移所有数据所需的表中的最后一列。