CODEWITHSUNDEEP
c#.netguid
Cory McCarty
Cory McCarty

Reputation: 1405

Why does Guid.ToByteArray() order the bytes the way it does?

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 representation of the GUID. For example, for the following GUID represented as a string:

11223344-5566-7788-9900-aabbccddeeff

The result of ToByteArray() is this:

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

Note that the order of the first four bytes is reversed. Also bytes 4 and 5 are swapped and bytes 6 and 7 are swapped. But the final 8 bytes are in the same order they're represented as in the string.

I understand that this is occurring. What I would like to know is why .NET handles it this way.

For reference, you can see some discussion and confusion about this (incorrect attributed to Oracle databases) here and here.

Upvotes: 56

Views: 18627

Answers (2)

hIpPy
hIpPy

Reputation: 5085

@user7116's answer says why.

That said, I have wrote an extension method to fix the order,

byte[] ToByteArrayMatchingStringRepresentation(Guid)

which takes endianness into account using BitConverter, and changes the order in-place. This extension method is useful when converting the Guid to some other base (say base64/base32) and roundtripping (Guid -> bytes -> base64/base32 -> bytes -> Guid).

using System;

namespace rm.Extensions;

/// <summary>
/// Guid extensions.
/// </summary>
public static class GuidExtension
{
    /// <summary>
    /// Returns a 16-element byte array that contains the value of this instance
    /// matching its string representation (endian-agnostic).
    /// <para></para>
    /// See https://stackoverflow.com/questions/9195551/why-does-guid-tobytearray-order-the-bytes-the-way-it-does
    /// <remarks>
    /// <para></para>
    /// Note: The byte[] returned by <see cref="ToByteArrayMatchingStringRepresentation(Guid)"/> will not yield
    /// the original Guid with <see cref="Guid(byte[])"/> ctor.
    /// </remarks>
    /// </summary>
    public static byte[] ToByteArrayMatchingStringRepresentation(this Guid guid)
    {
        var bytes = guid.ToByteArray();
        TweakOrderOfGuidBytesToMatchStringRepresentation(bytes);
        return bytes;
    }

    /// <summary>
    /// Initializes a new instance of the <see cref="Guid"></see> structure by using the specified array of bytes
    /// matching its string representation (endian-agnostic).
    /// <para></para>
    /// See https://stackoverflow.com/questions/9195551/why-does-guid-tobytearray-order-the-bytes-the-way-it-does
    /// <remarks>
    /// <para></para>
    /// Note: The Guid returned by <see cref="ToGuidMatchingStringRepresentation(byte[])"/> will not yield
    /// the original byte[] with <see cref="Guid.ToByteArray()"/>.
    /// </remarks>
    /// </summary>
    public static Guid ToGuidMatchingStringRepresentation(this byte[] bytes)
    {
        _ = bytes ??
            throw new ArgumentNullException(nameof(bytes));
        if (bytes.Length != 16)
        {
            throw new ArgumentException("Length should be 16.", nameof(bytes));
        }
        TweakOrderOfGuidBytesToMatchStringRepresentation(bytes);
        return new Guid(bytes);
    }

    private static void TweakOrderOfGuidBytesToMatchStringRepresentation(byte[] guidBytes)
    {
        if (BitConverter.IsLittleEndian)
        {
            Array.Reverse(guidBytes, 0, 4);
            Array.Reverse(guidBytes, 4, 2);
            Array.Reverse(guidBytes, 6, 2);
        }
    }
}

source: https://github.com/rmandvikar/csharp-extensions/blob/dev/src/rm.Extensions/GuidExtension.cs

Upvotes: 1

user7116
user7116

Reputation: 64068

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.

Upvotes: 38

Related Questions