Eine UUID ist ein 128-Bit-Bezeichner, geschrieben als zweiunddreißig hexadezimale Zeichen in fünf durch Bindestriche getrennten Gruppen. Erzeugt wird hier Version 4, die nahezu vollständig zufällig ist: kein Zähler, kein Zeitstempel, keine Maschinenkennung — zwei Systeme, die nie miteinander kommuniziert haben, können also je Bezeichner vergeben, ohne ein Kollisionsrisiko, das der Planung bedürfte.
Der Zufall stammt aus dem kryptografischen Generator des Browsers statt aus Math.random, und das zählt, weil Math.random nicht unvorhersehbar ist und daraus abgeleitete Bezeichner erraten werden können. Bis zu zwanzig werden auf einmal erzeugt.
Wo UUIDs helfen und wo sie kosten
-
Kollisionen sind kein praktisches Problem:
Der Raum ist groß genug, dass selbst Milliarden erzeugter Version-4-UUIDs die Wiederholungswahrscheinlichkeit verschwindend lassen. Sie müssen nicht auf Dubletten prüfen.
-
Sie sind nicht geheim:
Eine UUID identifiziert etwas, sie schützt es nicht. Ein nicht erratbarer Bezeichner ist keine Zugriffskontrolle, und alles, was allein über eine URL erreichbar ist, braucht eine echte Berechtigungsprüfung.
-
In manchen Datenbanken sind sie schlechte Primärschlüssel:
Zufällige Werte streuen Schreibvorgänge über einen Index, statt ihn hinten zu ergänzen, was ihn fragmentiert. Wo das zählt, ist eine zeitlich geordnete Variante die übliche Antwort.
-
Schreibweise und Bindestriche sind reine Darstellung:
Derselbe Bezeichner kann groß oder klein, mit oder ohne Bindestriche erscheinen. Normalisieren Sie vor dem Vergleich, sonst schlägt der Abgleich bei identischen Werten fehl.
What version 4 actually is
A UUID is a 128-bit identifier written as thirty-two hexadecimal characters in five hyphenated groups, and the [msm_tool slug="uuid-generator"] produces version 4, which is very nearly all randomness — no counter, no timestamp, no machine identifier embedded anywhere inside it. That is precisely what lets two systems that have never communicated with each other mint identifiers independently with no coordination and no meaningful risk of collision.
Collisions are not worth planning around
The space a version 4 UUID is drawn from is large enough that generating billions of them leaves the chance of a repeat vanishingly small — small enough that checking for duplicates before use is not a step any application actually needs to take.
They identify, they do not protect
A UUID makes something addressable; it does not make it secure. An identifier being difficult to guess is not the same thing as an access control, and anything reachable purely by knowing its UUID still needs a real permission check behind it — treating an unguessable URL as sufficient protection on its own is a mistake worth avoiding deliberately.
Where they cost you: database performance
Random values scatter writes across an index rather than appending to its end in order, which fragments the index over time in a way a sequential or time-ordered key does not. Where write performance genuinely matters, a time-ordered identifier variant is the usual fix, rather than abandoning UUIDs altogether.
Case and hyphenation are presentation only
The same identifier can legitimately appear in upper or lower case, with hyphens or without, and both forms represent exactly the same value. Comparing two UUIDs without normalising case and formatting first is a common way for identical values to be treated as different simply because they were written down differently.
Where the randomness actually comes from
Generation draws on the browser's cryptographic random number source rather than `Math.random`, which matters because `Math.random` is not built to be unpredictable and identifiers derived from it can, in principle, be guessed. Up to twenty identifiers are produced in a single run.