.NET 中的 Guid 字节顺序答案

【问题标题】：Guid Byte Order in .NET.NET 中的 Guid 字节顺序
【发布时间】：2012-04-28 18:26:15
【问题描述】：

我正在创建这样的 GUID

Guid g = new Guid(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0xA, 0xB, 0xC, 0xD, 0xE, 0xF });
Console.WriteLine(g);

这个输出

03020100-0504-0706-0809-0a0b0c0d0e0f

根据Wikipedia，guid 中有四个部分，这解释了为什么字节顺序在四组中切换。但是，Wikipedia 文章还指出，所有部分都以 Big Endian 格式存储。显然前三部分不是大端。 guid 的 GetBytes() 方法以用于创建的相同顺序返回字节。这种行为的解释是什么？

【问题讨论】：

标签： .net guid

【解决方案1】：

似乎 MS 将这五个部分存储在一个结构中。前 4 部分是 2 或 4 字节长，因此可能以小端格式存储为本机类型（即 WORD 和 DWORD）。最后一部分是 6 个字节长，因此处理方式不同（可能是一个数组）。

规范是否规定 GUID 以大端顺序存储，或者部分的存储是按该顺序但各个部分可能是特定于实现的？

编辑：

来自UUID spec，第 4.1.2 节。布局和字节顺序（强调我的）：

为了尽量减少八位字节中位分配的混淆，UUID
记录定义仅根据以下字段定义：
整数个八位位组。字段显示最多
重要的先。

...

在缺乏明确的应用程序或表示协议
规范相反，UUID被编码为128位对象，如下：

这些字段被编码为 16 个八位字节，其大小和顺序为上面定义的字段，并且每个字段都用最有效字节优先（称为网络字节顺序）。

可能是 MS 以正确的顺序存储了字节，但没有费心将 WORD 和 DWORD 部分按网络到主机的顺序进行演示（根据规范，至少在我看来是可以的不熟练的阅读。）

【讨论】：

根据 Wikipedia（我没有检查参考资料），应该实现 GUID 的 UUID 标准指出，部分应该以 Big Endian 编码。 UUID 和 GUID 规范都定义了大小依次为 4、2、2 和 8 字节的四个部分。
确实，当显示最后 8 字节部分时，通常显示为 2bytes-6bytes - 这两个似乎都是正确的大端（如您的示例所示）。
是的，最后 8 个字节在字符串表示中显示为 2-6 可能是出于可读性原因，但它们是同一数据部分的一部分。真正的问题是 Guid 是否违反标准或有其他解释。
很好的发现。我想知道我们是否应该现在更新维基百科的文章。

【解决方案2】：

我不是这里的专家，但你提到的 Wiki 页面也说：

然而，一个常用的[4]数据结构的参考 type 没有提到字节顺序

该引用 ([4]) 指向 http://msdn.microsoft.com/en-us/library/aa373931(VS.85).aspx，它随后确定了 Microsoft 如何将 GUID 实现为

typedef struct _GUID {
  DWORD Data1;
  WORD  Data2;
  WORD  Data3;
  BYTE  Data4[8];
} GUID;

由于最后 8 个字节存储为字节数组，我认为这可以识别您所看到的行为。

【讨论】：

所以 DWORD 和 WORD 出于某种原因是小端的？
en.wikipedia.org/wiki/Endianness 这取决于您的架构。在 x86 架构上，是的。
但这也意味着 GUID 违反了 UUID 标准？此外，维基百科的文章有点误导（说明 GUID 以 Big Endian 格式存储数据部分）
@Stilgar：uuid 标准和 GUID 文章仅声明它们以大端格式存储 - 似乎都没有明确说明 GUID/UUID 如何以人类可读的格式呈现。
大端 = 人类可读。人类首先写出最高有效数字（至少在所有左右脚本中）。 lwn.net/Articles/628233