Menu
Why are there dashes in a .NET GUID? Are there dashes in most implementations of a GUID, or is it just a Microsoft thing?
Signed,
741ecf77-9c92-4435-8e6b-85975bd13452
453
The UUID with hyphens is called the full uuid, without hyphens is called the trimmed uuid. They are the same value whether they have the dashes or not, just make sure that it has all the dashes or none of them. UUIDs with hyphens is the standard way to do it. I've only seen it done without hyphens in Minecraft.
UUID is represented by 32 lowercase hexadecimal digits, displayed in five groups separated by hyphens, in the form 8-4-4-4-12 for a total of 36 characters (32 alphanumeric characters and four hyphens).
A GUID follows a specific structure defined in RFC 4122 and come in a few different versions and variants. All variants follow the same structure xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx where M represents the version and the most significant bits of N represent the variant.
A GUID (globally unique identifier) is a 128-bit text string that represents an identification (ID). Organizations generate GUIDs when a unique reference number is needed to identify information on a computer or network. A GUID can be used to ID hardware, software, accounts, documents and other items.
Technically, there are no "dashes" in a GUID. A GUID is a 128-bit value which is usually stored in the following manner (using C# here to represent the structure):
public struct Guid { public ulong Data1; public ushort Data2; public ushort Data3; public fixed byte Data4[8]; } The dashes are in the string representation of a GUID.
The dashes are optional and are not required in a string representation of a GUID.
That said, there are historical reasons as to where the placement of the dashes are, related to how the GUIDs were generated, but that historical semantic no longer applies.
165
In the initial version of the UUID (Universally Unique Identifier) specification, each of the data elements had a semantic meaning:
{ time_low } – { time_mid } – { time_high_and_version } – { clock_seq_and_reserved clock_seq_low } – { node_id }
These elements were designed to provide temporal (time bits), and spatial (host bits) uniqueness.
As the the mathematical probability of collisions in a keyspace of 2^1024 random bits was found to be astronomically improbable, subsequent versions of the UUID spec have phased out the time and host data for security and privacy reasons.
The only elements that retain any meaning are the version bits and the reserved bits.
Version 3 UUIDs are derived from an MD5 hash of a URI or other Distinguished Name.
Version 4 is generated with random data and is, currently, the most common implementation you'll see in the wild.
Version 5 is derived from a SHA1 hash.
Since the hyphens are specified for the ASCII formatting of UUIDs in the RFC, even though the individual sections no longer retain their original meaning, they are still required if you need interoperability.
UUIDs are also sometimes stored as a base64 or ascii85 encoded string to save space for transmission over transports that are not binary-safe, and adherence to the RFC is not required.
Ascii: 3F2504E0-4F89-11D3-9A0C-0305E82C3301 Base64: 7QDBkvCA1+B9K/U0vrQx1A Ascii85: 5:$Hj:Pf\4RLB9%kU\Lj
References:
RFC4122 (see page 3 specifically for the ABNF description of the UUID format)
Wikipedia GUID UUID
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
