Talk:Universally unique identifier

From what I can determine, Version 4 UUID's -- the random kind -- have four variants, signified by the 17th hex digit being one of "8", "9", " a", or "b" (which is how I will refer to each variant here).

What are these four different variants for? How are they used? What determines the use of (say) variant "a" rather than variant "8"?

I'm writing a program to generate these UUID's pseudorandomly, and I don't want to make some kind of ghastly error by providing the wrong type of UUID! Is there a reason why one would use one v4 variant and not another? Are some v4 variants more apprpriate for some uses, and others for other uses? The ONLY document I've yet come across that addresses this issue says (in relevant part):

"...Version-4, variant-1 UUIDs are used in the game Minecraft... Version-4, variant-2 is called a "GUID" on Microsoft systems..."

(Source: https://www.uuidtools.com/uuid-versions-explained, Retrieved: Fri., 30-Sep-2022 at 08:43:17pm -0400 UTC.)

However, this leaves unanswered qustions. First (and most obvious) is, what about variants 3 and 4 (what I call "a" and "b" above)?

Also, the phrases "are used in" and "is called a" don't tell me whether these variants are exclusively reserved for these uses, or if it is permitted to use them for other, additional, purposes as well.

The main Wikipedia article doesn't even remotely begin to even touch upon this question...

Guidance? Help? Please?

: The standard -- {{IETF RFC | 9562}} -- has all of the details.

: A properly written Version 4 UUID generator --

: such as, for example, [https://developer.mozilla.org/en-US/docs/Web/API/Crypto/randomUUID the randomUUID() function] supported by most web browsers --

: *should* be creating UUIDs of all 4 kinds (8, 9, a, or b in the high hex digit of octet 8) in approximately equal numbers.

: Version 4 UUIDs all have a few bits hard-wired in order to indicate that they *are* Version 4 UUIDs. Every other bit should come from a truly random or pseudorandom number generator.

: In a standard (RFC 9562) Version 4 UUID, those hard-wired bits are binary "0100" (hex "4") in the "4-bit version field", and binary "10" in the "2-bit variant field".

: In other words, in a Version 4 UUID, octet 6 always has the high hex digit of "4", and octet 8 always has a high hex digit of any one of the 4 hex digits you mention -- 8, 9, a, or b. Every other bit of the UUID should come from the random number generator -- including the bits that distinguish 8 from 9 from a from b.

: (The "variant-2" UUIDs in the documentation you mentioned never have 8, 9, a, or b in that hex digit -- instead, they always have C or D in that hex digit).

: (The RFC 9562 documentation has a table listing all 16 possible values of that "variant" hex digit, and what uses they are exclusively reserved for.).

: The entire point of Version-4 UUIDs and Version-7 UUIDs is that anyone, even you, can generate them for any purpose, and (if they are generated correctly according to the standard) have a mathematically strong guarantee that each and every one generated anywhere is almost certainly universally unique, without needing any sort of coordination or the costs required by such coordination. (Many systems require unique numbers. Before Version-4 UUIDs, such systems usually required manufacturers to pay a surprisingly high license fee -- for each "block" of unique numbers -- to the centralized coordinating agency).

: How can we fix this article to make this more clear to future readers?

: --DavidCary (talk) 00:19, 22 November 2024 (UTC)

The text says they are "Version 2" GUIDs yet the example of encoding shows a GUID, which is NOT a version 2 GUID. The example should be consistent (use a GUID, which shows "2" where it is expected in the MS style). 2601:152:4B84:18D0:DAC:5D38:211C:12AF (talk) 17:59, 28 November 2024 (UTC)

:126.6+2+1=9999-1111=8888 203.144.88.108 (talk) 12:59, 28 June 2025 (UTC)

Hi, the current text says "historically used in COM/OLE libraries, they use a little-endian format, but appear mixed-endian". To me, this gives the impression that the mixed-endian format is no longer in much use.

However, this mixed-endian representation appears widely used in the context of UEFI firmware, e.g., storage of EFI variables, and UUIDs appearing in the eventlog (e.g, /sys/kernel/security/tpm0/binary_bios_measurements on linux). See https://uefi.org/specs/UEFI/2.10/Apx_A_GUID_and_Time_Formats.html 2001:1BA8:1134:F200:2E0:4CFF:FE68:E578 (talk) 08:23, 20 May 2025 (UTC)