Generátor UUID

Generátor UUID v4

Tento nástroj vytváří jedno nebo více UUID verze 4 – náhodné 36znakové řetězce ve standardním formátu 8-4-4-4-12 hexadecimálních znaků. Ovládáte počet identifikátorů (až 100) a to, zda se zobrazí velkými písmeny nebo s pomlčkami. Identifikátory se generují okamžitě ve vašem prohlížeči s využitím silné náhody z prohlížečového rozhraní; můžete zkopírovat jeden identifikátor nebo všechny najednou.

Co dělá tuto stránku odlišnou

UUID v4 používá 122 bitů náhody bez vložené časové značky, takže každá hodnota je prakticky nepředvídatelná a pravděpodobnost kolize je zanedbatelná. Na rozdíl od UUID v7 nebo ULID se hodnoty v4 řadí libovolně – nenesou žádnou časovou informaci, což při použití jako primární klíč fragmentuje databázové indexy. Tato stránka také umožňuje přepínat mezi velkými a malými písmeny a volit, zda se pomlčky zobrazí či nikoli, ale vnitřní náhoda a formát jsou pevně dány. Výchozí výstup je malými písmeny s pomlčkami. Změna libovolné volby vygeneruje celou sadu znovu.

Základní principy a struktura UUID v4

UUID verze 4 je definováno v RFC 4122 jako varianta, která nevyužívá časové údaje ani vlastnosti síťové karty. Místo toho je 122 bitů náhodných dat doplněno o 6 bitů pevně daných specifikací: 4 bity označují verzi (v4 = 0100 binárně = hexadecimálně 4) a 2 bity určují variantu (10 binárně, což dává v hexadecimálním zápisu hodnoty 8, 9, A nebo B v prvním nibblu třetího bloku). Výsledkem je 128 bitů uložených v 16 oktetech.

Formát zápisu je 8-4-4-4-12, tedy například:

f47ac10b-58cc-4372-a567-0e02b2c3d479

Podrobné rozložení:

Bez pomlček by stejné UUID vypadalo jako f47ac10b58cc4372a5670e02b2c3d479 (32 hex znaků). Počet pomlček je vždy 4, bez ohledu na hodnotu.

Při přepnutí na velká písmena se hexadecimální znaky a–f změní na A–F. Vnitřní hodnota zůstává stejná – záleží jen na formátování. Každá změna volby (počet, velikost písmen, pomlčky) spustí okamžité nové vygenerování všech identifikátorů.

Jak prohlížeč generuje náhodná data

Tento nástroj používá prohlížečové rozhraní Web Crypto API (crypto.getRandomValues), které poskytuje kryptograficky silnou pseudonáhodu. Na rozdíl od běžného Math.random() je tato metoda navržena tak, aby produkovala nepředvídatelná data vhodná pro zabezpečení. Rozhraní čerpá z entropie systému – pohyb myši, latence síťových operací, časování kláves a další zdroje – a generuje 32 pseudonáhodných bytů, ze kterých se poté konstruuje požadovaný počet UUID.

Pro každý UUID v4 se vytvoří 16 bytů náhody. Prvních šest bytů se upraví tak, aby se nastavila verze a varianta: čtvrtý oktet dostane horní nibbl nastaven na 0100 (verze 4) a šestý oktet dostane horní dva bity nastavené na 10 (varianta RFC 4122). Zbývajících 122 bitů zůstává zcela náhodných. Všechno zpracování probíhá lokálně v prohlížeči – nikam se neodesílá žádný mezikrok ani výsledný identifikátor.

Pravděpodobnost kolize a její dopady

Při 122 bitech náhody existuje 2^122 možných unikátních hodnot, tedy přibližně 5,3×10^36. Abychom dosáhli 50% pravděpodobnosti kolize, museli bychom vygenerovat zhruba 2,2×10^18 UUID – to je 2,2 kvintilionu identifikátorů. V praxi to znamená, že pokud byste každou sekundu vygenerovali miliardu UUID, trvalo by 70 let, než byste dosáhli poloviční šance na kolizi.

Tato čísla vycházejí z narozeninového paradoxu: pravděpodobnost kolize roste s druhou mocninou počtu vygenerovaných hodnot. U UUID v4 je riziko natolik nízké, že ho většina aplikací považuje za prakticky nulové. Přesto byste neměli spoléhat na to, že kolize nemůže nastat – například při ukládání identifikátorů do databáze je vhodné mít unikátní index jako ochranu.

Důležité je, že UUID v4 negeneruje časovou informaci. Když vygenerujete dvě UUID za sebou, nemůžete z nich vyčíst, které bylo dříve. To je výhodné pro případy, kdy nechcete, aby identifikátor prozrazoval čas vytvoření (například u anonymizovaných dat), ale zároveň to komplikuje řazení v databázi.

Dopad na výkon databáze

UUID v4 má při použití jako primární klíč v relačních databázích známý problém: náhodné řazení způsobuje fragmentaci indexů. Když databáze vkládá nový řádek, musí ho umístit na náhodnou pozici v B-stromu indexu, což vede k častým štěpením stránek. U sekvenčních klíčů (například auto_increment) se nové hodnoty přidávají na konec, což minimalizuje reorganizace.

