Universally Unique Identifier

Ein Universally Unique Identifier (UUID) ist eine 128-Bit-Zahl, welche zur Identifikation von Informationen in Computersystemen verwendet wird. Der Ausdruck Globally Unique Identifier (GUID) wird ebenfalls benutzt, typischerweise im Zusammenhang mit Microsoft (z. B. Software, Registry).

Bei der Generierung nach den Standardmethoden können UUIDs für praktische Zwecke als global eindeutig angenommen werden. Obwohl die Wahrscheinlichkeit, dass ein UUID dupliziert wird, nicht null ist, ist sie so gering, dass die Wahrscheinlichkeit für eine Kollision zumeist vernachlässigbar ist. Ein Vorteil von UUIDs ist die – im Gegensatz zu den meisten anderen Nummerierungsschemata – Unabhängigkeit von einer zentralen Registrierungsstelle oder Koordinierung zwischen den Parteien.

Daher kann jeder einen UUID erstellen und ihn zur Identifizierung eines Objekts verwenden und dabei mit größtmöglicher Sicherheit davon ausgehen, dass die Kennung keine andere Kennung dupliziert, die bereits erstellt wurde oder in Zukunft zur Identifizierung eines anderen Objekts erstellt wird.

Die Verwendung von UUIDs und GUIDs ist weit verbreitet. Viele Computerplattformen bieten Unterstützung beim Generieren und Parsen ihrer Textdarstellung.

Er wurde von der Open Software Foundation (OSF) als Teil des Distributed Computing Environment (DCE) standardisiert und ist jetzt in RFC 4122 geregelt.

Ein UUID besteht aus einer 16-Byte-Zahl, die hexadezimal notiert und in fünf Gruppen unterteilt wird. In seiner Normalform sieht ein UUID beispielsweise so aus:

550e8400-e29b-11d4-a716-446655440000

Geschichte und Standardisierung

UUID sind als Teil des Standards ISO/IEC 11578:1996 “Information technology – Open Systems Interconnection – Remote Procedure Call (RPC)” und als separater Standard ISO/IEC 9834-8:2005 dokumentiert. Die IETF hat das auf UUID basierende RFC 4122 veröffentlicht.

Das originale (Version 1) Generierungsschema für UUID war, die UUID-Version mit der MAC-Adresse des Computers, der den UUID generiert, und der Anzahl der 100-Nanosekunden-Intervalle seit Beginn des Gregorianischen Kalenders aneinanderzuhängen. In der Praxis ist der eigentliche Algorithmus komplizierter. Dieses Schema wurde kritisiert, weil es sowohl die Identität des generierenden Computers als auch den Zeitpunkt der Generierung preisgibt.

Mehrere andere Algorithmen zur Generierung wurden entwickelt und flossen in den Standard ein, so ein Schema, welches nur auf Zufallszahlen basiert (Version 4 UUID), und Schemata, in denen der UUID aus einem beliebigen String (z. B. DNS-Eintrag, URL, ISO OID, „X.500 Distinguished Names“, aber auch jeder beliebigen anderen Semantik, sofern ein Basis-UUID dafür definiert wird) über MD5- (Version 3 UUID) oder SHA-1- (Version 5 UUID) Hashwerte hergeleitet wird.

Das Release 5.0 von Java stellt eine Klasse zur Verfügung, die 128 Bit breite UUID generiert. Die API-Dokumentation für die Klasse java.util.UUID verweist auf RFC 4122. Auch viele andere Sprachen stellen fertige Routinen zur Generierung von UUID bereit.

Aufbau

RFC 4122 beschreibt den Aufbau eines UUID. Die Namen der einzelnen Felder orientieren sich an der ursprünglichen UUID-Version 1 und sind bei den heute vorwiegend verwendeten zufällig generierten UUIDs nur noch von historischem Interesse.

Aufbau einer UUID nach RFC 4122

Offset	Feldname	Datentyp	Beschreibung
0	time_low	uint32_t	Zeitstempel, niederstwertige 32 Bits
4	time_mid	uint16_t	Zeitstempel, mittlere 16 Bits
6	time_hi_and_version	uint16_t	Oberste Bits des Zeitstempels in den unteren 12 Bits des Feldes, die oberen 4 Bits dienen als Versionsbezeichner
8	clock_seq_high_and_reserved	uint8_t	Oberste 6 Bits der Clocksequenz (die obersten 2 Bits des Feldes sind in der hier beschriebenen UUID-Variante stets 1 0)
9	clock_seq_low	uint8_t	Untere 8 Bits der Clocksequenz
10	node	uint48_t	Eindeutige Node-Identifikationsnummer

