Consider the following unit test:
[TestMethod]
public void TestByteToString()
{
var guid = new Guid(\"61772f3ae5de5f4a8577eb1003c5c054\");
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 WORD
s 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).
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.
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.