Standardní UUID v4 způsobuje při vkládání až 4–5krát více I/O operací než sekvenční klíč v závislosti na velikosti databáze a indexu. Pro malé tabulky (do 100 000 řádků) je rozdíl zanedbatelný, ale u tabulek s miliony řádků může být zpomalení znatelné.

Alternativou je UUID v7, které kombinuje 48bitovou časovou značku s náhodnými bity. V7 zachovává jedinečnost a částečnou nepředvídatelnost, ale hodnoty se řadí přibližně chronologicky, což zlepšuje výkon indexů téměř na úroveň sekvenčních klíčů. ULID jde ještě dále – používá base32 kódování pro kratší reprezentaci při zachování časového řazení.

Pro identifikátory, u kterých nepotřebujete časové řazení (bezpečnostní tokeny, session ID, externí klíče bez vazby na databázové indexy), zůstává UUID v4 dobrou volbou. Nepředvídatelnost je u těchto případů důležitější než výkon při vkládání.

Možnosti formátování a jejich praktické využití

Tento nástroj nabízí tři ovládací prvky: počet (1–100), velikost písmen (výchozí malá) a zobrazení pomlček (výchozí zapnuto). Každá změna okamžitě vygeneruje novou sadu UUID.

Velikost písmen: Většina systémů používá malá písmena, ale některé starší systémy nebo specifikace vyžadují velká. Například některé varianty UUID v RFC 4122 se uvádějí velkými písmeny, ačkoli samotný standard říká, že zpracování by mělo být case‑insensitive. Výběr velikosti písmen nemění hodnotu UUID, pouze jeho textovou reprezentaci.

Pomlčky: Standardní formát s pomlčkami je čitelnější a očekávaný ve většině API. Některé systémy ale pracují s UUID bez pomlček, například v databázových sloupcích typu UNIQUEIDENTIFIER v SQL Serveru se hodnoty ukládají bez pomlček. Webová rozhraní někdy používají UUID s pomlčkami v URL, ale pak je nutné je URL‑encode. Bez pomlček je řetězec kratší o 4 znaky a lépe se kopíruje do systémů, které pomlčky neočekávají.

Počet: Generování až 100 UUID najednou je užitečné pro testování, předgenerování dávek identifikátorů nebo naplnění databáze testovacími daty. Všechna UUID se generují v jednom průchodu, takže i 100 hodnot vznikne prakticky okamžitě. Každé UUID je nezávislé a náhodné – neexistuje mezi nimi žádná korelace.

Místní zpracování a důsledky pro bezpečnost

Všechna generování probíhají výhradně v prohlížeči – ani vstupní parametry, ani vygenerovaná UUID se nikam neodesílají. To má několik důsledků:

• Stránka funguje offline po načtení.
• Žádný server se nedozví, jaké identifikátory jste vygenerovali.
• Není možné, aby se vygenerovaná data zachytila při přenosu.
• Není potřeba registrace ani přihlášení.

Pro bezpečnostní tokeny, resetovací odkazy nebo dočasné klíče je to důležité – víte, že nikdo jiný nemohl identifikátor zachytit ani ho ovlivnit. Kryptografická kvalita náhody je dána implementací crypto.getRandomValues, která je v moderních prohlížečích stejná jako ta, kterou používají samotné prohlížeče pro TLS relace.

Jediné riziko představuje přenos vygenerovaných UUID do jiného systému – například ručním zkopírováním do schránky. Pokud kopírujete identifikátory z prohlížeče do aplikace, ujistěte se, že je nepřeposíláte nezabezpečeným kanálem. Samotný nástroj s nimi ale nijak nenakládá.

Často kladené otázky

Je UUID v4 bezpečné pro generování přístupových tokenů? Ano, pokud potřebujete náhodný identifikátor, který není možné uhodnout. 122 bitů náhody poskytuje dostatečnou entropii. Pro dlouhodobé tokeny ale zvažte použití JWT nebo podobných mechanismů s podpisem.

Může se stát, že dvě UUID v4 budou stejná? Teoreticky ano, ale pravděpodobnost je extrémně nízká. Při vygenerování 2,2×10^18 UUID byste měli 50% šanci na jednu kolizi. Pro běžné použití (tisíce až miliony UUID) je kolize prakticky vyloučena.

Proč se UUID v4 nedoporučuje jako primární klíč v databázi? Náhodné řazení způsobuje fragmentaci indexů, což zpomaluje vkládání. Pokud databáze obsahuje miliony řádků, může být rozdíl oproti sekvenčnímu klíči výrazný. Alternativou je UUID v7 nebo ULID, které kombinují časové řazení s náhodou.

Znamená volba velkých písmen, že UUID má jinou hodnotu? Ne. Velká a malá písmena jsou považována za case‑insensitive – a a A reprezentují stejnou hexadecimální hodnotu 10. Volba formátování nemění samotné UUID.

Proč je maximální počet UUID omezen na 100? Limit 100 UUID na jedno vygenerování zajišťuje, že stránka zůstane rychlá a přehledná. Pokud potřebujete více, můžete kliknout několikrát nebo použít programové řešení.

Je bezpečné používat UUID v4 v URL adresách? Ano, ale pozor na pomlčky – v některých kontextech mohou být interpretovány jako oddělovače. Pokud UUID vkládáte do URL, doporučuje se odstranit pomlčky nebo celý řetězec správně URL‑encodovat.