GUID-Versionen erklärt: v1–v7 und welche Sie wählen sollten

2026-07-09

Tags: Windows · GUID · Tutorial · QuickGUID

---

Öffnen Sie eine beliebige UUID-Bibliothek, sehen Sie uuid1(), uuid3(), uuid4(), uuid5() und inzwischen auch uuid7(). Die Spezifikation definiert acht Versionen. Welche davon brauchen Sie wirklich?

Die kurze Antwort: v4 für fast alles, v7 für Datenbank-Primärschlüssel, v5 wenn derselbe Eingabewert immer denselben GUID liefern soll. Der Rest dieses Artikels erklärt warum — mit Byte-Layouts, den echten Gründen für jede Version und einem Code-Cheatsheet pro Sprache.

Wer ganz neu bei GUIDs ist, startet am besten mit Was ist ein GUID? für die Grundlagen zu Struktur und Eindeutigkeit. Dieser Beitrag ist das technische Gegenstück und geht tiefer in jede Version.

Die GUID/UUID-Versionslandschaft

Jede Version ist ein anderes Rezept, um dieselben 128 Bits zu füllen. Die Versions-Nibble (erste Hex-Ziffer des dritten Segments) verrät, welches Rezept verwendet wurde.

Version	Erzeugungsquelle	Sortierbar	Typische Verwendung
v1	Zeit + MAC-Adresse	Ja	Altsysteme (Privatsphäre-Risiko)
v2	DCE Security	Ja	Selten, spezialisiert
v3	MD5-Namespace-Hash	Nein	Veraltet (v5 verwenden)
v4	Zufällig	Nein	Allgemeiner Standard
v5	SHA-1-Namespace-Hash	Nein	Deterministische IDs
v6	Neu geordnete v1-Zeit	Ja	Direkter v1-Ersatz
v7	Millisekunden-Zeitstempel	Ja	Datenbank-Primärschlüssel
v8	Anbieterdefiniert	Benutzerdefiniert	Spezialisiert

Die Versionen v1, v4, v5 und v7 decken 99 % des realen Einsatzes ab. Gehen wir sie nacheinander durch.

v1: Zeit und MAC-Adresse

v1 ist das ursprüngliche Rezept aus RFC 4122. Es packt drei Dinge in 128 Bits:

| time_low (32) | time_mid (16) | ver+time_hi (16) | var+clk_seq (16) | node/MAC (48) |

• 60-Bit-Zeitstempel — 100-Nanosekunden-Intervalle seit dem 15.10.1582 (Einführung des gregorianischen Kalenders). Der Zeitstempel ist über time_low, time_mid und time_hi aufgeteilt.
• 14-Bit-Clock-Sequenz — ein Zähler, der zwei GUIDs unterscheidet, die im selben Clock-Tick erzeugt wurden oder wenn die Systemuhr zurückgestellt wurde.
• 48-Bit-Node — die MAC-Adresse der Netzwerkkarte.

Das MAC-Adressen-Problem

Das Node-Feld ist ein Hardware-Fingerabdruck. Jeder veröffentlichte v1-GUID trägt die MAC-Adresse Ihrer Maschine — und anders als eine IP-Adresse ist eine MAC-Adresse dafür gedacht, global eindeutig und dauerhaft zu sein. Das ist ein echtes Privatsphäre-Leck.

Das ist nicht theoretisch. Forscher haben gezeigt, dass sich Dokumente bis zu dem Rechner zurückverfolgen lassen, der sie erzeugt hat — einfach über die in Dateimetadaten eingebetteten v1-GUIDs. Microsoft selbst hat die v1-Erzeugung aus der Office-Telemetrie entfernt, nachdem das demonstriert wurde. Moderne Betriebssysteme randomisieren aus demselben Grund die MAC-Adresse gegenüber WLAN-Netzwerken.

Fazit: v1 in neuem Code vermeiden. Es überlebt in Altsystemen, COM-Schnittstellen und Hardware-naher Tooling-Umgebung — aber es gibt keinen Grund, es heute selbst zu erzeugen.

