Почему Гуид не. ToString (“n”) то же как шестнадцатеричная строка сгенерирован от массива байтов того же гуида?
Рассмотрите следующий модульный тест:
[TestMethod]
public void TestByteToString()
{
var guid = new Guid("61772f3ae5de5f4a8577eb1003c5c054");
var guidString = guid.ToString("n");
var byteString = ToHexString(guid.ToByteArray());
Assert.AreEqual(guidString, byteString);
}
private String ToHexString(Byte[] bytes)
{
var hex = new StringBuilder(bytes.Length * 2);
foreach(var b in bytes)
{
hex.AppendFormat("{0:x2}", b);
}
return hex.ToString();
}
Вот результат:
Assert.AreEqual failed. Expected:<61772f3ae5de5f4a8577eb1003c5c054>. Actual:<3a2f7761dee54a5f8577eb1003c5c054>.
3 ответа
Ну, они такие же, после первых 4 байтов. И первые четыре такие же, только в обратном порядке.
Обычно при создании из строки предполагается, что она находится в формате "обратный порядок байтов": старший байт слева. Однако при хранении внутри (на машине Intel-типа) байты упорядочиваются по принципу "прямой порядок байтов": байт самого высокого порядка справа.
GUID структурирован следующим образом:
int a
short b
short c
byte[8] d
Таким образом, для части, представленной a, ваш код получает байты в обратном порядке. Все остальные части преобразуются правильно.
Если вы сравните результаты, то увидите, что первые три группы перевернуты:
61 77 2f 3a e5 de 5f 4a 8577eb1003c5c054 3a 2f 77 61 de e5 4a 5f 8577eb1003c5c054
Это потому, что в структуре GUID эти три группы определены как DWORD и два WORD, а не как байты:
{0x00000000,0x0000,0x0000,{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}
поэтому в памяти процессор Intel хранит их в Little-endian порядке (старший байт - последний).