UUID v4 generator

UUID v4 generator – nasumični identifikatori u vašem pregledniku

Ova alatna stranica generira jedan ili više UUID v4 identifikatora – 36‑znakovne nizove u standardnom 8‑4‑4‑4‑12 heksadecimalnom formatu. Možete birati broj (od 1 do 100), koristiti velika ili mala slova, te uključiti ili isključiti crtice. Svi identifikatori nastaju isključivo u vašem pregledniku, ništa se ne šalje na poslužitelj. Jedan UUID možete kopirati klikom na njega, ili sve odjednom gumbom za kopiranje.

Što ovaj generator čini drugačijim

Svaki UUID v4 koristi 122 bita čiste slučajnosti, a preostalih 6 bitova je fiksno – 4 bita za varijantu i 2 bita za verziju. To znači da ne postoji nikakva vremenska ili sekvencijalna informacija ugrađena u identifikator. UUID v4 vrijednosti ne mogu se sortirati po redoslijedu nastanka – one su potpuno nasumično raspoređene.

Zbog toga njihova upotreba kao primarnog ključa u bazi podataka razbija B‑stabla (B‑tree indexe). Kad se novi zapisi umetaju, indeks se ne širi na kraju stranice, nego se umetci događaju na proizvoljnim mjestima, što uzrokuje fragmentaciju, veći broj operacija razdvajanja stranica (page splits) i znatno sporije upisivanje. Ovo je ključno upozorenje za arhitekte baza podataka: ako vam je brzina upisa prioritet, razmislite o vremenski sortiranim formatima poput UUID v7 ili ULID.

Vjerojatnost kolizije (da dva generatora proizvedu isti UUID) je zanemariva za praktične potrebe. S 122 bita entropije, čak i uz generiranje milijardi identifikatora, vjerojatnost sudara ostaje iznimno mala – koristi se standardna kriptografska slučajnost iz crypto.randomUUID ili istovrsnog API‑ja.

Za razliku od drugih vrsta identifikatora na istoj alatnoj stranici (kao što su int‑ID ili string‑ID), UUID v4 ima vlastite kontrole formata – preklopke za velika slova i crtice. One su specifične samo za UUID v4 i v7, jer ostali formati koriste drugačije izlazne uzorke.

Struktura UUID v4 – standard, bitovi i prikaz

UUID v4 definiran je u RFC 4122, a njegova struktura izgleda ovako:

Ukupno: 122 bita slučajnosti + 6 bitova metadata = 128 bitova. U heksadecimalnom zapisu to daje 32 heksadecimalne znamenke, koje se standardno grupiraju u 8‑4‑4‑4‑12 uz crtice, dakle 36 znakova. Ako crtice isključite, dobivate goli 32‑znakovni heksadecimalni niz.

Bitovi verzije postavljeni su na 0100 (binarno), što u heksadecimalnom prikazu na poziciji 13. znaka daje vrijednost 4. Zato svaki ispravni UUID v4 na tom mjestu ima "4". Primjer: 550e8400-e29b-41d4-a716-446655440000 – treća grupa počinje s 4, a četvrta s a, b, 8 ili 9 (varijantni bitovi).

Slučajnost i vjerojatnost kolizije

Kad kažemo "122 bita entropije", to znači da postoji 2^122 mogućih različitih UUID v4 identifikatora. Da biste imali 50% šanse za bar jedan sudar u skupu od N nasumičnih UUID‑ova, potrebno je N ≈ 2^(122/2) = 2^61, što je otprilike 2,3 × 10^18. Nitko ne generira takve količine u praksi.

Zbog toga se UUID v4 koristi za:

• API tokene koji ne smiju biti predvidljivi.
• Sesijske identifikatore gdje vremenski slijed ne želite otkriti.
• Distribuirane sustave u kojima se identifikatori stvaraju na više čvorova bez središnje koordinacije.
• Sigurnosne identifikatore (npr. jedinstveni ID zahtjeva).

Međutim, ako trebate identifikatore koje možete sortirati po vremenu nastanka, ili ako vam je brzina upisa u bazu kritična, možda je bolje odabrati UUID v7 (koji je također dostupan u istom alatnom padajućem izborniku) ili ULID.

Utjecaj na indekse baza podataka – zašto random nije uvijek dobar

Kada koristite UUID v4 kao primarni ključ u relacijskoj bazi (npr. PostgreSQL, MySQL), on se obično pohranjuje u B‑stablo indeks. B‑stablo je optimizirano za sekvencijalno umetanje – kad ključevi rastu monotono, novi se podaci dodaju na desni rub indeksa, što je brzo i ne zahtijeva ponovno balansiranje.

S UUID v4 ključevi su nasumično raspoređeni, pa se svaki novi redak najčešće umetne u sredinu indeksa. To uzrokuje:

• Fragmentaciju indeksa – puno praznog prostora na stranicama.
• Povećan broj page splitova – svaki put kad stranica postane puna, treba je podijeliti.
• Više I/O operacija – indeks postaje veći i sporiji za pretraživanje.
• Gubitak predmemorije – jer se ne mogu predvidjeti koji će dijelovi indeksa biti korišteni.

Procjenjuje se da upisivanje nasumičnih ključeva može biti 10 do 20 puta sporije od sekvencijalnih, ovisno o veličini tablice i količini indeksa. To ne znači da UUID v4 treba izbjegavati po svaku cijenu – već da treba razumjeti kompromis između prednosti (jedinstvenost bez centralnog servera, nepredvidljivost) i cijene performansi.

Ako koristite UUID v4, razmislite o:

• Korištenju UUID tipa (umjesto niza znakova) u bazi – neke baze imaju optimizirani prikaz (npr. PostgreSQL uuid tip koristi 128 bita umjesto 36 bajtova).
• Particioniranju tablica po rasponu (npr. po hash‑u) kako bi se smanjila fragmentacija.
• Zamjeni s UUID v7 ako vam je vremensko sortiranje prihvatljivo i sigurnosni zahtjevi nisu previsoki.

Prilagodba formata – velika slova i crtice

Alat nudi dvije preklopke koje utječu na izgled UUID‑a:

• Uppercase (velika slova): Ako je uključeno, heksadecimalne znamenke a–f prikazuju se kao A–F. Inače se koriste mala slova. Standard RFC 4122 ne propisuje velika ili mala slova – oboje je valjano. Međutim, neki sustavi (npr. datotečni sustavi na Linuxu) razlikuju velika i mala slova, dok ih drugi (npr. Windows) ignoriraju. Ako želite dosljednost u svim okruženjima, preporučuje se velika slova jer su vizualno uočljivija, ali mala slova su češća u praksi.
• Include hyphens (uključi crtice): Standardni prikaz uvijek sadrži crtice na pozicijama 8, 13, 18 i 23. Ako ih isključite, dobivate niz od 32 heksadecimalne znamenke bez razmaka. To je korisno:
  • za URL‑ove – jer crtice mogu biti interpretirane (npr. u nekim web adresama) i čine identifikator dužim.
  • za baze podataka – 32‑znakovni niz bez crtica je kraći i lakše se indeksira.
  • za JSON ili XML – manje znakova znači manji payload.

No, bez crtica gubi se ljudska čitljivost i mogućnost brzog vizualnog provjeravanja formata.

Generiranje u pregledniku – sigurnost i privatnost

Svi UUID v4 identifikatori generiraju se lokalno u vašem pregledniku. Alatni kod koristi crypto.getRandomValues() ili crypto.randomUUID() (dostupno u modernim preglednicima). To znači:

• Podaci ne napuštaju vaše računalo – nema slanja na poslužitelj, nema dnevnika, nema analitike.
• Generiranje je trenutno – čak i za 100 UUID‑ova, vrijeme je ispod milisekunde.
• Rad izvan mreže – alat radi i bez internetske veze.
• Pouzdana nasumičnost – kriptografski generator osigurava da se ista vrijednost ne može lako predvidjeti.

Jedina iznimka je ako koristite vrlo stari preglednik bez podrške za Crypto API – tada bi mogao pasti na manje siguran generator, ali to je iznimno rijetko.

Često postavljana pitanja

1. Koja je razlika između UUID v4 i UUID v7? UUID v4 koristi 122 bita slučajnosti i potpuno je nasumičan. UUID v7 koristi vremensku oznaku (timestamp) na početku, pa su identifikatori sortirani po vremenu nastanka. To smanjuje fragmentaciju indeksa, ali otkriva približno vrijeme nastanka.

2. Je li sigurno koristiti UUID v4 kao primarni ključ? Sigurnosno da – jedinstvenost je zajamčena. No, performanse upisa mogu patiti zbog fragmentacije indeksa. Ako vam je brzina upisa kritična, razmislite o vremenski sortiranim identifikatorima.

3. Mogu li generirati više od 100 UUID‑ova odjednom? Alat dopušta maksimalno 100. Ako trebate više, jednostavno ponovite generiranje ili upotrijebite programsko rješenje.

4. Zašto na poziciji 13 (treća grupa) uvijek vidim “4”? To je fiksni bit koji označava verziju (verzija 4 = random). Slično, na poziciji 17 (četvrta grupa) uvijek će biti 8, 9, a ili b – to su bitovi varijante.

5. Što se dogodi ako isključim crtice – hoće li UUID i dalje biti valjan? Da. Bez crtica to je jednostavno 32‑znakovni heksadecimalni niz. On se može pretvoriti natrag u standardni prikaz dodavanjem crtica na ispravna mjesta. Mnogi sustavi prihvaćaju oba oblika.

6. Kako znam da je generirani UUID stvarno nasumičan? Alat koristi crypto.randomUUID(), koji je definiran u W3C specifikaciji kao kriptografski jak generator. Ne postoji način da se predvidi sljedeća vrijednost bez poznavanja unutarnjeg stanja preglednika.