View source for Universally unique identifier

{{Short description|Label used for information in computer systems}}
{{infobox identifier
| name          = Universally Unique Identifier
| alt = Examples of Universally Unique Identifier (UUID) as used by EFI variables on Linux
| caption = Examples of Universally Unique Identifier (UUID) as used by EFI variables on Linux
| image         =Examples_of_universally_unique_identifier.png
| image_caption =
| image_alt     = 
| acronym       = UUID
| start_date    = <!-- {{Start date|YYYY|MM|DD|df=y}} -->
| organisation  = [[Open Software Foundation]] (OSF), [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]], [[Internet Engineering Task Force]] (IETF)
| digits        = 32
| check_digit   = 
| example       = {{code|f81d4fae-7dec-11d0-a765-00a0c91e6bf6}}
| website       = {{IETF RFC|9562}} (obsoleted {{IETF RFC|4122}})
}}A '''Universally Unique Identifier''' ('''UUID''') is a [[128-bit]] [[nominal number|label]] used to uniquely identify objects in computer systems. The term '''Globally Unique Identifier''' ('''GUID''') is also used, mostly in [[Microsoft]] systems.<ref name="RFC 9562">{{cite IETF|title=Universally Unique IDentifiers (UUIDs)|rfc=9562|first1=K.|last1=Davis|first2=B.|last2=Peabody|first3=P.|last3=Leach|publisher=[[Internet Engineering Task Force]]|year=2024|access-date=2024-05-09}}</ref><ref name="RFC 4122">{{cite IETF|title=A Universally Unique IDentifier (UUID) URN Namespace|rfc=4122|first1=P.|last1=Leach|first2=M.|last2=Mealling|first3=R.|last3=Salz|publisher=[[Internet Engineering Task Force]]|year=2005|access-date=2017-01-17}}</ref>

