¿Por qué Guid.ToByteArray () ordena los bytes de la forma en que lo hace?

Cuando llama a ToByteArray() en un GUID en .NET, el orden de los bytes en la matriz resultante no es lo que esperaría en comparación con la representación de cadena del GUID. Por ejemplo, para el siguiente GUID representado como una cadena:

 11223344-5566-7788-9900-aabbccddeeff 

El resultado de ToByteArray() es este:

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

Tenga en cuenta que el orden de los primeros cuatro bytes está invertido. También los bytes 4 y 5 se intercambian y los bytes 6 y 7 se intercambian. Pero los últimos 8 bytes están en el mismo orden en que se representan como en la cadena.

Entiendo que esto está ocurriendo. Lo que me gustaría saber es por qué .NET lo maneja de esta manera.

Como referencia, puede ver un poco de discusión y confusión acerca de esto (bases de datos incorrectas atribuidas a Oracle) aquí y aquí .

Si lees la sección Ejemplos del constructor del GUID , encontrarás tu respuesta:

Guid(1,2,3,new byte[]{0,1,2,3,4,5,6,7}) crea un Guid que corresponde a "00000001-0002-0003-0001-020304050607" .

a es un entero de 32 bits, b es un entero de 16 bits, c es un entero de 16 bits d es simplemente 8 bytes.

Como a , c son tipos de enteros en lugar de bytes sin formato, están sujetos a la ordenación endian cuando eligen cómo mostrarlos. El RFC para GUID (RFC4122) establece que deben presentarse en formato big endian.