74 lines
3.6 KiB
Go
74 lines
3.6 KiB
Go
/*
|
|
Package uuidx intends to supplement [github.com/google/uuid].
|
|
|
|
# Microsoft GUID Shenanigans
|
|
|
|
The following functions are provided to deal with [Microsoft's incompetence]:
|
|
|
|
* [DetectMsGuid] (a confidence'd determination if a UUID is a Microsoft GUID or not)
|
|
* [IsFlippedEndian] for flipped-endian [uuid.UUID] comparison (e.g. a is the Microsoft-flipped-endian version of b)
|
|
* [IsMsGuid] (wraps [DetectMsGuid] and returns true if confidence is reasonably strong that it's a Microsoft GUID)
|
|
* [IsRfc] (the inverse of IsMsGuid, but also checks for strict RFC compliance and returns which RFC)
|
|
* [MsGuidToUuid] (explicitly convert/ensure a GUID/UUID is likely a UUID)
|
|
* [ToggleUuidMsGuid] (blindly flip the endianness of selected byte ranges for MS GUID <-> UUID conversion)
|
|
* [UuidToMsGuid] (explicitly convert/ensure a GUID/UUID is likely an MS GUID)
|
|
|
|
Microsoft, in their typical insanity, uses a proprietary UUID format (usually referred to as the "Microsoft GUID Format"
|
|
or "Mixed-Endian Format").
|
|
|
|
Normally for, for example a UUIDv4, it's structured as thus per RFC 9562 [§ 5.4] (which obsoletes RFC 4122 [§ 4.4]):
|
|
|
|
A B C D E
|
|
HEX(BE(uint32))-HEX(BE(uint16))-HEX(BE(uint16))-HEX(BE(<uint16>), BE(<6 bytes>))
|
|
|
|
(where <BE> is big-endian packing).
|
|
|
|
However, thanks to Microsoft we can't have nice things. They decided to completely ignore the standard, and
|
|
instead keep D/E as big-endian *but use little-endian* for A through C inclusive:
|
|
|
|
A B C D E
|
|
HEX(LE(uint32))-HEX(LE(uint16))-HEX(LE(uint16))-HEX(BE(<uint16>), BE(<6 bytes>))
|
|
|
|
"Surely that had SOME reason to do that," you may say to yourself, "they wouldn't make some arbitrary formatting
|
|
change from a standard just because."
|
|
|
|
You would be wrong. To my knowledge, they have never provided any technological justfification to this insanity,
|
|
and now it's infected its way into a slew of other technologies they've had their grubby little hands involved in
|
|
(e.g. UEFI). And it's of course too late to change.
|
|
|
|
So anyways here's a library to make dealing with Microsoft's hubris a little easier.
|
|
|
|
# Validation/Verification
|
|
|
|
Aside from trying to address Microsoft silliness, there are some additional functions:
|
|
|
|
* [Equal] for [uuid.UUID] comparison
|
|
* [IsMaxUUID] (if a given [uuid.UUID] is an RFC 9562 [§ 5.10] UUID)
|
|
* [IsNilUUID] (if a given [uuid.UUID] is an RFC 9562 [§ 5.9] UUID)
|
|
* [IsValid] (If an RFC can be considered safely conformant to RFC spec)
|
|
|
|
# Future Incorporation/Deprecation/Obsolescence
|
|
|
|
Worth keeping an eye on are:
|
|
|
|
* https://github.com/google/uuid/pull/192
|
|
* https://github.com/golang/go/issues/62026
|
|
* https://github.com/golang/go/issues/76319
|
|
(generally it's a bad idea for an API addition overall, but some good ideas were raised)
|
|
|
|
Some of these additions may deprecate/obsolete components of this package.
|
|
I'll try to keep them around but mark as deprecated as they are (if they are),
|
|
but I make no concrete promises - I hate making new major releases in Go's
|
|
[silly module architecture] even more than I do keeping old deprecated code around.
|
|
So caveat emptor.
|
|
|
|
[Microsoft's incompetence]: https://learn.microsoft.com/en-us/windows/win32/api/guiddef/ns-guiddef-guid
|
|
[§ 5.4]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.4
|
|
[§ 4.4]: https://datatracker.ietf.org/doc/html/rfc4122#section-4.4
|
|
[§ 5.9]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.9
|
|
[§ 5.10]: https://datatracker.ietf.org/doc/html/rfc9562#section-5.10
|
|
[github:google/uuid#192]: https://github.com/google/uuid/pull/192
|
|
[silly module architecture]: https://go.dev/doc/modules/major-version
|
|
*/
|
|
package uuidx
|