我创造这样一个GUID

I am creating a GUID like this

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

根据维基百科的有四个部分的GUID，这解释了四组为什么字节顺序切换。但是维基百科的文章还指出，所有部件都存储在大端格式。显然，前三个部分是不是大端。 GUID的的GetBytes（）方法用于创建非常相同的顺序返回的字节数。什么是交代了这种行为？

According to Wikipedia there are four parts in the guid and this explains why the bytes order switch in four groups. However the Wikipedia article also states that all parts are stored in Big Endian format. Obviously the first three parts are not Big Endian. The GetBytes() method of the guid returns the bytes in the very same order used for creation. What is the explaination for this behavior?

推荐答案

看来，MS是存储五个部分的结构。 前4个部分是2或4个字节长，因此，很可能存储在小端格式的本机类型（即，WORD和DWORD）。最后部分为6字节长，因此，它的处理方式不同（可能的阵列）。

It appears that MS are storing the five parts in a structure. The first 4 parts are either 2 or 4 bytes long and are therefore probably stored as a native type (ie. WORD and DWORD) in little endian format. The last part is 6 bytes long and it therefore handled differently (probably an array).

请问规格状态的GUID存储在大端秩序，或者说部分的存储是按照这个顺序，但indiviual部分可能是特定的实现？

Does the Spec state that the GUID is stored in big-endian order, or that the storage of parts are in that order but the indiviual parts may be implementation specific?

编辑：

从 UUID规范，第4.1.2节。布局和字节顺序（重点煤矿）：

From the UUID spec, section 4.1.2. Layout and Byte Order (emphasis mine):

要最大限度地减少混乱中八位位分配的UUID   记录定义仅定义在各字段来说是   八位字节组成的数字。这些字段是psented最 $ P $   第一显著之一。

To minimize confusion about bit assignments within octets, the UUID record definition is defined only in terms of fields that are integral numbers of octets. The fields are presented with the most significant one first.

...

在没有明确的应用程序或presentation协议的   规范相反，一个UUID是连接codeD作为128位的对象，   如下：

In the absence of explicit application or presentation protocol specification to the contrary, a UUID is encoded as a 128-bit object, as follows:

中的字段都设有codeD为16个字节，与规模和秩序   上面定义的字段，并且每个字段烯$ C $光盘与最   显著字节在前（称为网络字节顺序）。

The fields are encoded as 16 octets, with the sizes and order of the fields defined above, and with each field encoded with the Most Significant Byte first (known as network byte order).

这可能是MS已经sotred字节是正确的顺序，但没有打扰到网络到主机的顺序WORD和DWORD件presentation（这似乎根据该规范是确定在至少在我不熟练吧阅读。）

It might be that MS have sotred the bytes is the correct order, but have not bothered to network-to-host order the WORD and DWORD parts for presentation (which appears to be ok according to the spec, at least by my unskilled reading of it.)