为什么不是Guid.ToString（“n”）与从同一个GUID的字节数组生成的十六进制字符串相同？

Question

考虑下面的单元测试：

[TestMethod] 
    public void TestByteToString() 
    { 
     var guid = new Guid("61772f3ae5de5f4a8577eb1003c5c054"); 
     var guidString = guid.ToString("n"); 
     var byteString = ToHexString(guid.ToByteArray()); 

     Assert.AreEqual(guidString, byteString); 
    } 

    private String ToHexString(Byte[] bytes) 
    { 
     var hex = new StringBuilder(bytes.Length * 2); 
     foreach(var b in bytes) 
     { 
      hex.AppendFormat("{0:x2}", b); 
     } 
     return hex.ToString(); 
    } 

这里的结果：

Assert.AreEqual failed. Expected:<61772f3ae5de5f4a8577eb1003c5c054>. Actual:<3a2f7761dee54a5f8577eb1003c5c054>.

Answer 1

那么，它们是相同的，前4个字节后。前四个是相同的，只是以相反的顺序。

基本上，从字符串创建时，它被认为是“big-endian”格式：最高字节在左边。但是，当存储在内部（在Intel-ish机器上）时，字节排序为“little-endian”：最高位字节在右边。

Answer 2

如果比较的结果，你可以看到，前三组被颠倒：

 
61 77 2f 3a e5 de 5f 4a 8577eb1003c5c054 
3a 2f 77 61 de e5 4a 5f 8577eb1003c5c054 

这是因为在GUID structure，这3组被定义为DWORD和两个WORD真是让人不是字节：

{0x00000000,0x0000,0x0000,{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}} 

因此在内存中，英特尔处理器以Little-endian顺序（最后一个最重要的字节）存储它们。

Answer 3

一个GUID结构如下：那么通过a代表的部分

int a 
short b 
short c 
byte[8] d 

你的代码获取字节逆转。所有其他部分都正确转换。