Das zugehörige Bitfelddiagramm sieht wie folgt aus:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          time_low                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       time_mid                |version|        time_hi        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|clk_seq_hi_res |  clk_seq_low  |         node (0-1)            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         node (2-5)                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Die obersten vier Bits im Feld time_hi_and_version geben dabei die sogenannte Version des UUID an. Strenggenommen ist dies keine Version, sondern eine Art UUID-Subtyp. Folgende 5 Versionen sind bisher definiert worden:

UUID-Versionen nach RFC 4122

Version	Beschreibung
1	ursprünglicher, zeitstempelbasierter UUID
2	DCE Security version
3	namensbasiert, MD5-gehasht
4	zufälliger oder pseudozufälliger UUID
5	namensbasiert, SHA1-gehasht

Darüber hinaus wird die Einführung von weiteren Versionsnummern diskutiert, wie in folgender Tabelle mit Stand im Jahr 2022 dargestellt.

Vorschläge zu neuen UUID-Versionen

Version	Beschreibung
6	zeitstempelbasierend wie Version 1, aber mit anderer Anordnung der Datenfelder
7	zeitstempelbasierend auf der Unixzeit mit zufälliger oder pseudozufälliger Komponente
8	für experimentelle oder herstellerspezifische Anwendungen

Zeitstempelbasierte UUIDs

Der Zeitstempel ist ein 60-Bit-Wert, der die seit dem 15. Oktober 1582 (Einführung des heutigen Gregorianischen Kalenders) vergangenen 100-ns-Intervalle zählt. Um die Zeitstempel eindeutig zu halten, falls die Systemzeit einmal zurückgestellt werden muss, gibt es ein Feld Clock sequence, welches in diesem Fall entweder um 1 erhöht wird oder auf einen neuen (pseudo)zufälligen Wert gesetzt werden soll. Die Node-ID soll die MAC-Adresse einer der im System verbauten Netzwerkkarten sein oder ein pseudozufälliger Wert, falls das System keine MAC-Adresse besitzt.

(Pseudo)zufällig generierte UUIDs (Version 4)

Hierbei werden sämtliche Bits, die nicht vom UUID-Format auf feste Werte gesetzt werden, durch (pseudo-)zufällige Werte besetzt.

Obwohl die Eindeutigkeit für einen so generierten UUID nicht garantiert ist, ist die Gesamtzahl der zufällig generierbaren UUIDs mit 2¹²² ≈ 5,3169 × 10³⁶ so groß, dass die Wahrscheinlichkeit der Erzeugung zweier gleicher UUIDs sehr klein ist, sofern die verwendeten Zufallszahlenalgorithmen gleichverteilte Zufallszahlen liefern. Daher können UUIDs beliebig ohne zentrales Kontrollorgan erzeugt und zur Kennzeichnung eingesetzt werden, ohne relevante Gefahr zu laufen, dass derselbe UUID für etwas anderes verwendet wird. Mit UUID markierte Informationen können somit später in einer einzigen Datenbank zusammengeführt werden, ohne Bezeichnerkonflikte auflösen zu müssen.

Namensbasierte UUIDs (Version 3 und 5)

Hierbei wird ausgehend von einem nicht näher bestimmten Namen ein UUID generiert. Namen sind innerhalb eines zugewiesenen Namensraums eindeutige Bezeichner für ein Objekt, eine Ressource oder Ähnliches. Ausgehend von einem UUID für den Namensraum wird aus dem Namen ein UUID generiert, indem eine Bytesequenz aus der Namensraum-UUID und dem Namen selbst gebildet wird und diese Bytesequenz dann mit MD5 oder SHA1 gehasht wird. Der Hash wird dann auf definierte Weise auf die verfügbaren UUID-Bits verteilt.

RFC 4122 enthält beispielhafte Namensraum-UUIDs für die Namensräume DNS, URL, ISO OID und „X.500 Distinguished Names“.

Soll beispielsweise aus dem DNS-Namen www.example.org ein UUID-Version 5 generiert werden, so ist wie folgt vorzugehen:

