UUID-Generator

• Hash-Generator
• Base64-Encoder/Decoder
• Alle Konverter

UUIDs liefern Kennungen mit extrem geringer Kollisionswahrscheinlichkeit über Systeme hinweg. Das vereinfacht Primärschlüssel in verteilten Datenbanken, Ressourcen-IDs in APIs, Sitzungs-Tokens und Dateibenennung ohne zentralen Allocator.

Vorteile von UUIDs

• Eindeutigkeit: Sehr geringe Kollisionswahrscheinlichkeit bei korrekter Erzeugung, sodass unabhängige Dienste IDs sicher vergeben können.
• Verteilte Systeme: Clients oder Dienste können IDs erstellen, ohne eine zentrale Sequenz aufzurufen.
• Datenbankschlüssel: Beliebt als Surrogat-Primärschlüssel, wenn natürliche Schlüssel unhandlich sind oder zusammenführbare Schemas wichtig sind.
• Schwerer erratbar: Zufällige v4-Werte legen keine sequenziellen Zähler offen, was gegen triviale Enumeration hilft (ersetzt keine ordentliche Authentifizierung).
• Standardskonform: RFC 4122 definiert Formate und Versionsbits, damit Tools und Sprachen interoperieren.

Dieses Tool konzentriert sich auf die beiden Versionen, die Entwickler am häufigsten nutzen. Wählen Sie die passende für Sortierung, Datenschutz und Kompatibilität.

Hier verfügbare Versionen

• UUID v4 (zufällig): Nutzt zufällige oder pseudozufällige Daten für die Nutzlastbits; empfohlener Standard für neue Designs.
• UUID v1 (zeitbasiert): Enthält einen Zeitstempel; nützlich, wenn monotones oder nach Zeit sortierbares Verhalten hilft, mit anderen Offenlegungsmerkmalen als bei rein zufälligen IDs.

Ein paar Details vermeiden Überraschungen beim Speichern, Indizieren oder Vergleichen von UUID-Zeichenketten.

Kurzreferenz

• Eine UUID hat 128 Bit und wird oft als 32 Hex-Ziffern im Muster 8-4-4-4-12 mit Bindestrichen dargestellt.
• UUID v4 bietet 122 Bit Zufälligkeit in der Nutzlast (Versions- und Variantenbits sind festgelegt).
• UUID-Zeichenketten sind breiter als Ganzzahlschlüssel; Index- und Speicherdesign sollten die Länge berücksichtigen.
• Klein- oder Großschreibung der Hex-Ziffern ist Darstellung; Vergleiche sind meist case-insensitive.
• RFC 4122 definiert weitere Versionen (z. B. v3, v5); diese Seite erzeugt nur v1 und v4.

Empfohlene Vorgehensweise

Nutzen Sie die passende Version für Ihr Bedrohungsmodell und Ihre Speicherschicht, und behandeln Sie UUIDs als Kennungen — nicht als Geheimnis allein.

• Bevorzugen Sie UUID v4 für allgemeine eindeutige IDs, sofern kein klarer Grund für v1 besteht.
• Speichern Sie UUIDs konsistent (Zeichenkette vs. binär) und indizieren Sie nach den Empfehlungen Ihrer Datenbank.
• Verlassen Sie sich nicht allein auf UUID-Zufälligkeit für sensible Ressourcen; setzen Sie immer Autorisierung durch.
• Bei sehr hohen Einfügeraten messen Sie, wie UUID-String-Schlüssel die B-Baum-Fragmentierung gegenüber sequenziellen IDs beeinflussen.
• Bei IDs in URLs kombinieren Sie Unvorhersehbarkeit mit angemessenem Zugriffsschutz auf die Daten.

Typische Einsatzszenarien

• Primärschlüssel in Datenbanken: Surrogatschlüssel, die sauber über Shards oder Offline-Clients hinweg zusammenführen.
• API-Ressourcen: Stabile, undurchsichtige Kennungen in JSON-Antworten und Hypermedia-Links.
• Sitzungs- und Korrelations-IDs: Anfragen oder Browser-Sitzungen verfolgen ohne gemeinsamen Zähler.
• Verteilte Worker: Worker erzeugen Job- oder Datei-IDs ohne Koordinator.
• Eindeutige Dateinamen: Vermeiden Kollisionen beim Hochladen oder Cachen von Nutzerinhalten.