Quando si chiama ToByteArray() su un GUID in .NET, l'ordinamento dei byte nell'array risultante non è quello che ci si aspetterebbe rispetto alla rappresentazione di stringa del GUID. Ad esempio, per il seguente GUID rappresentato come una stringa:Perché Guid.ToByteArray() ordina i byte come fa?
11223344-5566-7788-9900-aabbccddeeff
Il risultato di questo è ToByteArray():
44, 33, 22, 11, 66, 55, 88, 77, 99, 00, AA, BB, CC, DD, EE, FF
noti che l'ordine dei primi quattro byte è invertita. Anche i byte 4 e 5 vengono scambiati ei byte 6 e 7 vengono scambiati. Ma gli 8 byte finali sono nello stesso ordine in cui sono rappresentati come nella stringa.
Capisco che questo si sta verificando. Quello che vorrei sapere è perché .NET lo gestisce in questo modo.
Per riferimento, è possibile vedere alcune discussioni e confusione su questo (attribuito erroneamente ai database Oracle) here e here.
Vedere anche http://stackoverflow.com/questions/8064648/net-native-guid-conversion e [questo post di Eric Lippert da ** 2004 **!] (Http://blogs.msdn.com/b /ericlippert/archive/2004/05/25/141525.aspx) – AakashM
a) non importa. b) è un grosso problema di endianità. –
a) È davvero importante quando ti morde. Inoltre, avere una migliore comprensione non solo del modo in cui le cose funzionano, ma anche del perché funzionano in quel modo, ti rende più capace di evitare di essere morso da comportamenti contrari come questo. b) È stato chiaro fin dall'inizio che si tratta di un problema di endianità. Ma è particolarmente sconcertante perché gli 8 byte finali sono rimasti nel loro ordine originale. Inoltre, se si intende rappresentare un GUID come una stringa di hex, non avrebbe più senso rappresentarlo nell'ordine dei byte effettivi? –