Editing Universally unique identifier (section)

==== 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>