Representations
View this section in the spec ↗128 bits, representable any way a UUID is; anything that stores UUIDs stores TNIDs unchanged. TNIDs add their own TNID string.
Example
The spec's example, name test, variant 1:
| Format | Value |
|---|---|
| TNID string | test.x8MRU0xetVa6QZeZR |
| u128 (hex) | 0xCAB19F495DC78C1F9AB98261DB92A91C |
| UUID form | cab19f49-5dc7-8c1f-9ab9-8261db92a91c |
| Bytes (big-endian) | CA B1 9F 49 5D C7 8C 1F 9A B9 82 61 DB 92 A9 1C |
Byte order
Big-endian, as for any UUID: byte 0 holds the top 8 name bits. Mixed-endian GUID APIs reorder the first 8 bytes.
UUID form
32 hex digits, grouped 8-4-4-4-12 (RFC 9562). Read either case, write lowercase. Any UUID parser reads a TNID; a TNID parser also checks the TNID rules.
Ordering
All four sort identically:
| Representation | Compare |
|---|---|
| u128 | Unsigned integer |
| Bytes | Byte by byte, first to last |
| UUID form | As strings, only if every string uses the same case |
| TNID string | Byte by byte |
TNID strings sort correctly despite variable-length names because . (ASCII 46) sorts before every name character, as the null name character 00000 does in the bits: a.… < a0.… < ab.….