Generátor UUID

• UUID v1 kombinuje časové razítko s MAC adresou stroje — je zaručeně unikátní, ale odhaluje čas vytvoření a hardwarovou identitu, což vyvolává obavy o soukromí.
• UUID v3 a v5 jsou deterministické hashe: v3 používá MD5, v5 používá SHA-1. S daným jmenným prostorem a názvem vytvářejí vždy stejné UUID — užitečné pro generování konzistentních identifikátorů z přirozených klíčů (např. převod e-mailových adres na uživatelská ID).
• UUID v4 využívá 122 bitů náhodných dat a poskytuje nejsilnější záruku unikatity bez prozrazení jakýchkoli informací.
• UUID v7 (RFC 9562, 2024) vkládá Unixové časové razítko do prvních 48 bitů a zároveň ponechává 74 náhodných bitů — je řaditelné podle času vytvoření, což je ideální pro primární klíče databází, kde záleží na výkonu indexů.

Pro většinu aplikací je v4 výchozí volbou; na v7 přejděte u databázových primárních klíčů, kde záleží na pořadí vkládání.

UUID v4 využívá 122 náhodných bitů, což dává 5,3 × 10^36 možných hodnot. Problém narozenin určuje pravděpodobnost kolize: po vygenerování 2,7 × 10^18 (2,7 kvintilionu) UUID existuje 50% šance na jednu kolizi.

Prakticky vzato, generování 1 miliardy UUID za sekundu po dobu 85 let dosáhne této prahové hodnoty. Při realističtějších měřítkách — systém generující 1 milion UUID za den — je pravděpodobnost jakékoliv kolize za 100 let přibližně 1 ku 10^24.

To předpokládá správný generátor náhodných čísel (CSPRNG); použití Math.random() v JavaScriptu (které není kryptograficky bezpečné) snižuje entropii a zvyšuje riziko kolize. Pro produkční systémy vždy používejte crypto.randomUUID(), knihovny pro uuid v4 nebo nativní databázové funkce UUID.

UUID jako primární klíče umožňují decentralizované generování ID (aplikace vytvářejí ID bez zpětných dotazů do databáze) a zabraňují útokům enumerací (uživatelé nemohou uhodnout ID ostatních záznamů).

Náhodné hodnoty UUID v4 však snižují výkon B-stromových indexů — náhodná vkládání způsobená štěpením stránek a fragmentací zvyšují zápisovou amplifikaci 2–5krát ve srovnání s celočíselnými sekvenčními klíči. UUID v7 to řeší náhodností předponovanou časovým razítkem, což poskytuje jak unikatitu, tak sekvenční řazení.

Náklady na úložiště jsou také vyšší: 16 bajtů oproti 4–8 bajtům u celých čísel, což je významné u tabulek s miliardami řádků a mnoha indexy.

Běžným vzorem je kombinace UUID jako veřejných identifikátorů s interními celočíselnými klíči s autoincrementem, přičemž tabulky se propojují pomocí efektivního celého čísla, zatímco API a URL vystavují pouze zabezpečené UUID.

UUID (Universally Unique Identifier) je 128bitová hodnota navržená tak, aby byla unikátní v prostoru i čase bez nutnosti centrální registrační autority, jak definuje standard IETF RFC 9562 (který nahrazuje dřívější RFC 4122).

Jeho 128 bitů se zapisuje jako 32 hexadecimálních znaků seskupených ve vzoru 8-4-4-4-12, například 550e8400-e29b-41d4-a716-446655440000. Specifické bity jsou rezervovány: 13. hexadecimální znak kóduje verzi a horní bity 17. hexadecimálního znaku kódují variantu.

Zbývající bity nesou náhodná data, časové razítko nebo hashovaný název v závislosti na verzi. Protože adresovatelný prostor je 2^122, mohou nezávislé generátory bezpečně vytvářet identifikátory, aniž by se kdykoliv vzájemně koordinovaly.

Nejjednodušší způsob, jak vygenerovat UUID, je použít vestavěnou funkci jazyka, která volá kryptograficky bezpečný zdroj náhodných čísel.

• V jazyce JavaScript vrací funkce crypto.randomUUID() verzi v4 UUID a je zdokumentována na MDN Web Docs jako součást rozhraní Web Crypto API, které je k dispozici v moderních prohlížečích a v Node.js 14.17+.
• V jazyce Python poskytuje modul ze standardní knihovny uuid funkci uuid.uuid4() pro náhodné hodnoty a uuid.uuid1() pro hodnoty založené na časovém razítku.
• V systému PostgreSQL vytváří gen_random_uuid() verzi v4 UUID, zatímco MySQL 8 nabízí UUID() pro hodnotu ve stylu v1.

Všechny tyto možnosti generují řetězce odpovídající standardu RFC 9562, takže ID vygenerovaná v jednom jazyce fungují bez problémů i v jiném.

Ano, GUID a UUID jsou stejný 128bitový identifikátor; GUID (Globally Unique Identifier) je jednoduše terminologie společnosti Microsoft pro standardní UUID definovaný v RFC 9562 IETF. Jsou binárně kompatibilní, takže hodnotu vytvořenou systémem Windows nebo .NET může zpracovat jakýkoli systém splňující specifikaci RFC a naopak.

