Why isn't Guid.ToString(“n”) the same as a hex string generated from a byte array of the same guid?

后端 未结 3 1201
面向向阳花
面向向阳花 2021-02-13 12:40

Consider the following unit test:

    [TestMethod]
    public void TestByteToString()
    {
        var guid = new Guid(\"61772f3ae5de5f4a8577eb1003c5c054\");
           


        
相关标签:
3条回答
  • 2021-02-13 13:08

    If you compare the results, you can see that the first three groups are reversed:

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

    That's because in the GUID structure, these 3 groups are defined as DWORD and two WORDs rather than bytes:

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

    so in memory, an Intel processor stores them in Little-endian order (the most significant byte the last).

    0 讨论(0)
  • 2021-02-13 13:08

    A GUID is structured as follows:

    int a
    short b
    short c
    byte[8] d
    

    So for the part represented by a your code gets the bytes reversed. All other parts are transformed correctly.

    0 讨论(0)
  • 2021-02-13 13:12

    Well, they are the same, after the first 4 bytes. And the first four are the same, just in the reverse order.

    Basically, when created from the string, it's assumed to be in "big-endian" format: Highest byte to the left. However, when stored internally (on an Intel-ish machine), the bytes are ordered "little-endian": highest order byte to the right.

    0 讨论(0)
提交回复
热议问题