v2: DCE Security

v2 ist die Version, der Sie im Wesentlichen niemals begegnen werden. Sie nimmt das v1-Layout (Zeitstempel + MAC) und legt eine POSIX-UID/GID darüber — die lokalen Benutzer- und Gruppenkennungen aus dem DCE-Sicherheitsmodell (Distributed Computing Environment) —, sodass der UUID neben seiner Eindeutigkeit auch Zugangskontrolle-Informationen tragen kann.

v2 existiert für DCE/RPC-Authentifizierung und ACLs in Legacy-Unternehmenssystemen. Sofern Sie keine Software pflegen, die explizit DCE Security spricht, werden Sie nie ein v2 erzeugen oder konsumieren. Es erscheint hier nur, damit die Versionsliste vollständig ist und Sie nicht rätseln müssen, was eine „2" in diesem Nibble bedeutet, falls Sie je eine entdecken.

v3: Warum es verworfen wurde

v3 ist mit v5 identisch, außer dass es MD5 statt SHA-1 verwendet. MD5 hat praktische Kollisionsangriffe — zwei verschiedene Eingaben lassen sich so craften, dass sie denselben Hash erzeugen. Das bricht v3s Determinismus-Garantie in adversarischen Szenarien.

RFC 4122 behielt v3 für Abwärtskompatibilität, aber v5 hat es abgelöst. Es gibt keinen Grund, heute v3 zu erzeugen. Wenn Sie irgendwo ein v3 sehen, behandeln Sie es als veraltet.

v4: Der zufällige Standard

v4 ist das, was Sie von praktisch jedem „GUID erzeugen"-Aufruf bekommen: [guid]::NewGuid(), Guid.NewGuid(), crypto.randomUUID(), uuid.uuid4(), NEWID(). Es füllt 122 der 128 Bits mit kryptografisch starkem Zufall (die anderen 6 Bits sind die Versions- und Varianten-Marker).

