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
275
It's possible to generate an identical guid over and over. However, the chances of it happening are so low that you can assume they are unique.
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.
Absolutely. Even if only one GUID is generated per second, we'll run out in a scant 9 quintillion years. That's well before the heat death of the Universe.
So the answer is "yes", it will always be the same length. As for the 4, it is a version number (according to http://en.wikipedia.org/wiki/Uuid). Every GUID that you generate with that algorithm will have a 4 in that position, but older GUIDs will have a 1, 2, or 3.
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.
144
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
32
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