1. Namespace-UUID für „DNS“-Namen ist 6ba7b810-9dad-11d1-80b4-00c04fd430c8.
2. An diese Bytefolge wird die Bytefolge für den Namen www.example.org angehängt (Bytes vom Namespace-UUID in fett):
   0x6b 0xa7 0xb8 0x10 0x9d 0xad 0x11 0xd1 0x80 0xb4 0x00 0xc0 0x4f 0xd4 0x30 0xc8 0x77 0x77 0x77 0x2e 0x65 0x78 0x61 0x6d 0x70 0x6c 0x65 0x2e 0x6f 0x72 0x67.
3. Diese Bytesequenz ist mit SHA1 zu hashen. Das Ergebnis ist folgender SHA1-Hash: 74738ff55367e9589aee98fffdcd187694028007
4. Die Bits des SHA1-Hashes sind auf die verfügbaren Bits der UUID-Version 5 aufzuteilen.
5. Generierter UUID: 74738ff5-5367-5958-9aee-98fffdcd1876. (Die fett markierten Stellen enthalten feste Bits aus UUID-Variante und -Version.)

Zeitstempelbasierte UUIDs (Version 6)

UUIDv6 zielt darauf ab, die Implementierung der UUID Erstellung zu vereinfachen, indem das Bitlayouts von UUIDv1 wiederverwendet wird, jedoch mit Änderungen in der Bitreihenfolge für den Zeitstempel.

1. Der Zeitstempel zählt in 100 Nanosekunden-Intervallen ab dem 15. Oktober 1582 um 00:00:00.00 UTC und wird auf die Felder time_high, time_mid, und t time_low aufgeteilt.
2. Das Feld ver wird immer auf die Versionsnummer (6 bzw. 0110_b) gesetzt.
3. Das Feld var wird gesetzt auf 10_b gesetzt.
4. Das Feld clock_seq, 14 Bits, enthält die Clocksequenz.
5. Die node-Felder können – je nach Implementierung – entweder Zufallswerte enthalten, oder die MAC-Adresse des erstellenden Computers.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           time_high                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           time_mid            |  ver  |       time_low        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|         clock_seq         |             node              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              node                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Zeitstempel + Zufallszahl basierte UUIDs (Version 7)

UUIDs der Version 7 bestehen aus

1. unixts: einem 36 Bit UNIX-Zeitstempel (Big-Endian codiert)
2. subsec_a12 Bits für Sekundenbruchteile
3. ver: 4 Bit Versionsnummer (immer auf dem Wert 7 bzw. 0111_b gesetzt)
4. subsec_b: 12 Bits für Sekundenbruchteile
5. var: 2 Bits für die UUID Variante (immer 10_b)
6. subsec_seq_node: 62 Zufallsbits

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            unixts                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|unixts |       subsec_a        |  ver  |       subsec_b        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|                   subsec_seq_node                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       subsec_seq_node                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Durch den Zeitstempel wird eine Sortierung in Datenbanken ermöglicht, während durch die Zufallsbits Kollisionen vermieden werden.

Anwendungsspezifische UUIDs (Version 8)

Eine UUIDv8 besitzt im Feld ver den Wert 8 bzw. 1000_b und können verwendet werden, wenn andere UUID Versionen nach [RFC4122] für eine bestimmte Anwendung nicht geeignet sind. Zudem ist ein 2 Bit großes variant Feld definiert, um verschiedene UUID-Implementierungen innerhalb einer Anwendung unterscheiden zu können.

Es wird empfohlen, dass eine UUIDv8 aus timestamp (Zeitstempel der Erstellung), clock sequence (Zählwert, der sich erhöht, wenn mehrere UUIDs für denselben Zeitstempel erstellt werden), und node Felder (Zufallswerte, MAC-Adresse, Hash-Code etc.) bestehen. Diese Felder können hierbei eine beliebige Länge aufweisen.

Das folgende Schema zeigt auf, wie eine UUIDv8 implementiert sein kann:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          timestamp_32                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           timestamp_48        |  ver  |      time_or_seq      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|var|  seq_or_node  |          node                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              node                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Globally Unique Identifier

Ein Globally Unique Identifier ist eine Zahl mit 128 Bit (16 Bytes), die in verteilten Computersystemen zum Einsatz kommt. GUID stellt eine Implementierung des Universally-Unique-Identifier-Standards (UUID) dar.

