Encoders & Utilities

Generator UUID

Generuj UUID v1, v4, v7, NIL lub MAX wsadowo. Toggle dla wielkich liter, nawiasów lub bez myślników.

Version

v4 — random v7 — time-ordered (RFC 9562) v1 — time + node NIL — all zeros MAX — all ones

Quantity Between 1 and 1000.

UPPERCASE Wrap in {braces} No dashes

When to use which version

v1 — time-based + MAC node. Good when ordering matters and you need debuggable insertion order. Leaks MAC/host info if real MAC is used; we generate a random multicast-bit node so no real hardware is exposed.
v4 — random. Default choice. Collision-resistant (2¹²² entropy), good for distributed systems where ordering doesn't matter. Bad for DB primary keys at scale (random order kills B-tree locality).
v7 — time-ordered (RFC 9562, 2024). 48-bit Unix-ms timestamp prefix → lexicographically sortable + index-friendly. Recommended for new DB primary keys. Use this if you can.
NIL — 00000000-0000-0000-0000-000000000000. Sentinel/placeholder value.
MAX — all-ones UUID (RFC 9562). Useful as "infinity" sentinel paired with NIL.

O tym narzędziu

UUID Generator emituje 128-bitowe Universally Unique Identifiers zgodne z RFC 9562 (aktualizacja 2024 oryginalnego RFC 4122). Pięć wariantów jest obsługiwanych: v1 (time + MAC, przewidywalne w czasie), v4 (losowe — najczęstsze), v7 (time-ordered losowe, nowoczesny default dla kluczy bazy), NIL (placeholder all-zero) i MAX (all-FF — przydatne jako granica "maksimum" w zapytaniach zakresowych). Wygeneruj jeden lub do 1000 naraz.

Cała losowość pochodzi z crypto.getRandomValues() — tego samego CSPRNG przeglądarki używanego przez TLS. UUID-y nigdy nie powtarzają się w praktyce: 122 bity losowości v4 dają prawdopodobieństwo kolizji tak niskie, że generowanie miliarda na sekundę przez 85 lat ma około 50% szansy na pojedynczą kolizję ("granica urodzin" dla 122 bitów). v7 redukuje losowość do 74 bitów w zamian za time-ordering, co nadal jest collision-safe na każdej realistycznej skali.

Kiedy używać tego narzędzia

Generowanie przykładowego ID bazy do testów. Szybsze niż uruchamianie generatora Twojego ORM.
Wybór właściwej wersji. v7 sortuje się po czasie używane jako primary key — znacznie lepsze dla indeksów B-tree niż v4. Używaj v4 tylko gdy aktywnie chcesz ukryć kolejność.
Seedowanie fixtures. 100 odrębnych UUID-ów jednym kliknięciem dla zestawu danych testowych.
Inspekcja formatu UUID. Zwaliduj, że string, który dostałeś, jest faktycznie poprawnym UUID-em, i dowiedz się, która to wersja.

O v7 vs v4

UUID v7 został ustandaryzowany w 2024, specyficznie by naprawić anty-database-friendly losowość v4. v7 ma timestamp (48 bitów, rozdzielczość milisekund) w wysokich bitach, więc świeżo wygenerowane UUID-y sortują się leksykalnie po czasie utworzenia. To trzyma indeks B-tree "ciasno" (nowe insertyclustrują się na jednym końcu) zamiast rozsypywać przez strony. Dla nowych aplikacji v7 jest nowym defaultem; v4 pozostaje przydatne tylko gdy specyficznie chcesz nieodgadywalności kolejności.

Najczęstsze pytania

Czym różnią się UUID v4 i v7?

v4 to 122 bity losowych danych — kolejność dwóch UUID-ów v4 jest bez znaczenia. v7 osadza 48-bitowy Unix timestamp w milisekundach w wysokich bitach, więc UUID-y v7 wygenerowane później sortują się po wcześniejszych. Dla primary keys bazy v7 jest dramatycznie przyjaźniejszy indeksom B-tree; v4 rozprasza zapisy po całym indeksie i powoduje więcej page splits.

Czy UUID-y są naprawdę unikalne?

Efektywnie tak. Dla v4, z 122 bitami losowości, musiałbyś wygenerować ~2,7 × 10^18 UUID-ów, zanim miałbyś 50% szansy na jedną kolizję. Świat generuje biliony rocznie i kolizje nie są prawdziwym problemem. v7 z 74 losowymi bitami nadal jest bezpieczne do ~1,5 × 10^11 na milisekundę. UUID NIL (00000000-...) to jeden wyjątek i jest zarezerwowany.

Dlaczego niektóre UUID-y mają nawiasy klamrowe wokół?

Konwencja Microsoftu — Windows COM i .NET często wyświetlają GUID-y jako {xxxxxxxx-xxxx-...}. Nawiasy nie są częścią wartości, tylko dekoracyjne. Większość innych ekosystemów (Linux, JSON API, JavaScript) pisze UUID-y bez nawiasów. Nasz toggle pozwala produkować oba formaty; przełączaj wedle potrzeby przy interoperacji ze stackami Windows-heavy.

Czy mogę używać ich jako primary keys bazy?

Tak — UUID-y są szeroko używane jako PK. Dla nowych tabel preferuj v7 (lub ULID, pokrewny format), by indeks pozostał kompaktowy. v4 jest technicznie okej, ale powoduje więcej write amplification na indeksach B-tree z powodu losowego rozproszenia. PostgreSQL, MySQL 8+ i SQLite wszystkie mają natywne lub near-natywne wsparcie UUID; w MySQL pre-8 przechowuj jako BINARY(16) dla kompaktowości.