-
-
Notifications
You must be signed in to change notification settings - Fork 754
Open
Description
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
Labels
No labels