为什么Guid.ToByteArray（）以这种方式sorting字节？

当您在.NET中以GUID调用ToByteArray() ，与GUID的string表示forms相比，生成的数组中的字节顺序不是您所期望的。 例如，对于以string表示的以下GUID：

 11223344-5566-7788-9900-aabbccddeeff 

ToByteArray()的结果是这样的：

 44, 33, 22, 11, 66, 55, 88, 77, 99, 00, AA, BB, CC, DD, EE, FF 

请注意，前四个字节的顺序是相反的。 字节4和5交换，字节6和7交换。 但最后的8个字节与它们在string中的表示顺序相同。

我明白这是发生。 我想知道的是为什么.NET这样处理它。

作为参考，你可以在这里和这里看到一些关于这个（不正确的归因于Oracle数据库）的讨论和困惑。

Answer 1

如果您从GUID构造函数中读取“ 示例”部分 ，则会发现您的答案：

Guid(1,2,3,new byte[]{0,1,2,3,4,5,6,7})创build一个对应于"00000001-0002-0003-0001-020304050607"的Guid。

a是32位整数， b是16位整数， c是16位整数， d仅是8个字节。

因为a ， b和c是整数types而不是原始字节，所以在select如何显示它们时，它们会受到endian顺序的限制。 GUID（RFC4122）的RFC规定，它们应该以大端格式显示。