Kein Zeitstempel, keine MAC, kein Maschinenzustand — reiner Zufall. Das macht v4 sicher zur Veröffentlichung, trivial zu parallelisieren und kollisionsresistent genug für jede realistische Last. Die vollständige Kollisions-Mathematik (und warum die virale „eine Milliarde Jahre"-Behauptung das Geburtstagsparadoxon falsch versteht) findet sich im Hauptartikel.

Fazit: das ist Ihr Standard. Wählen Sie v4, es sei denn, Sie haben einen konkreten Grund für etwas anderes.

v5: Deterministische Namespace-IDs

Das ist die Version, von der die meisten Entwickler gehört, sie aber nie benutzt haben — und sie löst ein echtes, nützliches Problem.

v5 erlaubt es, aus derselben Eingabe jedes Mal denselben GUID abzuleiten. Man übergibt einen Namespace-UUID und einen Namen-String und erhält einen deterministischen Bezeichner:

import uuid

# Gleiche Eingabe → gleicher GUID, jeder Lauf, jede Maschine
dns_guid = uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com')
url_guid = uuid.uuid5(uuid.NAMESPACE_URL, 'https://prunelab.net/blog/guid-explained')

print(dns_guid)  # immer  cf14e0a3-... (derselbe Wert)
print(dns_guid == uuid.uuid5(uuid.NAMESPACE_DNS, 'example.com'))  # True

Wie es funktioniert

Intern verkettet v5 die Namespace-UUID-Bytes mit den UTF-8-Namen-Bytes, führt SHA-1 über das Ergebnis aus, nimmt die ersten 16 Bytes und stempelt anschließend die Versions- (5) und Varianten-Bits auf. Der Namespace selbst ist ein UUID — NAMESPACE_DNS, NAMESPACE_URL, NAMESPACE_OID und NAMESPACE_X500 sind vordefiniert, aber jeder UUID kann als Namespace dienen.

Wann v5 das richtige Werkzeug ist

• Reproduzierbare Test-Fixtures — IDs für Testdaten erzeugen, die über Läufe hinweg stabil bleiben, sodass ein scheiternder Test jedes Mal auf dieselbe Entität zeigt.
• Von URLs abgeleitete Bezeichner — eine URL in einen GUID verwandeln, ohne Datenbank-Lookup. Zwei Systeme, die unabhängig uuid5(NAMESPACE_URL, url) für dieselbe URL berechnen, kommen immer überein.
• Idempotentes Deduplizieren — denselben Datensatz zweimal importieren, und der GUID kollidiert mit sich selbst, sodass das Duplikat allein am Schlüssel erkannt wird.

Der zentrale Unterschied zu v4: v4 liefert pro Aufruf einen eindeutigen Wert (auch bei identischer Eingabe); v5 liefert bei identischer Eingabe einen stabilen Wert. Sie sind nicht austauschbar.

Fazit: greifen Sie zu v5, wann immer Sie einen GUID brauchen, der reproduzierbar aus einem Eingabe-String abgeleitet wird.

v6: Der v1-Fix, den Sie wahrscheinlich nicht brauchen

v6 enthält exakt dieselben Daten wie v1 — denselben Zeitstempel, dieselbe Clock-Sequenz und MAC —, reorganisiert aber die Zeitstempel-Bits so, dass der Wert sich natürlich chronologisch sortieren lässt. Bei v1 ist der Zeitstempel unglücklich aufgeteilt (low, mid, high); bei v6 wird er high-first gespeichert, sodass lexikalisches String-Sorting gleich Zeitsorting ist.

v6 wurde 2024 in RFC 9562 zusammen mit v7 standardisiert. Es existiert hauptsächlich als direkter Migrationspfad für Systeme, die schon fest am Clock-und-MAC-Modell von v1 hängen: die bestehende Zeitstempel-Logik bleibt, nur das Bit-Layout wird umgeschrieben.

Für neue Systeme ist v7 fast immer die bessere Wahl. v7 nutzt einen Millisekunden-Zeitstempel (einfacher als v1/v6s 100-ns-gregorianische Zählung), bettet keine MAC-Adresse ein und hat ein saubereres Random-Fill. v6 beantwortet „wie modernisiere ich v1, ohne mein Erzeugungsmodell zu ändern"; v7 beantwortet „was sollte ich künftig verwenden".

v7: Zeitgeordnet für Datenbanken

v7 ist der wichtigste Neuzugang seit v4. Es löst ein Problem, das v4 in Datenbanken erzeugt.

Das v4-Datenbankproblem

Wenn eine Datenbank GUIDs als Primärschlüssel verwendet, stützen diese Schlüssel einen B+-Baum-Index. B+-Bäume bleiben effizient, wenn Einfügungen grob geordnet sind — neue Werte landen am rechten Rand und füllen bestehende Pages. Zufällige v4-GUIDs streuen über den gesamten Schlüsselraum, sodass jede Einfügung eine zufällige Page trifft. Bei großen Tabellen verursacht das ständige Page-Splits, Index-Fragmentierung, Cache-Thrash und Schreib-Verstärkung. Die Lösung im SQL Server (NEWSEQUENTIALID()) ist ein proprietärer, nicht portabler Hack, der Sequenzierung leakt.

v7s Layout

| unix_ts_ms (48) | ver (4) | rand_a (12) | var (2) | rand_b (62) |

• 48-Bit-Millisekunden-Unix-Zeitstempel — führendes Feld, sodass Werte über die Zeit steigen.
• 4-Bit-Version — auf 7 gesetzt.
• 12-Bit rand_a — zufällig, optional ein monotoner Zähler zur Ordnung innerhalb derselben Millisekunde.
• 2-Bit-Variante — der Standard-RFC-9562-Marker.
• 62-Bit rand_b — zufällig.

Weil der Zeitstempel führt, sind nacheinander erzeugte v7-GUIDs natürlich geordnet: Index-Einfügungen sammeln sich am rechten Rand, Pages füllen sich sauber, und der B+-Baum verhält sich wie bei einem Auto-Increment-Integer — und ist trotzdem global eindeutig ohne zentralen Koordinator.

Wann sich v7 NICHT lohnt

• In-Memory-Stores (Redis, memcached) — kein B+-Baum, kein Fragmentierungs-Kosten. v4 ist in Ordnung.
• Kleine Tabellen — der Unterschied zwischen v4 und v7 ist unterhalb von Millionen Zeilen unsichtbar.
• Nicht-Schlüssel-Spalten — wenn der GUID nur ein gespeichertes Attribut und kein Index-Schlüssel ist, ist Ordnung irrelevant.
• GUIDs, die opak sein müssen — v7 leakt die Erzeugungs-Millisekunde, was in sicherheitssensiblen Kontexten unerwünscht sein kann.

Fazit: wenn ein GUID ein Clustered-Primary-Key auf einer echten Datenbank ist, verwenden Sie v7. Ansonsten v4.

v8: Anbieterdefiniert

v8 ist die Ausnahmetür: RFC 9562 erlaubt dem Anbieter, ein eigenes Bit-Layout zu definieren, solange die Versions-Nibble 8 lautet und die Varianten-Bits korrekt sind. Alles andere — Zeitstempel-Breite, Zufallsquelle, Encoding — liegt beim Implementierer.

v8 werden Sie nur in Systemen sehen, die aus einem bestimmten Grund ein eigenes UUID-Schema entworfen haben (etwa um eine Shard-ID oder Node-ID fürs Routing in den UUID zu backen). Wenn Sie kein solches System bauen, ist v8 irrelevant; und wenn Sie es tun, gelten die Regeln Ihres eigenen Schemas, nicht irgendetwas in diesem Artikel.

Welche Version sollten Sie wirklich verwenden?

Ein Entscheidungsleitfaden:

• „IDs für allgemeine Verwendung erzeugen?" → v4. Das ist in 90 % der Fälle die Antwort.
• „Datenbank-Primärschlüssel oder Zeit-Ordnung nötig?" → v7. Besonders bei Clustered-Indexes auf großen Tabellen.
• „Bei jeder Eingabe denselben GUID brauchen?" → v5. Deterministisches Mapping aus einem String.
• „Mit einem Altsystem, das v1 erwartet?" → v1 (Kompatibilität behalten), aber eine Migration auf v7 planen.
• „Jemand hat mir zu v3 geraten?" → Nicht tun. Stattdessen v5 verwenden (MD5 in v3 ist kaputt).
• „Ich will das Neueste." → Das ist kein Grund. v7 ist neu und löst ein echtes Problem (DB-Ordnung); v6 ist neu und meistens nur eine v1-Migrationshilfe. Nach Anwendungsfall wählen, nicht nach Aktualität.

Wenn Sie immer noch unsicher sind: nehmen Sie v4. Den Standard gibt es nicht ohne Grund.

GUIDs nach Version und Sprache erzeugen

Sprache / Werkzeug	v4 (Standard)	v5 (deterministisch)	v7 (geordnet)
PowerShell	[guid]::NewGuid()	—	—
C# / .NET	Guid.NewGuid()	—	Guid.CreateVersion7() (.NET 9+)
Python	uuid.uuid4()	uuid.uuid5(uuid.NAMESPACE_URL, 'name')	uuid.uuid7() (3.14 beta) / Lib
JavaScript	crypto.randomUUID()	—	(npm uuid v11+)
Node.js (uuid-lib)	uuid.v4()	uuid.v5('name', NAMESPACE)	uuid.v7()
SQL Server	NEWID()	—	—
PostgreSQL	gen_random_uuid()	—	(Erweiterung)

Ein paar Hinweise: native v7-Unterstützung ist Stand 2026 noch dabei, in Standardbibliotheken zu landen. Das Node.js-Paket uuid (v11+) und .NET 9 liefern es nativ; Python fügt uuid.uuid7() in 3.14 hinzu; ältere Runtimes brauchen eine Bibliothek. v5-Unterstützung ist nahezu universell, weil es reine SHA-1-Mathematik ohne Entropie-Quelle ist.

FAQ

Wird v7 v4 als Standard ablösen?

Nein. v4 bleibt der allgemeine Standard. v7 gewinnt nur, wenn der GUID ein geordneter Primärschlüssel ist — für fast alle anderen Zwecke (Session-Tokens, Request-IDs, Content-Hashes, alles Nicht-Datenbankliche) ist v4s Zufälligkeit kein Nachteil, und v7s führender Zeitstempel würde nur Timing-Information ohne Nutzen leaken.

Ist v1 noch sicher zu verwenden?

Nein. v1 bettet die MAC-Adresse Ihrer Netzwerkkarte ein — ein dauerhafter Hardware-Fingerabdruck. Microsoft selbst hat v1 aus der Office-Telemetrie entfernt, nachdem Forscher Maschinen über eingebettete GUIDs in Dokumenten zurückverfolgt hatten. Für neuen Code v1 ganz vermeiden; für Alt-v7 eine Migration auf v7 planen.

Was ist der Unterschied zwischen v3 und v5?

Beide sind deterministische Namespace-Hashes (gleiche Eingabe → gleicher GUID). v3 nutzt MD5, v5 nutzt SHA-1. MD5 hat praktische Kollisionsangriffe, deshalb gilt v3 als für Integritätszwecke kaputt und wurde durch v5 abgelöst. Es gibt keinen Grund, heute v3 zu erzeugen.

Kann ich einen v4-GUID in v7 umwandeln?

Nein. Die Version ist kein Label, das man einfach tauscht — jede Version nutzt völlig andere Erzeugungslogik. v4 hat keinen Zeitstempel zum Extrahieren, deshalb ist der einzige Weg, „einen v7 zu bekommen", einen neuen zu erzeugen. Wenn Sie eine v4-Primärschlüssel-Spalte auf v7 migrieren wollen, legen Sie tatsächlich eine neue Spalte an und schreiben sie neu.

Unterstützt .NET v7 nativ?

Ja. Guid.CreateVersion7() wurde in .NET 9 hinzugefügt (veröffentlicht November 2024). Auf .NET 8 oder früher nutzen Sie die NuGet-Pakete GenVault oder UUIDv7 oder upgraden.

QuickGUID: v4 & v7 erzeugen, jedes Format konvertieren

Für die alltägliche GUID-Arbeit ist QuickGUID ein nativer Windows-Werkzeugkasten, der den kompletten Workflow abdeckt:

• Stapelerzeugung von v4 oder v7, bis zu 1.000 auf einmal
• 10+-Format-Konvertierung: Standard, ohne Bindestriche, geschweifte Klammern, Base64, C-Byte-Array, DEFINE_GUID-Makro — alles mit Live-Vorschau
• Smarte Extraktion: Logs oder Quellcode einfügen, automatisch jeden GUID finden und konvertieren
• Live-Dekoratoren: Anführungszeichen, Präfixe/Suffixe, Groß-/Kleinschreibung — global umschalten und direkt kopieren

Komplett kostenlos, 100% offline.

Zum Schluss

Das Versionierungssystem existiert, weil verschiedene Jobs verschiedene Garantien brauchen: v4 gibt Ihnen untraceable Zufälligkeit, v5 gibt Ihnen Reproduzierbarkeit, v7 gibt Ihnen Ordnung. Standardmäßig v4, bei Datenbankschlüsseln zu v7 greifen und v5 verwenden, wenn identische Eingaben identische GUIDs liefern müssen.

Ganz neu bei GUIDs? Starten Sie mit Was ist ein GUID? für die Grundlagen zu Struktur, dem Bindestrich-Format und warum 128 Bits ausreichen, um Kollisionen in der Praxis zur Nichte zu machen.