GUIDs werden üblicherweise im 8-4-4-4-12 Format XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX dargestellt, wobei jedes X für ein Zeichen aus dem Hexadezimalsystem steht und damit eine Ziffer 0–9 oder ein Buchstabe A–F sein kann, z. B. 936DA01F-9ABD-4D9D-80C7-02AF85C822A8 (32 Buchstaben/Ziffern, mit Bindestrichen 36 Zeichen).

Die vier höchstwertigen Bits des dritten Blocks (von links aus gezählt) geben die Version der GUID an, aus der man auf die Art des verwendeten Algorithmus zur Erzeugung der GUID schließen kann. Die bis zu drei höchstwertigen Bits des vierten Blocks identifizieren die verwendete Variante. Im Beispiel ist die Version an der 4 erkennbar und die Variante an der 8 in 936DA01F-9ABD-4D9D-80C7-02AF85C822A8. Dieselbe Variante wie im Beispiel könnte statt durch eine 8 auch durch eine 9, ein A oder B gekennzeichnet sein, da für diese Variante nur die ersten beiden Bit zählen.

Eine denkbare Möglichkeit, einen eindeutigen Bezeichner zu erhalten, wäre die Zuteilung durch eine zentrale Registraturstelle. Für Computer-Netzwerkkarten gibt es bereits eine solche zentrale Registraturstelle für die zugrunde liegenden MAC-Adressen. Geht man davon aus, dass ein Computer zu einem Zeitpunkt nur einen Datensatz neu anlegen kann, so lässt sich aus der MAC-Adresse des anlegenden Computers und dem Zeitstempel eine global eindeutige Kennung des Datensatzes ermitteln. GUIDs der Version 1 basieren auf der MAC-Adresse und der aktuellen Uhrzeit des berechnenden Systems. Die Verwendung der MAC-Adresse ist umstritten, da hierdurch sichtbar wird, ob ein bestimmter Host der Urheber einer GUID ist. Dies kann die Privatsphäre der GUID-Erzeuger beeinträchtigen.

In der aktuellen Version 4 wird die MAC-Adresse nicht mehr zur Erzeugung von GUIDs herangezogen. Schlüsse auf den Urheber sind somit kaum noch möglich. Der überwiegende Teil einer GUID ist nun eine pseudozufällige Zahl, die jedoch nicht kryptographisch sicher ist.

Microsoft verwendet in seinem Component Object Model ebenfalls UUIDs, dort auch GUID genannt. Allerdings entsprechen diese IDs zum Teil einer eigenen Spezifikation. Die hier beschriebenen UUIDs sind an den obersten beiden Bits des Feldes clock_seq_high_and_reserved erkennbar. Sie haben stets den Wert 10. In der Hexadezimaldarstellung ist daher die erste Hexadezimalziffer der vierten Zahl stets zwischen 8_hex und B_hex, z. B. 5945c961-e74d-478f-8afe-da53cf4189e3. Die von Microsoft verwendeten historischen UUIDs haben in den obersten drei Bits dieses Feldes den Wert 110, in der Hexadezimaldarstellung ist daher die erste Hexziffer der vierten Zahl entweder C_hex oder D_hex. Beispiel: Der GUID des IUnknown-Interfaces im COM besitzt den UUID 00000000-0000-0000-C000-000000000046.

In den Windows-Betriebssystemen von Microsoft werden GUIDs an vielen Stellen verwendet, um beispielsweise Office-Dokumente, COM-Schnittstellen oder Active-X-Steuerelemente eindeutig zu identifizieren. Eine andere Anwendung ist die Identifikation von Datenträgern und Partitionstypen in der GUID Partition Table.

Squids

Squids, früher als HashID bezeichnet, ist eine Codierung von Zahlen, welche aus dem Zeichensatz [A-Za-z0-9]+ bestehen und für die Verwendung in URIs (z. B. URLs) geeignet sind.

Die UUID 06637133-2230-472e-80fa-ba1c9661d0a7 wird z. B. als 5fQCUZjbo6srKIdYLlB5KzhkX3kkHIFM06YNrfOh9D repräsentiert.

Da die Darstellung einer UUID als Squids ebenfalls relativ groß ausfällt, wird in Anwendungen, welche Objekte als UUID referenzieren, zumeist eine Tabelle hinterlegt, welche eine Zuordnung einer eindeutigen Zahl zu einer UUID ermöglicht. Diese Zahl wird als Squid codiert in der URI übermittelt.

Die Zuordnungstabelle kann z. B. wie folgt aussehen:

UUID	Id
06637133-2230-472e-80fa-ba1c9661d0a7	07454566h

Der Wert 07454566h (hier im Hexadezimalsystem dargestellt) wird als das Squid jkwuEpN8ujl codiert und kann in der URI verwendet werden (https://example.org/jkwuEpN8ujl), um das Datenbank-Objekt mit der UUID 06637133-2230-472e-80fa-ba1c9661d0a7 zu referenzieren.

Kollisionen

Kollisionen entstehen, wenn derselbe UUID mehr als einmal generiert und verschiedenen Referenzobjekten zugewiesen wird. Bei Version 1 und 2 kann eine Kollision nur entstehen, wenn von der Standardimplementation abgewichen wird, entweder absichtlich oder unabsichtlich. Bei den Hash-basierten Versionen 3 und 5 sowie der pseudo-zufälligen Version 4 können Kollisionen auch ohne Abweichungen in der Implementierung entstehen. Jedoch ist die Wahrscheinlichkeit dafür so gering, dass sie normalerweise ignoriert werden kann. Die Wahrscheinlichkeit hierfür kann analog zum Geburtstagsproblem genau berechnet werden.

Zum Beispiel beträgt die Anzahl von Version-4 UUIDs, die berechnet werden müssen, um eine 50 %-Wahrscheinlichkeit von mindestens einer Kollision zu haben, 2,71 Trillionen.: $n\approx {\frac {1}{2}}+{\sqrt {{\frac {1}{4}}+2\times \ln(2)\times 2^{122}}}\approx 2{,}71\times 10^{18}.$

Die kleinste Anzahl von Version-4 UUIDs, die für die Wahrscheinlichkeit, eine Kollision zu finden, erzeugt werden müssen, wird durch diese Formel approximiert:

$n\approx {\sqrt {2\times 2^{122}\times \ln {\frac {1}{1-p}}}}.$

Daher beträgt die Wahrscheinlichkeit für ein Duplikat eins aus einer Milliarde bei 103 Billionen Version-4 UUIDs.

Die Anzahl generierbarer Version-4-UUIDs beträgt 4.294.967.296 * 65.536 * 4.096 * 4 * 4.096 * 281.474.976.710.656 = 5.316.911.983.139.663.491.615.228.241.121.378.304 Stück. Bei 1 mm je UUID ergibt sich eine Distanz von 561.998.040.061.409.650 Lichtjahren oder 3.406.048.727.644 Milchstraßen (~165.000 Lichtjahre) oder 40.730.000 Universum-Durchmessern (~13.800.000.000 Lichtjahre).

Implementierungen

Beispiele für Implementierung des UUID-Standards in Betriebssystemen sind:

• In der Windows API die GUID-Struktur
• Die Linux-Datei /proc/sys/kernel/random/uuid
• Unter FreeBSD implementiert als uuid(3)

Zudem gibt es Implementierungen für UUIDs in den Standardbibliotheken der meisten Programmiersprachen. Beispiele:

• Die Java-Klasse java.util.UUID
• Die Qt-Klasse QUuid
• In .NET die Klasse System.Guid
  • System.Guid implementiert UUIDv4. Ab .NET 9 wird auch UUIDv7 unterstützt. Für andere UUID-Versionen existieren Open-Source-Implementierungen.
• In Rust mittels uuid::Uuid (Unterstützt UUIDs v1 bis v8)
• In Python in Lib/uuid.py

Weblinks

• Syntax and semantics of the DCE variant of Universal Unique Identifiers (UUIDs) (englisch)
• Paul J. Leach, Michael Mealling, Rich Salz: RFC: 4122 – A Universally Unique IDentifier (UUID) URN Namespace. Juli 2015 (englisch).
• K. Davis, B. Peabody, P. Leach: RFC: 9562 – Universally Unique IDentifiers (UUIDs). Mai 2024 (englisch).
• ITU-T Recommendation X.667 (08/2008) (englisch)
• UUID Decoder uuidtools.com
• UUID Generator generateuuid.online