Generator UUID v4
Generuje kryptograficznie bezpieczne losowe UUID v4
…
Formatuj
UUID v4 jest najszerzej stosowaną wersją UUID we współczesnym oprogramowaniu. W odróżnieniu od swoich odpowiedników, które wywodzą bity ze znacznika czasu lub skrótu przestrzeni nazw, UUID v4 jest zbudowany całkowicie z losowych danych — co czyni go najprostszym i najbardziej przenośnym wyborem zawsze, gdy potrzebujesz unikalnego identyfikatora, który nie zawiera żadnych metadanych o swoim pochodzeniu.
Ten generator używa crypto.randomUUID(), natywnego API przeglądarki i Node.js, które pobiera entropię z kryptograficznie bezpiecznego generatora liczb losowych systemu operacyjnego — tego samego źródła, które jest używane do materiału klucza TLS.
Czym jest UUID v4?
Universally Unique Identifier (UUID) to 128-bitowa etykieta standaryzowana w RFC 4122. Jest zazwyczaj reprezentowana jako 32 cyfry szesnastkowe pogrupowane myślnikami w wzorzec 8-4-4-4-12:
W UUID v4 122 ze 128 bitów jest losowe. Pozostałe 6 bitów to pola stałe wymagane przez specyfikację: 4 bity kodują wersję (0100 = 4), a 2 bity kodują wariant RFC 4122 (10). Te stałe bity są powodem, dla którego trzecia grupa zawsze zaczyna się od 4, a czwarta zawsze zaczyna się od 8, 9, a lub b.
Anatomia UUID v4
Analiza 550e8400-e29b-41d4-a716-446655440000:
| Segment | Bity | Znaczenie |
|---|---|---|
| 550e8400 | 32 losowe | time_low (nazwa historyczna — w pełni losowe w v4) |
| e29b | 16 losowych | time_mid (nazwa historyczna — w pełni losowe w v4) |
| 41d4 | 4 stałe + 12 losowych | Nibble wersji 4 (binarnie 0100) + 12 losowych bitów |
| a716 | 2 stałe + 14 losowych | Bity wariantu 10 (MSB pierwszego bajtu) + 14 losowych bitów |
| 446655440000 | 48 losowych | węzeł (w pełni losowy w v4) |
8, 9, a lub b — ponieważ dwa wysokie bity tego bajtu są ustalone na 10 (znacznik wariantu RFC 4122), pozostawiając pozostałe dwa bity do swobodnej zmiany.UUID v4 a inne wersje
RFC 4122 definiuje pięć wersji UUID. Każda rozwiązuje inny problem:
Łączy 60-bitowy znacznik czasu (interwały 100-nanosekundowe od października 1582) z adresem MAC hosta. Monotonicznie rosnący na danej maszynie.
Use when: potrzebujesz identyfikatorów posortowanych według czasu i nie przeszkadza ci ujawnianie tożsamości serwera i czasu generowania.
Deterministyczny: ta sama przestrzeń nazw + nazwa zawsze produkuje ten sam UUID. Używa skrótu MD5.
Use when: potrzebujesz odtwarzalnych identyfikatorów ze znanych przestrzeni nazw (np. nazwy DNS). Preferuj v5 nad v3.
122 bity kryptograficznie bezpiecznej losowości. Bez znacznika czasu, bez MAC, bez przestrzeni nazw. Najczęstszy wybór ogólnego zastosowania.
Use when: potrzebujesz unikalnych identyfikatorów bez znaczenia strukturalnego i maksymalną prywatność.
Jak v3, ale używa SHA-1. Nadal deterministyczny z przestrzeni nazw + nazwy.
Use when: potrzebujesz odtwarzalnych, adresowanych treścią identyfikatorów (np. stabilne identyfikatory dla zasobów identyfikowanych przez URL).
Nowszy (RFC 9562, 2024). Koduje uniksowy znacznik czasu w milisekundach w wysokich bitach, a następnie losowe bity. Sortowalny i przyjazny dla baz danych.
Use when: potrzebujesz identyfikatorów przyjaznych dla indeksów baz danych z naturalnym porządkiem czasu (preferuj nad v1 w nowych projektach).
Kiedy używać UUID v4
UUID v4 jest właściwym narzędziem w zdecydowanej większości sytuacji, gdy po prostu potrzebujesz "unikalnego identyfikatora" bez dodatkowych ograniczeń:
Identyfikatory użytkowników i kont
Nieprzezroczyste identyfikatory użytkowników, które nie ujawniają nic o czasie tworzenia konta ani tożsamości serwera. Nie mogą być wyliczone ani odgadnięte.
Klucze główne bazy danych
Działa z dowolnym silnikiem bazy danych. UUID v4 można bezpiecznie generować po stronie klienta i łączyć z rozproszonych źródeł bez koordynacji — nie jest wymagana tabela sekwencji ani centralna usługa identyfikatorów.
Identyfikatory sesji i tokenów
122 bity losowości sprawiają, że brutalne odgadnięcie jest obliczeniowo niewykonalne — porównywalne pod względem siły z 122-bitowym losowym tokenem.
Nazwy plików i obiektów
Bezpieczne dla deduplikacji nazwy plików dla przesyłanych plików, kluczy obiektów S3 lub wpisów pamięci podręcznej. Brak ryzyka, że dwaj klienci zapiszą pod tym samym kluczem.
Klucze idempotentności
Wygeneruj UUID na kliencie przed przesłaniem żądania. Serwer może bezpiecznie deduplikować ponowione żądania bez wspólnego licznika.
Identyfikatory korelacji i śledzenia
Dołącz UUID do każdego wiersza logu i zakresu śledzenia rozproszonego. Nie jest potrzebna koordynacja między usługami ani maszynami.
Prawdopodobieństwo kolizji
Przy 122 losowych bitach przestrzeń UUID v4 zawiera 2122 ≈ 5,3 × 1036 możliwych wartości. Prawdopodobieństwo kolizji wynika z problemu urodzin:
Powszechnie cytowany punkt odniesienia: aby mieć 50% szansę na pojedynczą kolizję, należałoby wygenerować około 2,71 × 1018 UUID. Przy tempie miliarda UUID na sekundę zajęłoby to około 85 lat ciągłego generowania. Dla każdej aplikacji z życia wziętej kolizje nie są praktycznym problemem.
Przykłady kodu
JavaScript — przeglądarka i Node.js 14.17+
Metoda crypto.randomUUID() jest dostępna natywnie we wszystkich nowoczesnych przeglądarkach (Chrome 92+, Firefox 95+, Safari 15.4+) oraz w Node.js 14.17+. Nie wymagana instalacja pakietu.
// Browser or Node.js 14.17+
const id = crypto.randomUUID()
// → "110e8400-e29b-41d4-a716-446655440000"
// Generate multiple
const ids = Array.from({ length: 5 }, () => crypto.randomUUID())Node.js — starsze wersje (pakiet uuid)
const { v4: uuidv4 } = require('uuid')
const id = uuidv4()
// → "110e8400-e29b-41d4-a716-446655440000"Python
import uuid # Generate a UUID v4 id = str(uuid.uuid4()) # → '110e8400-e29b-41d4-a716-446655440000' # The uuid module uses os.urandom() — cryptographically secure print(uuid.uuid4().hex) # without hyphens # → '110e8400e29b41d4a716446655440000'
Go
import "github.com/google/uuid" id := uuid.New().String() // → "110e8400-e29b-41d4-a716-446655440000" // Or using the standard library (Go 1.20+ with math/rand/v2 is NOT cryptographic) // Always prefer github.com/google/uuid for production use
Rust
# Cargo.toml
[dependencies]
uuid = { version = "1", features = ["v4"] }use uuid::Uuid; let id = Uuid::new_v4().to_string(); // → "110e8400-e29b-41d4-a716-446655440000"
Często zadawane pytania
Czy UUID v4 jest kryptograficznie bezpieczny?
UUID v4 sam w sobie nie jest prymitywem bezpieczeństwa — jest formatem identyfikatora. Jednak gdy jest generowany za pomocą crypto.randomUUID() (przeglądarka lub Node.js) lub równoważnych API na poziomie systemu operacyjnego, podstawowa entropia jest kryptograficznie bezpieczna. Oznacza to, że wartości UUID v4 nadają się do użycia jako tokeny sesji lub klucze idempotentności, gdzie nieprzewidywalność ma znaczenie. Nie używaj generatorów UUID opartych na Math.random() w kontekstach wrażliwych na bezpieczeństwo — używaj tylko API, które wyraźnie czerpią z CSPRNG systemu operacyjnego.
Czy dwa UUID v4 mogą być równe?
Teoretycznie tak, ale praktycznie nie. Prawdopodobieństwo wygenerowania duplikatu w jakimkolwiek realistycznym zbiorze danych (miliardy identyfikatorów) jest astronomicznie małe — znacznie mniej prawdopodobne niż błąd sprzętowy powodujący uszkodzenie danych. Kolizja UUID v4 jest traktowana jako niemożliwa w projektowaniu systemów produkcyjnych. Jeśli naprawdę potrzebujesz gwarancji zerowej kolizji, użyj scentralizowanego licznika lub sekwencji bazy danych.
UUID v4 a nanoid — co powinienem wybrać?
Oba są generatorami losowych identyfikatorów obsługiwanymi przez CSPRNG. Kluczowe różnice:
- UUID v4 jest zgodny ze standardem RFC 4122, jest rozpoznawany przez każdą bazę danych i framework i nie wymaga zależności (natywne
crypto.randomUUID()). - nanoid używa alfabetu bezpiecznego dla URL i jest domyślnie krótszy (21 znaków wobec 36). Przydatny, gdy liczy się długość URL lub czytelność. Wymaga pakietu npm.
Preferuj UUID v4, gdy liczy się interoperacyjność z systemami zewnętrznymi (API, bazy danych, infrastruktura logowania). Preferuj nanoid, gdy chcesz krótszych identyfikatorów i kontrolujesz cały stos.
Czy powinienem przechowywać UUID jako ciągi znaków czy binarnie w bazach danych?
Dla większości baz danych przechowywanie jako kolumna UUID lub BINARY(16) (16 bajtów) jest bardziej wydajne niż ciąg VARCHAR(36) (36 bajtów). PostgreSQL ma natywny typ uuid. MySQL i MariaDB dobrze współpracują z BINARY(16) oraz pomocnikami UUID_TO_BIN() / BIN_TO_UUID(). Użytkownicy SQLite zazwyczaj przechowują jako TEXT. Wybór przechowywania nie ma wpływu na unikalność ani poprawność.
Dlaczego UUID v4 ma myślniki — i czy mogę je pominąć?
Myślniki są częścią kanonicznej reprezentacji UUID zdefiniowanej przez RFC 4122. Są czysto kosmetyczne — nie niosą żadnych informacji i nie wpływają na 128-bitową wartość. Ich pominięcie daje kompaktowy 32-znakowy ciąg szesnastkowy, który jest funkcjonalnie równoważny. Większość parserów UUID akceptuje obie formy. W razie wątpliwości użyj kanonicznej formy z myślnikami, aby zapewnić maksymalną zgodność z narzędziami i bazami danych innych firm.
const id = crypto.randomUUID() // "550e8400-e29b-41d4-a716-446655440000"
const compact = id.replaceAll('-', '') // "550e8400e29b41d4a716446655440000"