Skip to content

Consider providing a big-endian Guid formatter #2240

@adrianotr

Description

@adrianotr

Is your feature request related to a problem? Please describe.

The byte layout used by .NET for Guid values is not aligned with the RFC 4122 representation that most languages and databases use. Internally, the first three components of the GUID (time_low, time_mid, time_hi_and_version) are stored in little endian form, while the remaining bytes use big endian. This mixed endianness is a legacy implementation detail and can be surprising when interoperating with other systems.

Describe the solution you'd like

It would be nice to have a big-endian guid formatter built-in in the library.
Here I provide an example implementation:

/// <summary>
/// A MessagePack formatter for System.Guid that serializes and deserializes values as a 16-byte binary
/// payload in RFC 4122 big-endian (“network”) byte order.
/// </summary>
public class BigEndianGuidFormatter : IMessagePackFormatter<Guid>
{
    public static readonly BigEndianGuidFormatter Instance = new();
    
    public void Serialize(ref MessagePackWriter writer, Guid guid, MessagePackSerializerOptions options)
    {
        writer.WriteBinHeader(16);
        var span = writer.GetSpan(16);
        guid.TryWriteBytes(span, bigEndian: true, out _);
        writer.Advance(16);
    }

    public Guid Deserialize(ref MessagePackReader reader, MessagePackSerializerOptions options)
    {
        var seq = reader.ReadBytes() ?? throw new InvalidOperationException("Got nil when guid was expected");
        return new Guid(seq.FirstSpan, bigEndian: true);
    }
}

Describe alternatives you've considered

String guids are not viable in my case because we make intense use of guids in the systems.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions