Editing Universally unique identifier (section)

=== Binary representation ===

Initially, Apollo Computer designed the UUID with the following wire format:<ref name=":0"/><ref name=":1">{{cite web |title=uuid.c |url=https://opensource.apple.com/source/CF/CF-299.35/Base.subproj/uuid.c.auto.html}}</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 |title=UUID Versions Explained |url=https://www.uuidtools.com/uuid-versions-explained}}</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 |title=Guid.ToByteArray Method |url=https://docs.microsoft.com/en-us/dotnet/api/system.guid.tobytearray?view=net-5.0}}</ref>