Jediným běžným rozdílem je zobrazení: nástroje od Microsoftu často obalují hodnotu do složených závorek, například {550e8400-e29b-41d4-a716-446655440000}, a některá rozhraní COM API v minulosti používala velká písmena pro šestnácti soustavu.

Jemným úskalím je pořadí bajtů – binární GUID od Microsoftu ukládá první tři pole v kódování little-endian, což je důležité pouze při parsování nezpracovaných bajtů, nikoli u kanonického řetězcového formátu s pomlčkami.

UUID není tajemství a nikdy by se s ním tak nemělo zacházet, a to ani v případě, že jeho náhodné bity pocházejí z kryptograficky bezpečného generátoru. Norma RFC 9562 výslovně varuje, že UUID nenabízejí žádné vestavěné zabezpečení a nesmí se předpokládat, že je těžké je odhadnout; organizace OWASP podobně varuje před používáním identifikátorů jako autorizačních tokenů.

Verze 4 čerpá 122 bitů z generátoru CSPRNG, takže je nepraktické ji předvídat, ale verze 1 a verze 7 obsahují časová razítka, která prozrazují čas vytvoření, a verze 3 a verze 5 jsou deterministické hashe známého jmenného prostoru a názvu.

Pro tokeny relací, obnovení hesla nebo klíče API generujte raději vyhrazené tajné klíče s vysokou entropií, než abyste se spoléhali na strukturu UUID kvůli ochraně.

Pole verze a varianty jsou pevné bitové vzory integrované v každém UUID dle RFC 9562, které parserům říkají, jak byla hodnota vygenerována.

Verze zabírá čtyři nejvýznamnější bity sedmého bajtu (13. šestnáctková číslice), takže v4 UUID má na tomto místě vždy 4 a v7 vždy 7. Varianta se nachází ve dvou nebo třech nejvýznamnějších bitech devátého bajtu (17. šestnáctková číslice), což u standardní varianty IETF znamená, že tato číslice je 8, 9, a nebo b.

Proto platné v4 UUID odpovídá vzoru xxxxxxxx-xxxx-4xxx-[89ab]xxx-xxxxxxxxxxxx. Kontrola těchto pevných pozic je správný způsob ověření nebo klasifikace UUID namísto volné kontroly délky.

Hromadné generování UUID je užitečné pro plnění databází, vytváření testovacích sad, zátěžové testování a vyplňování simulovaných rozhraní API a tento nástroj dokáže vygenerovat mnoho platných identifikátorů jedním kliknutím. Vzhledem k tomu, že každé UUID je vytvořeno nezávisle z náhodného zdroje nebo zdroje časového razítka podle RFC 9562, nenese generování dávky žádné významné riziko kolize ani při velkém počtu položek.

Pro opakovatelná testovací data upřednostněte deterministická UUID verze 5 odvozená z pevného jmenného prostoru a názvu, aby stejný vstup vždy přinesl stejný identifikátor napříč spuštěními.

Při plnění tabulek v produkčním měřítku zvažte verzi 7, aby hromadně vkládané řádky skončily v přibližně sekvenčním pořadí indexů, což udržuje stránky B-stromu kompaktní a snižuje zesílení zápisu během importu.

Ukládejte UUID do nativního 16bajtového binárního typu, kdykoliv jej vaše databáze podporuje, protože jejich uchovávání ve formě 36znakového textu plýtvá více než dvojnásobným místem a zpomaluje porovnávání indexů. Systém PostgreSQL poskytuje vyhrazený typ sloupce uuid, zatímco MySQL a SQL Server běžně používají typ BINARY(16) s konverzními funkcemi pro převod do a z řetězce s pomlčkami.

Jak uvádí norma RFC 9562, UUID nerozlišují velká a malá písmena a před uložením by měla být normalizována – obvykle na malá písmena –, aby vyhledávání zůstalo konzistentní.

Pokud používáte UUID jako primární klíče, dejte přednost verzi 7, abyste zachovali lokalitu vkládání; pokud musíte použít verzi 4, některé enginy umožňují přeuspořádat bity časového razítka, přičemž verze 7 představuje standardní řešení téhož problému s fragmentací.

Nejčastější chybou při práci s UUID je použití nekryptografického zdroje náhodných čísel, jako je funkce Math.random() v jazyce JavaScript, která není generátorem CSPRNG a může produkovat zkreslené nebo předvídatelné hodnoty; MDN proto doporučuje použít crypto.randomUUID() nebo Web Crypto API.

Mezi další časté chyby patří:

• považování nulového UUID (samé nuly) za skutečný identifikátor
• předpoklad, že UUID jsou dostatečně tajná pro autorizaci přístupu
• jejich ukládání jako textu, kdy by 16bajtový binární sloupec byl mnohem efektivnější

Vývojáři také nekonsistentně míchají verze nebo spoléhají na verzi 1 v kontextech citlivých na soukromí, kde její vložené časové razítko a historická MAC adresa prozrazují informace. Porovnávání UUID s ohledem na velikost písmen nakonec vede k falešným neshodám, protože RFC 9562 definuje, že na velikosti písmen nezáleží.