Wählen Sie die Anzahl der UUIDs sowie Groß- oder Kleinschreibung. Nach dem Absenden erzeugt der Server die Werte, die Sie als Liste in Ihre Testdaten übernehmen können.
Wählen Sie die Anzahl der Bezeichner (1 bis 100) und ob die Buchstaben klein- oder großgeschrieben werden; das Formular erzeugt sie auf dem Server und liefert die Liste zurück, einen Wert pro Zeile. Jeder Wert ist eine UUID der Version 4 mit 128 Bit im kanonischen Format 8-4-4-4-12 — fertig zum Einfügen in Fixtures, Seed-Daten oder Datenbankschlüssel.
Version 4 besteht aus Zufallsbits: Sie enthält weder Zeitstempel noch MAC-Adresse oder Namenshash, verrät also weder Rechner noch Erstellungszeitpunkt. Das macht sie zu einem undurchsichtigen Bezeichner — und ebenso ungeeignet, um Datensätze nach Erstellungszeit zu sortieren.
Eine UUID sind 128 Bit, geschrieben als 32 Hexadezimalzeichen in fünf durch Bindestriche getrennten Gruppen. Bei Version 4 sind 122 dieser Bits zufällig: Das Nibble am Anfang der dritten Gruppe ist auf 4 festgelegt, damit der Wert als Version 4 erkennbar ist, und die beiden höchstwertigen Bits der vierten Gruppe stehen auf 10, um die RFC-4122-Variante einzuhalten.
Diese sechs festen Bits sind der Grund, warum eine echte v4 nicht einfach 32 zufällige Hexzeichen sind: Strikte Prüfer und Bibliotheken, die die Version auswerten, weisen Werte zurück, die per Hash oder Zähler ohne diese Bits entstanden sind.
Mit 122 Zufallsbits gibt es rund 5,3 × 10^36 mögliche Werte; die Wahrscheinlichkeit einer Wiederholung ist für realistische Datenmengen vernachlässigbar. Die Seite prüft zusätzlich die Werte eines Stapels und erzeugt Duplikate neu, sodass ein Stapel mit 100 UUIDs garantiert keine Doppel enthält.
Die einzige Kollision, die in der Praxis zählt, entsteht in Ihren eigenen Daten: Wenn Sie Zeichenketten je nach Sortierung Ihrer Datenbank mit unterschiedlicher Groß-/Kleinschreibung vergleichen, können zwei Zeilen für denselben Wert entstehen. Speichern Sie die UUID in einer einheitlichen Form (etwa Kleinbuchstaben) oder in einer Binärspalte.
Eine v4 ist ein guter Primärschlüssel, wenn die Reihenfolge keine Rolle spielt: 16 Byte Zufall, die niemand errät. Wenn Ihre Datenbank unter der geringen Indexlokalität leidet (Einfügungen verteilen sich über den ganzen Baum), sind UUID v7 oder ULID die bessere Wahl — sie bringen einen sortierbaren Zeitstempel mit. Beim Speichern ist CHAR(36) lesbar, BINARY(16) spart Platz.
Verwenden Sie den Wert nicht als Geheimnis: Er entsteht auf dem Server und geht zurück an die Seite, behandeln Sie ihn also wie einen öffentlichen Bezeichner. Für Sitzungstoken oder Schlüssel erzeugen Sie das Geheimnis im eigenen Backend mit einem kryptografischen Generator und speichern nur einen Hash.
Sie ist zufällig: Version 4 kodiert weder Zeitstempel noch MAC-Adresse oder Namen, anders als Version 1. Sie enthält 122 Zufallsbits und sechs feste Bits für Version und Variante.
Ja. RFC 4122 behandelt UUIDs ohne Unterscheidung der Schreibweise: 0BC4… und 0bc4… sind derselbe Wert. Legen Sie für Datenbank und Vergleiche eine Form fest — besonders, wenn die Spalte binär sortiert wird.
1 bis 100 pro Absenden. Manipulierte Formularwerte korrigiert der Server: 0, negative Zahlen oder nicht numerischer Text werden zu 1, alles über 100 wird auf 100 begrenzt.
Jede Anfrage erzeugt die Liste auf dem Server, auch der erste Aufruf, der standardmäßig eine UUID zeigt. Es gibt keinen Cache und keine vorab erzeugten Werte: Ein Neuladen liefert andere Bezeichner.
Ja, das ist ein üblicher Einsatz: Sie wiederholen sich nicht und verraten nichts über Ihre Infrastruktur. Wenn die Einfügereihenfolge im Index wichtig ist, nehmen Sie UUID v7 oder ULID; wenn Platz zählt, speichern Sie die 16 Byte als BINARY(16) statt als 36-Zeichen-String.
Dafür ist das Werkzeug nicht gedacht. Der Wert entsteht auf dem Server und steht auf der Seite — behandeln Sie ihn als öffentlich und nutzen Sie ihn als Bezeichner. Für Token und Schlüssel erzeugen Sie den Zufall im eigenen Backend und speichern nur einen Hash.