When you call ToByteArray()
on a GUID in .NET, the ordering of the bytes in the resulting array is not what you\'d expect as compared to the string representati
If you read the Examples section from the GUID constructor, you'll find your answer:
Guid(1,2,3,new byte[]{0,1,2,3,4,5,6,7})
creates a Guid that corresponds to"00000001-0002-0003-0001-020304050607"
.
a
is a 32-bit integer, b
is a 16-bit integer, c
is a 16-bit integer, and d
is simply 8 bytes.
Because a
, b
, and c
are integer types rather than raw bytes, they are subject to endian ordering when choosing how to display them. The RFC for GUID's (RFC4122) states that they should be presented in big endian format.