When generated according to the standard methods, UUIDs are, for practical purposes, unique. Their uniqueness does not depend on a central registration authority or coordination between the parties generating them, unlike most other numbering schemes. While the [[probability]] that a UUID will be duplicated is not zero, it is generally considered close enough to zero to be negligible.<ref>{{cite web |title=Universally Unique Identifiers (UUID) |url=http://www.h2database.com/html/advanced.html#uuid |access-date=21 March 2021 |website=[[H2 (DBMS)|H2]] |language=en-US}}</ref><ref>''ITU-T Recommendation [https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.667-201210-I!!PDF-E&type=items X.667]: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components''. Standard. October 2012.</ref>

Thus, anyone can create a UUID and use it to identify something with near certainty that the identifier does not duplicate one that has already been, or will be, created to identify something else. Information labeled with UUIDs by independent parties can therefore be later combined into a single database or transmitted on the same channel, with a negligible probability of duplication.

Adoption of UUIDs is widespread, with many computing platforms providing support for generating them and for parsing their textual representation.{{TOC limit|3}}

== History ==

In the 1980s, [[Apollo Computer]] originally used UUIDs in the [[Network Computing System]] (NCS). Later, the [[Open Software Foundation]] (OSF) used UUIDs for their [[Distributed Computing Environment]] (DCE). The design of the DCE UUIDs was partly based on the NCS UUIDs,<ref name=":0">{{cite book |last1=Zahn |first1=Lisa |url=https://archive.org/details/networkcomputing0000zahn/page/10/mode/1up |title=Network Computing Architecture |last2=Dineen |first2=Terence |last3=Leach |first3=Paul |last4=Martin |first4=Elizabeth |last5=Mishkin |first5=Nathaniel |last6=Pato |first6=Joseph |last7=Wyant |first7=Geoffrey |publisher=[[Prentice Hall]] |year=1990 |isbn=978-0-13-611674-5 |page=10 |url-access=registration}}</ref> whose design was in turn inspired by the ([[64-bit computing|64-bit]]) unique identifiers defined and used pervasively in [[Domain/OS]], an [[operating system]] designed by Apollo Computer.<ref>{{cite book |author1=Leach, P. J. |author2=Levine, P.H. |author3=Hamilton, J. A. |author4=Stumpf, B.L. |chapter=UIDs as internal names in a distributed file system |title=Proceedings of the first ACM SIGACT-SIGOPS symposium on Principles of distributed computing - PODC '82 |date=August 18–20, 1982 |pages=34–41|doi=10.1145/800220.806679 |isbn=0-89791-081-8 }}</ref> Later,{{when|date=June 2020}} the [[Microsoft Windows]] platforms adopted the DCE design as "Globally Unique IDentifiers" (GUIDs).

RFC 4122 registered a [[URN]] namespace for UUIDs and recapitulated the earlier specifications, with the same technical content.<ref name="RFC 4122" /> When in July 2005 RFC 4122 was published as a proposed [[IETF]] standard, the [[ITU]] had also standardized UUIDs, based on the previous standards and early versions of RFC 4122. On May 7, 2024, RFC 9562{{r|RFC 9562}} was published, introducing 3 new "versions" and clarifying some ambiguities.

== Standards ==

UUIDs are standardized by the Open Software Foundation (OSF) as part of the [[Distributed Computing Environment]] (DCE).<ref name="dce_spec_rpc">{{ cite web | publisher = The Open Group | year = 1997 | title = DCE 1.1: Remote Procedure Call | url = http://www.opengroup.org/onlinepubs/9629399/apdxa.htm}}</ref><ref name="dce_spec_auth">{{ cite web | publisher = The Open Group | year = 1997 | title = DCE 1.1: Authentication and Security Services | url = http://www.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01_01 }}</ref>

UUIDs are documented as part of [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]] 11578:1996 "[[Information technology]] – Open Systems Interconnection – [[Remote procedure call|Remote Procedure Call]] (RPC)" and more recently in ITU-T Rec. X.667 | [[International Organization for Standardization|ISO]]/[[International Electrotechnical Commission|IEC]] 9834-8:2014.<ref>{{Cite web|url=https://www.itu.int/rec/T-REC-X.667-201210-I/en|title=ITU-T Study Group 17 - Object Identifiers (OID) and Registration Authorities Recommendations|website=ITU.int|access-date=2023-03-28}}</ref>

The [[Internet Engineering Task Force]] (IETF) published the Standards-Track RFC 9562{{r|RFC 9562}} from the "Revise Universally Unique Identifier Definitions Working Group"<ref>{{Cite web |title=Revise Universally Unique Identifier Definitions (uuidrev) |url=https://datatracker.ietf.org/wg/uuidrev/about/ |access-date=2023-05-30}}</ref> as revision for RFC 4122.{{r|RFC 4122}} RFC 4122 is technically equivalent to ITU-T Rec. X.667 | ISO/IEC 9834-8, but is now obsolete.

== Format ==

A UUID is 128 bits in size, in which 2 to 4 bits are used to indicate the format's variant. The most common variant in use, OSF DCE, additionally defines 4 bits for its version.

The use of the remaining bits is governed by the variant/version selected.

=== Variants ===

The ''variant'' field indicates the format of the UUID (and in case of the legacy UUID also the address family used for the node field). The following variants are defined:

* The Apollo NCS variant (indicated by the one-bit pattern 0xxx<sub>2</sub>) is for backwards compatibility with the now-obsolete Apollo [[Network Computing System]] 1.5 UUID format developed around 1988. Though different in detail, the similarity with modern UUIDv1 is evident. The variant bits in the current UUID specification '''coincide''' with the high bits of the address family octet in NCS UUIDs. Though the address family could hold values in the range 0..255, only the values 0..13 were ever defined. Accordingly, the bit pattern <code>0xxx</code> avoids conflicts with historical NCS UUIDs, should any still exist in databases.<ref name=":1" /> This variant defines "families" as subtype.
* The OSF DCE variant (10xx<sub>2</sub>) are referred to as <nowiki>RFC 4122/DCE 1.1 UUIDs</nowiki>, or "Leach–Salz" UUIDs, after the authors of the original [[Internet Draft]]. This variant defines "versions" as subtype.
* The Microsoft COM/DCOM variant (110x<sub>2</sub>) is characterized in the RFC as "reserved, Microsoft Corporation backward compatibility" and was used for early GUIDs on the [[Microsoft Windows]] platform.
* The Reserved variant space is not currently used by any specification.

=== Versions of the OSF DCE variant ===

The OSF DCE variant defines eight "versions" in the standard, and each version may be more appropriate than the others in specific use cases. The version is indicated by the value of the higher [[nibble]] (higher 4 bits, or higher hexadecimal digit) of the 7th byte of the UUID. In hex, this is the character after the second dash. For example, the UUID <code>9c5b94b1-35ad-'''4'''9bb-b118-8e8fc24abf80</code> is version 4, because of the digit after the second dash is 4 in <code>...-'''4'''9bb-...</code>.

==== Versions 1 and 6 (date-time and MAC address) ====

Version 1 concatenates the 48-bit [[MAC address]] of the "node" (that is, the computer generating the UUID), with a 60-bit timestamp, being the number of 100-[[nanosecond]] intervals since midnight 15 October 1582 [[Coordinated Universal Time]] (UTC), the date on which the [[Gregorian calendar]] was first adopted by the bulk of Europe. <nowiki>RFC 4122</nowiki> states that the time value rolls over around 3400 AD,<ref name="RFC 4122" />{{rp|3|q="it is possible for values to rollover (around A.D. 3400, depending on the specific algorithm used)"}} depending on the algorithm used, which implies that the 60-bit timestamp is a signed quantity. However some software, such as the libuuid library, treats the timestamp as unsigned, putting the rollover time in 5623 AD.<ref name="e2fsprogs" /> The rollover time as defined by ITU-T Rec. X.667 is 3603 AD.<ref name="X667">{{cite web |date=October 2012 |title=Recommendation ITU-T X.667 |url=https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.667-201210-I!!PDF-E&type=items |access-date=19 December 2020 |website=[[ITU-T|www.itu.int]]}}</ref>{{rp|v|q="a UUID is&nbsp;[...] guaranteed to be different from all other UUIDs generated before 3603 A.D."}}

A 13-bit or 14-bit "uniquifying" clock sequence extends the timestamp in order to handle cases where the processor clock does not advance fast enough, or where there are multiple processors and UUID generators per node. When UUIDs are generated faster than the system clock could advance, the lower bits of the timestamp fields can be generated by incrementing it every time a UUID is being generated, to simulate a high-resolution timestamp.  With each version 1 UUID corresponding to a single point in space (the node) and time (intervals and clock sequence), the chance of two properly generated version-1 UUIDs being unintentionally the same is practically nil.  Since the time and clock sequence total 74 bits, 2<sup>74</sup> (1.8{{e|22}}, or 18 sextillion) version-1 UUIDs can be generated per node ID, at a maximal average rate of 163 billion per second per node ID.<ref name="RFC 4122" />

In contrast to other UUID versions, version-1 and -2 UUIDs based on MAC addresses from [[network card]]s rely for their uniqueness in part on an identifier issued by a central registration authority, namely the [[Organizationally unique identifier|Organizationally Unique Identifier]] (OUI) part of the MAC address, which is issued by the [[IEEE]] to manufacturers of networking equipment.<ref name="IEEE-RA">
{{cite web |title=Registration Authority |url=http://standards.ieee.org/develop/regauth/ |archive-url=https://web.archive.org/web/20110404225440/http://standards.ieee.org/develop/regauth/ |url-status=dead |archive-date=4 April 2011 |website=[[IEEE Standards Association]]}}</ref> The uniqueness of version-1 and version-2 UUIDs based on network-card MAC addresses also depends on network-card manufacturers properly assigning unique MAC addresses to their cards, which like other manufacturing processes is subject to error. Virtual machines receive a MAC address in a range that is configurable in the hypervisor.<ref>{{Cite web|url=https://superuser.com/questions/932651/mac-addresses-for-virtual-machines|title=MAC addresses for virtual machines|website=Super User}}</ref> Additionally some operating systems permit the end user to customise the MAC address, notably [[OpenWrt|OpenWRT]].<ref>{{Cite web |date=15 September 2021 |title=MAC Address Setup |url=https://openwrt.org/docs/guide-developer/mac.address |website=OpenWRT}}</ref>

Usage of the node's network card MAC address for the node ID means that a version-1 UUID can be tracked back to the computer that created it. Documents can sometimes be traced to the computers where they were created or edited through UUIDs embedded into them by [[word processing]] software. This [[privacy]] hole was used when locating the creator of the [[Melissa (computer virus)|Melissa virus]].<ref>{{cite web |last=Reiter |first=Luke |date=1999-04-02 |title=Tracking Melissa's Alter Egos |url=https://www.zdnet.com/article/tracking-melissas-alter-egos/ |access-date=2017-01-16 |publisher=[[ZDNet]]}}</ref>

RFC 9562{{r|RFC 9562}} does allow the MAC address in a version-1 (or 2) UUID to be replaced by a random 48-bit node ID, either because the node does not have a MAC address, or because it is not desirable to expose it. In that case, the RFC requires that the least significant bit of the first octet of the node ID should be set to 1.<ref name="RFC 4122" /> This corresponds to the [[multicast]] bit in MAC addresses, and setting it serves to differentiate UUIDs where the node ID is randomly generated from UUIDs based on MAC addresses from network cards, which typically have [[unicast]] MAC addresses.<ref name="RFC 4122" />

Version 6 is the same as version 1 except all timestamp bits are ordered from most significant to least significant. This allows systems to sort UUIDs in order of creation simply by sorting them lexically, whereas this is not possible with version 1.

==== Version 2 (date-time and MAC address, DCE security version) ====

RFC 9562{{r|RFC 9562}} reserves version 2 for "DCE security" UUIDs; but it does not provide any details. For this reason, many UUID implementations omit version 2. However, the specification of version-2 UUIDs is provided by the DCE 1.1 Authentication and Security Services specification.<ref name="dce_spec_auth" />

Version-2 UUIDs are similar to version 1, except that the least significant 8 bits of the clock sequence are replaced by a "local domain" number, and the least significant 32 bits of the timestamp are replaced by an integer identifier meaningful within the specified local domain. On [[POSIX]] systems, local-domain numbers 0 and 1 are for user ids ([[User identifier|UIDs]]) and group ids ([[Group identifier|GIDs]]) respectively, and other local-domain numbers are site-defined.<ref name="dce_spec_auth" /> On non-POSIX systems, all local domain numbers are site-defined.

The ability to include a 40-bit domain/identifier in the UUID comes with a tradeoff. On the one hand, 40 bits allow about 1&nbsp;trillion domain/identifier values per node ID.  On the other hand, with the clock value truncated to the 28 most significant bits, compared to 60 bits in version 1, the clock in a version 2 UUID will "tick" only once every 429.49&nbsp;seconds, a little more than 7&nbsp;minutes, as opposed to every 100&nbsp;nanoseconds for version 1.  And with a clock sequence of only 6&nbsp;bits, compared to 14 bits in version 1, only 64 unique UUIDs per node/domain/identifier can be generated per 7-minute clock tick, compared to 16,384 clock sequence values for version 1.<ref>{{cite web |last1=Kuchling |first1=A. M. |title=What's New in Python 2.5 |url=https://docs.python.org/3/whatsnew/2.5.html |access-date=23 January 2016 |website=Python.org |ref=Python2.5RelNotes}}</ref>

==== Versions 3 and 5 (namespace name-based) ====

Version-3 and version-5 UUIDs are generated by [[Cryptographic hash function|hashing]] a [[namespace]] identifier and name. Version 3 uses [[MD5]] as the hashing algorithm, and version 5 uses [[SHA-1]].<ref name="RFC 9562" />

The namespace identifier is itself a UUID. The specification provides UUIDs to represent the namespaces for [[Uniform Resource Locator|URL]]s, [[fully qualified domain name]]s, [[object identifier]]s, and [[X.500]] [[LDAP|distinguished name]]s; but any desired UUID may be used as a namespace designator.

To determine the version-3 UUID corresponding to a given namespace and name, the UUID of the namespace is transformed to a string of bytes, concatenated with the input name, then hashed with MD5, yielding 128 bits.  Then 6 or 7 bits are replaced by fixed values, the 4-bit version (e.g. 0011<sub>2</sub> for version 3), and the 2- or 3-bit UUID "variant" (e.g. 10<sub>2</sub> indicating an RFC 9562{{r|RFC 9562}} UUIDs, or 110<sub>2</sub> indicating a legacy Microsoft GUID). Since 6 or 7 bits are thus predetermined, only 121 or 122 bits contribute to the uniqueness of the UUID.

Version-5 UUIDs are similar, but SHA-1 is used instead of MD5. Since SHA-1 generates 160-bit digests, the digest is truncated to 128 bits before the version and variant bits are replaced.

Version-3 and version-5 UUIDs have the property that the same namespace and name will map to the same UUID. However, neither the namespace nor name can be determined from the UUID, even if one of them is specified, except by brute-force search. RFC 4122 recommends version 5 (SHA-1) over version 3 (MD5), and warns against use of UUIDs of either version as security credentials.<ref name="RFC 4122" />

==== Version 4 (random) ====

A version 4 UUID is randomly generated.  As in other UUIDs, 4 bits are used to indicate version 4, and 2 or 3 bits to indicate the variant (10<sub>2</sub> or 110<sub>2</sub> for variants 1 and 2 respectively). Thus, for variant 1 (that is, most UUIDs) a random version 4 UUID will have 6 predetermined variant and version bits, leaving 122 bits for the randomly generated part, for a total of 2<sup>122</sup>, or 5.3{{e|36}} (5.3&nbsp;[[Names of large numbers|undecillion]]) possible version-4 variant-1 UUIDs.  There are half as many possible version 4, variant 2 UUIDs (legacy GUIDs) because there is one less random bit available, 3 bits being consumed for the variant.

Per RFC 9562{{r|RFC 9562}}, the seventh octet's most significant 4 bits indicate which version the UUID adheres to. This means that the first hexadecimal digit in the third group always starts with a <code>4</code> in UUIDv4s. Visually, this looks like this <code>xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx</code>, where <code>M</code> is the UUID version field. The upper two or three bits of digit <code>N</code> encode the variant. Values are <code>8</code>, <code>9</code>, <code>A</code> or <code>B</code> for the 2 bit indication, values <code>C</code> or <code>D</code> for the 3 bit indication. For example, a random UUID version 4, variant 1 could be  <code>8D8AC610-566D-4EF0-9C22-186B2A5ED793</code>.<ref>{{Cite web |date=2023-11-06 |title=draft-ietf-uuidrev-rfc4122bis-14 |url=https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis#name-version-field |url-status=live |archive-url=https://archive.today/20240417032603/https://datatracker.ietf.org/doc/html/draft-ietf-uuidrev-rfc4122bis#selection-6225.0-6239.184 |archive-date=2024-04-17 |website=[[University of Washington]]}}</ref>

==== Version 7 (timestamp and random) ====
Version 7 UUIDs (UUIDv7) are designed for keys in high-load databases and distributed systems.

UUIDv7 begins with a 48 bit big-endian Unix Epoch timestamp with approximately millisecond granularity. The timestamp can be shifted by any time shift value. Directly after the timestamp follows the version nibble, that must have a value of 7. The variant bits have to be <code>10x</code>. The remaining 74 bits are random seeded counter (optional, at least 12 bits but no longer than 42 bits) and random.

Two counter rollover handling methods can be used together:

* Zero seeded most significant, leftmost guard bit of the counter.
* Increment of the timestamp ahead of the actual time and reinitialize the counter when it overflows.

In DBMS UUIDv7 generator can be shared between threads (tied to a table or to a DBMS instance) or can be thread-local (with worse monotonicity, locality and performance).

==== Version 8 (custom) ====
Version 8 only has two requirements:

* The variant bits have to be <code>10</code>, so the nibble containing the variant must be 8 (<code>0b1000</code>), 9 (<code>0b1001</code>), A (<code>0b1010</code>), or B (<code>0b1011</code>).
* The version nibble has to be the value of 8.

Those requirements tell the system that it is a version 8 UUID. The remaining 122 bits are up to the vendor to customize. The difference with version 4 is that those 122 bits are random, but the 122 bits in UUID version 8 are not, because they follow vendor specific rules.

=== Special values ===
==== Nil UUID ====

The "nil" UUID is the UUID <code>00000000-0000-0000-0000-000000000000</code>; that is, all bits set to zero.<ref name="RFC 9562" />

==== Max UUID ====

The "max" UUID, sometimes also called the "omni" UUID, is the UUID <code>FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF</code>; that is, all bits set to one.<ref name="RFC 9562" />

== Encoding ==
=== Binary representation ===

Initially, Apollo Computer designed the UUID with the following wire format:<ref name=":0"/><ref name=":1">{{Cite web|url=https://opensource.apple.com/source/CF/CF-299.35/Base.subproj/uuid.c.auto.html|title=uuid.c|website=opensource.apple.com}}</ref>

{| class="wikitable"
|+ The legacy wire format
! Name
! Offset
! Length
! Description
|-
| time_high
| {{Mono|0x00}}
| 4 octets / 32 bits
| rowspan="2" | The first 6 octets are the number of four-[[microsecond]] (μs) units of time that have passed since 1980-01-01 00:00 [[UTC]].<br>The time 2<sup>48</sup> × 4 μs after 1980 started was 2015-09-05 05:58:26.84262 UTC.<br>Thus, the last time at which UUIDs could be generated in this original format was in 2015.<ref>But a bug in Domain/OS made only the first half of the timespace usable, so problems occurred on 1997-11-02.{{cite web |year=1996|title=Apollo Date Bug|author=Jim Rees|url=https://jim.rees.org/apollo-archive/date-bug}}</ref>
|-
| time_low
| {{Mono|0x04}}
| 2 octets / 16 bits
|-
| reserved
| {{Mono|0x06}}
| 2 octets / 16 bits
|These octets are reserved for future use.
|-
| family
| {{Mono|0x08}}
| 1 octet / 8 bits
| This octet is an address family.
|-
| node
| {{Mono|0x09}}
| 7 octets / 56 bits
| These octets are a host ID in the form allowed by the specified address family.
|}

Later, the UUID was extended by combining the legacy family field with the new variant field. Because the family field only had used the values ranging from 0 to 13 in the past, it was decided that a UUID with the most significant bit set to 0 was a legacy UUID. This gives the following table for the family group:

{| class="wikitable"
|+ Family / variant field
! MSB 0
! MSB 1
! MSB 2
! Legacy family field value range
! In hex
! Description
|-
| 0
| x
| x
| 0–127 (Only 0–13 are used)
| 0x00–0x7f
| The legacy Apollo NCS UUID
|-
| 1
| 0
| x
| 128–191
| 0x80–0xbf
| OSF DCE UUID
|-
| 1
| 1
| 0
| 192–223
| 0xc0–0xdf
| Microsoft COM / DCOM UUID
|-
| 1
| 1
| 1
| 224–255
| 0xe0–0xff
| Reserved for future definition
|}

The legacy Apollo NCS UUID has the format described in the previous table. The OSF DCE UUID variant is described in RFC 9562{{r|RFC 9562}}. The Microsoft COM / DCOM UUID has its variant described in the Microsoft documentation.

==== Endianness ====

When saving UUIDs to binary format, they are sequentially encoded in [[big-endian]]. For example, <code>00112233-4455-6677-8899-aabbccddeeff</code> is encoded as the bytes <code>00 11 22 33</code> <code>44 55</code> <code>66 77</code> <code>88 99</code> <code>aa bb cc dd ee ff</code>.<ref>{{cite web |last1=Steele |first1=Nick |title=Breaking Down UUIDs |url=https://duo.com/labs/tech-notes/breaking-down-uuids}}</ref><ref>{{Cite web|url=https://www.uuidtools.com/uuid-versions-explained|title=UUID Versions Explained &#124; UUIDTools.com|website=www.uuidtools.com}}</ref>

An exception to this are Microsoft's variant 2 UUIDs ("GUID"): historically used in [[Component Object Model|COM/OLE libraries]], they use a [[little-endian]] format, but appear [[mixed-endian]] with the first three components of the UUID as [[little-endian]] and last two [[big-endian]]. Microsoft's GUID structure defines the last eight bytes as an 8-byte array, which are serialized in ascending order, which makes the byte representation appear mixed-endian.<ref>{{ cite web | title = Why does COM express GUIDs in a mix of big-endian and little-endian? Why can't it just pick a side and stick with it? | last = Chen | first = Raymond | work = The Old New Thing | date = 28 September 2022 | access-date = 31 October 2022 | url = https://devblogs.microsoft.com/oldnewthing/20220928-00/?p=107221 }}</ref> For example, <code>00112233-4455-6677-8899-aabbccddeeff</code> is encoded as the bytes <code>33 22 11 00</code> <code>55 44</code> <code>77 66</code> <code>88 99</code> <code>aa bb cc dd ee ff</code>.<ref>{{cite web |last1=Leach |first1=Paul |title=UUIDs and GUIDs |url=http://upnp.org/resources/draft-leach-uuids-guids-00.txt}}</ref><ref>{{Cite web|url=https://learn.microsoft.com/en-us/dotnet/api/system.guid.tobytearray?view=net-9.0|title=Guid.ToByteArray Method (System)|website=learn.microsoft.com}}</ref>

=== Textual representation ===

In most cases, UUIDs are represented as hexadecimal values. The most used format is the 8-4-4-4-12 format, <code>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</code>, where every <code>x</code> represents 4 bits. Other well-known formats are the 8-4-4-4-12 format with braces, <code>{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}</code>, like in Microsoft's systems, e.g. Windows, or <code>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</code>, where all hyphens are removed. In some cases, it is also possible to have <code>xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</code> with the "0x" prefix or the "h" suffix to indicate hexadecimal values. The format with hyphens was introduced with the newer variant system. Before that, the legacy Apollo format used a slightly different format: <code>34dc23469000.0d.00.00.7c.5f.00.00.00</code>. The first part is the time (time_high and time_low combined). The reserved field is skipped. The family field comes directly after the first dot, so in this case <code>0d</code> (13 in decimal) for [[Data Distribution Service|DDS (Data Distribution Service)]]. The remaining parts, each separated with a dot, are the node bytes.

The lowercase form of the hexadecimal values is the generally preferred format. Specifically in some contexts such as those defined in ITU-T Rec. X.667, lowercase is required when the text is generated, but the uppercase version must also be accepted.

A UUID can be represented as a 128 bit integer. For example, the UUID <code>'''550e8400-e29b-41d4-a716-446655440000'''</code> can also be represented as 113059749145936325402354257176981405696. Note that it is possible to have both signed and unsigned values if the first bit of the UUID is set to 1.

A UUID can be represented as a  128 bit [[binary number]]. For example, the UUID <code>'''550e8400-e29b-41d4-a716-446655440000'''</code> can also be represented as 0101010100001110<wbr>1000010000000000<wbr>1110001010011011<wbr>0100000111010100<wbr>1010011100010110<wbr>0100010001100110<wbr>0101010101000100<wbr>0000000000000000<wbr>.

RFC 9562{{r|RFC 9562}} registers the "uuid" namespace. This makes it possible to make URNs out of UUIDs, like <code>'''<nowiki>urn:uuid:550e8400-e29b-41d4-a716-446655440000</nowiki>'''</code>. The normal 8-4-4-4-12 format is used for this. It is also possible to make a OID URN out of UUIDs, like <code>'''<nowiki>urn:oid:2.25.113059749145936325402354257176981405696</nowiki>'''</code>. In that case, the unsigned decimal format is used. The "uuid" URN is recommended over the "oid" URN.

== Collisions ==

[[Hash collision|Collision]] occurs when the same UUID is generated more than once and assigned to different referents. In the case of standard version-1 and version-2 UUIDs using unique MAC addresses from network cards, collisions are unlikely to occur, with an increased possibility only when an implementation varies from the standards, either inadvertently or intentionally.

In contrast to version-1 and version-2 UUIDs generated using MAC addresses, with version-1 and -2 UUIDs which use randomly generated node ids, hash-based version-3 and version-5 UUIDs, and random version-4 UUIDs, collisions can occur even without implementation problems, albeit with a probability so small that it can normally be ignored. This probability can be computed precisely based on analysis of the [[birthday problem]].<ref>{{cite web |url=http://repositorium.sdum.uminho.pt/bitstream/1822/36065/1/1159.pdf |first1=Paulo |last1=Jesus |first2=Carlos |last2=Baquero |first3=Paulo |last3=Almaeida |title=ID Generation in Mobile Environments |website=Repositorium.Sdum.Uminho.pt }}</ref>

For example, the number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71&nbsp;quintillion, computed as follows:<ref>{{ cite journal | last = Mathis | first = Frank H. |date= June 1991 | title = A Generalized Birthday Problem | journal = SIAM Review | volume = 33 | issue = 2 | pages = 265–270 | issn = 0036-1445 | doi = 10.1137/1033051 | oclc = 37699182 | jstor = 2031144 | citeseerx = 10.1.1.5.5851 }}</ref>

{{block indent|
<math>n \approx \frac{1}{2} + \sqrt{\frac{1}{4} + \ln(2) \times 2^{123}} \approx 2.71 \times 10^{18}.</math>
}}

This number would be equivalent to generating 1&nbsp;billion UUIDs per second for about 86&nbsp;years. A file containing this many UUIDs, at 16 bytes per UUID, would be about 43.4&nbsp;[[exabyte]]s (37.7&nbsp;[[exbibyte|EiB]]).

The smallest number of version-4 UUIDs which must be generated for the probability of finding a collision to be ''p'' is approximated by the formula

{{block indent|
<math>\sqrt{2 \times 2^{122} \times \ln\frac{1}{1 - p}}.</math>
}}

Thus, the probability to find a duplicate within 103&nbsp;trillion version-4 UUIDs is one in a billion.

Collisions have occurred when manufacturers assign a default UUID to a product, such as a motherboard, and then fail to over-write the default UUID later in the manufacturing process. For example, UUID 03000200-0400-0500-0006-000700080009 occurs on many different units of [[Gigabyte Technology|Gigabyte]]-branded motherboards.<ref>{{Cite web|url=https://pocketables.com/2019/08/duplicate-uuid-universally-unique-id-more-common-than-expected.html|title=Duplicate UUID (Universally Unique ID) - more common than expected - Pocketables|date=27 August 2019|website=pocketables.com}}</ref>

== Uses ==
=== Filesystems ===

Significant uses include [[ext2]]/[[ext3]]/[[ext4]] filesystem userspace tools ([[e2fsprogs]] uses libuuid provided by [[util-linux]]), [[Logical Volume Manager (Linux)|LVM]], [[LUKS]] encrypted partitions, [[GNOME]], [[KDE]], and [[macOS]],<ref>{{Cite web|url=https://opensource.apple.com/source/Libc/Libc-391/uuid/uuidsrc/gen_uuid.c|title=Wayback Machine|website=opensource.apple.com}}</ref> most of which are derived from the original implementation by [[Theodore Ts'o]].<ref name="e2fsprogs">{{cite web|url=https://git.kernel.org/?p=fs/ext2/e2fsprogs.git;a=blob;f=lib/uuid/gen_uuid.c;hb=1bbfec624c4bbe767060a13762aa9a656536a4fd|title=ext2/e2fsprogs.git - Ext2/3/4 filesystem userspace utilities|website=Kernel.org|access-date=9 January 2017}}</ref>
The "partition label" and the "partition UUID" are both stored in the [[Superblock (file system)|superblock]]. They are both part of the file system rather than of the partition. For example, ext2–4 contain a UUID, while NTFS or FAT32 do not. The superblock is a part of the file system, thus fully contained within the partition, hence doing {{code|1=dd if=/dev/sda1 of=/dev/sdb1}} leaves both sda1 and sdb1 with the same label and UUID.

=== Partition tables ===

The [[GUID Partition Table]] (GUID) is one example that utilised GUIDs to label partition types.

=== Remoting ===

There are several flavors of GUIDs used in Microsoft's [[Component Object Model]] (COM):

* {{mono|IID}} – interface identifier; (The ones that are registered on a system are stored in the [[Windows Registry]] at {{code|[HKEY_CLASSES_ROOT\Interface]}}<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms688484(v=vs.85).aspx|title=Interface Pointers and Interfaces|website=Windows Dev Center - Desktop app technologies|publisher=[[Microsoft]]|access-date=15 December 2015|quote=You reference an interface at run time with a globally unique interface identifier ({{mono|IID}}). This {{mono|IID}}, which is a specific instance of a globally unique identifier ({{mono|GUID}}) supported by COM, allows a client to ask an object precisely whether it supports the semantics of the interface, without unnecessary overhead and without the confusion that could arise in a system from having multiple versions of the same interface with the same name.}}</ref> )
* {{mono|CLSID}} {{anchor|CLSID}} – class identifier; (Stored at {{code|[HKEY_CLASSES_ROOT\CLSID]}}). In practice it is not entirely separate from the {{mono|IID}} space, because remoting the interface can require a [[Stub (distributed computing)|proxy/stub object]] which some toolsets used to create with a {{mono|CLSID}} equal to the interface's {{mono|IID}}.
* {{mono|LIBID}} – type library identifier; (Stored at {{code|[HKEY_CLASSES_ROOT\TypeLib]}}<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms221610(v=vs.85).aspx|title=Registering a Type Library|website=[[Microsoft Developer Network]]|publisher=[[Microsoft]]|access-date=15 December 2015}}</ref>)
* {{mono|CATID}} – category identifier; (its presence on a class identifies it as belonging to certain class categories, listed at {{code|[HKEY_CLASSES_ROOT\Component Categories]}}<ref>{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms682451(v=vs.85).aspx|title=Categorizing by Component Capabilities|website=Windows Dev Center - Desktop app technologies|publisher=[[Microsoft]]|access-date=15 December 2015|quote=A listing of the CATIDs and the human-readable names is stored in a well-known location in the registry.}}</ref>)

=== Databases ===

UUIDs are commonly used as a [[unique key]] in [[database]] tables. The {{mono|NEWID}} function in [[Microsoft SQL Server]] version 4 [[Transact-SQL]] returns standard random version-4 UUIDs, while the {{mono|NEWSEQUENTIALID}} function returns 128-bit identifiers similar to UUIDs which are committed to ascend in sequence until the next system reboot.<ref>{{cite web |url=http://msdn.microsoft.com/en-us/library/ms189786.aspx |title=NEWSEQUENTIALID (Transact-SQL) |website=[[Microsoft Developer Network]] |publisher=[[Microsoft]] |date=2015-08-08 |access-date=2017-01-14}}</ref> The [[Oracle Database]] {{mono|SYS_GUID}} function does not return a standard GUID, despite the name.  Instead, it returns a 16-byte 128-bit RAW value based on a host identifier and a process or thread identifier, somewhat similar to a GUID.<ref>{{cite web |url=https://docs.oracle.com/cd/B12037_01/server.101/b10759/functions153.htm |publisher=[[Oracle Corporation|Oracle]] |title=Oracle Database SQL Reference}}</ref> [[PostgreSQL]] contains a {{mono|UUID}} datatype<ref>{{cite web |url=https://www.postgresql.org/docs/9.4/static/datatype-uuid.html |work=PostgreSQL 9.4.10 Documentation |title=Section 8.12 UUID Type |date=13 February 2020 |publisher=PostgreSQL Global Development Group}}</ref> and can generate most versions of UUIDs through the use of functions from modules.<ref>{{cite web |url=https://www.postgresql.org/docs/9.6/static/uuid-ossp.html |work=PostgreSQL: Documentation: 9.6 |title=uuid-ossp |date=12 August 2021 |publisher=PostgreSQL Global Development Group}}</ref><ref>{{cite web |url=https://www.postgresql.org/docs/9.6/static/pgcrypto.html |work=PostgreSQL: Documentation: 9.6 |title=pgcrypto |date=12 August 2021 |publisher=PostgreSQL Global Development Group}}</ref> [[MySQL]] provides a {{mono|UUID}} function, which generates standard version-1 UUIDs.<ref>{{cite book |chapter-url=http://dev.mysql.com/doc/refman/5.7/en/miscellaneous-functions.html |title=MySQL 5.7 Reference Manual |chapter=Section 13.20 Miscellaneous Functions |publisher=[[Oracle Corporation]]}}</ref>

==== Combined Time-GUID ====

The random nature of standard UUIDs of versions 3, 4, and 5, and the ordering of the fields within standard versions 1 and 2 may create problems with database [[locality of reference|locality]] or performance when UUIDs are used as [[primary key]]s. For example, in 2002 Jimmy Nilsson reported a significant improvement in performance with Microsoft SQL Server when the version-4 UUIDs being used as keys were modified to include a non-random suffix based on system time. This so-called "COMB" (combined time-GUID) approach made the UUIDs significantly more likely to be duplicated, as Nilsson acknowledged, but Nilsson only required uniqueness within the application.<ref>{{cite web |last=Nilsson |first=Jimmy |url=http://www.informit.com/articles/article.aspx?p=25862 |title=The Cost of GUIDs as Primary Keys |website=InformIT |access-date=2012-06-20|date=2002-03-08 }}</ref> By reordering and encoding version 1 and 2 UUIDs so that the timestamp comes first, insertion performance loss can be averted.<ref>{{cite web |url=https://percona.com/blog/2014/12/19/store-uuid-optimized-way/ |publisher=Percona |title=Storing UUID Values in MySQL |access-date=2021-02-10 |archive-url=https://web.archive.org/web/20201129230946/https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ |archive-date=2020-11-29| date=2014-12-19}}</ref>

COMB-like arrangements of UUID payloads were eventually standardized in RFC 9562{{r|RFC 9562}} as UUIDv6 and UUIDv7.

== See also ==

* [[Birthday attack]]
* [[Object identifier]] (OID)
* [[Uniform Resource Identifier]] (URI)
* [[Snowflake ID]]

==References==
{{Reflist}}

== External links ==

* [http://handle.itu.int/11.1002/1000/11746 Recommendation ITU-T X.667] (Free access)
* [https://www.iso.org/standard/62795.html ISO/IEC 9834-8:2014] (Paid)
* [https://developer.apple.com/library/mac/#technotes/tn2166/_index.html#//apple_ref/doc/uid/DTS10003927 Technical Note TN2166 - Secrets of the GPT] - Apple Developer
* [http://jakarta.apache.org/commons/sandbox/id/uuid.html UUID Documentation] - Apache Commons Id
* [http://msdn.microsoft.com/en-us/library/ms691424(VS.85).aspx CLSID Key] - Microsoft Docs
* [https://pubs.opengroup.org/onlinepubs/9629399/apdxa.htm Universal Unique Identifier] - The Open Group Library
* [https://www.uuidtools.com/decode UUID Decoder tool]
* [https://segment.com/blog/a-brief-history-of-the-uuid/ A Brief History of the UUID]
* [https://generateguid.online/en#uuidblog Understanding How UUIDs Are Generated]

{{Authority control}}

{{Use dmy dates|date=December 2021}}
[[Category:Unique identifiers]]
[[Category:Windows administration]]
[[Category:1996 establishments]]