Почему Guid.ToString( "n" ) не совпадает с шестнадцатеричной строкой, созданной из массива байтов одного и того же guid?

Рассмотрим следующий unit test:

    [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>.

Ответ 1

Ну, они те же, после первых 4 байтов. И первые четыре одинаковые, только в обратном порядке.

В принципе, если он создан из строки, он предположительно находится в формате "big-endian": самый старший байт влево. Тем не менее, при хранении внутри (на машине Intel-ish) байты упорядочиваются "мало-endian": старший байт вправо.

Ответ 2

Если вы сравните результаты, вы увидите, что первые три группы меняются на противоположные:

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 (самый старший байт - последний).

Ответ 3

GUID структурирован следующим образом:

int a
short b
short c
byte[8] d

Итак, для части, представленной a, ваш код возвращает байты. Все остальные части преобразуются правильно.