UUID v4 ģenerators: darbības princips un iespējas
Šī lapa ģenerē vienu vai vairākus UUID v4 identifikatorus – nejaušas 36 rakstzīmju virknes standarta 8‑4‑4‑4‑12 hex formātā. Jūs kontrolējat ID skaitu (līdz 100) un to, vai tie tiek rādīti lielajiem burtiem vai ar defisēm. ID tiek izveidoti acumirklī jūsu pārlūkprogrammā, izmantojot spēcīgu pārlūkprogrammas nejaušību; varat nokopēt vienu ID vai visus uzreiz. Atšķirībā no citiem identifikatoru veidiem, UUID v4 izmanto 122 nejaušības bitus bez iegulta laikspiedola, tāpēc katra vērtība ir praktiski neparedzama un kolīziju iespējamība ir niecīga. Tas padara šo lapu par noderīgu rīku izstrādātājiem, kuriem nepieciešami unikāli, neparedzami identifikatori drošības žetoniem, sesiju ID vai ne‑secīgām atslēgām.
UUID v4 struktūra un nejaušības avots
UUID v4 ir definēts RFC 4122 standartā un sastāv no 16 oktetiem jeb 128 bitiem. No tiem 122 biti ir nejauši (random), bet 6 biti ir fiksēti – 4 biti norāda versiju (v4 = 0100) un 2 biti norāda variantu (10). Izvada formāts ir 36 rakstzīmes: 32 hex cipari, kas sadalīti grupās pa 8‑4‑4‑4‑12, un starp tām 4 defises. Piemērs: 550e8400‑e29b‑41d4‑a716‑446655440000. Ja defises ir izslēgtas, iegūstam 32 hex ciparu virkni bez atdalītājiem (piem., 550e8400e29b41d4a716446655440000). Uppercase pārvērš burtus no a‑f uz A‑F.
Šī lapa ģenerē nejaušību, izmantojot pārlūkprogrammas kriptogrāfisko pseidogadījuma skaitļu ģeneratoru (CSPRNG). Pārlūkprogrammas, piemēram, Chromium, Firefox un Safari, nodrošina piekļuvi operētājsistēmas nejaušības avotiem, kas ir pietiekami stipri drošības kritiskiem lietojumiem. Katrs UUID tiek veidots, pieprasot 16 nejaušus baitus, pēc tam atbilstoši standartam iestatot versijas un varianta bitus un pārveidojot par hex virkni. Tas notiek pilnībā lokāli – nekādi dati netiek sūtīti uz serveri. Mainot jebkuru opciju (skaitu, lielos burtus, defises), tiek atkārtoti ģenerēts viss komplekts.
Kāpēc izvēlēties UUID v4, nevis citus formātus?
Galvenā UUID v4 priekšrocība ir tā augstā neparedzamība. Tā kā vērtībā nav iekļauts laikspiedols, secīgi ģenerēti UUID v4 ir praktiski nekorelēti. Tas ir svarīgi drošības lietojumos, piemēram, atiestatīšanas žetonos, kur uzbrucējs nedrīkst uzminēt nākamo vērtību. Salīdzinājumam, UUID v7 un ULID izmanto laikspiedolu, padarot tos prognozējamus, ja ir zināms laiks.
Tomēr šī pati īpašība rada problēmas datubāzu indeksos. UUID v4 identifikatori kārtojas patvaļīgi – tie nesatur hronoloģisku informāciju, tāpēc, tos izmantojot kā primāro atslēgu, rindas tiek ievietotas nejaušās vietās indeksā, izraisot lappušu sadalīšanos (page splits) un pasliktinot veiktspēju ierakstu ievietošanā. Tāpēc datubāzu administratori bieži dod priekšroku laikā sakārtotiem identifikatoriem (UUID v7, ULID vai secīgiem ID), lai saglabātu indeksu saspiešanu. UUID v4 ir jālieto apzinoties šo kompromisu starp neparedzamību un kārtošanas kārtību.
Šī lapa ļauj ātri ģenerēt līdz 100 UUID v4 vērtībām testēšanai, ārējo identifikatoru izveidei vai anonīmu atslēgu ģenerēšanai, kur laika kārtība nav svarīga. Lai pārslēgtos uz citiem formātiem, lapā ir pieejami arī UUID v7, ULID un NanoID – mainot formātu, opcijas lielajiem burtiem un defisēm var mainīties, bet UUID v4 režīmā tās ir fiksētas.
Ģenerēšanas opcijas un to ietekme
Lapā ir trīs vadīklas, kas ietekmē UUID v4 izvadi:
- Count – skaitlis no 1 līdz 100 (ieskaitot), kas norāda, cik identifikatoru ģenerēt.
- Uppercase – pārslēgs, kas noklusējuma stāvoklī ir izslēgts (false), t.i., izvade ir mazie burti. Ieslēdzot, visi hex burti (
a–f) kļūst par lielajiem (A–F). - Include hyphens – pārslēgs, kas noklusējuma stāvoklī ir ieslēgts (true), t.i., starp grupām tiek liktas defises. Izslēdzot, iegūst 32 hex ciparu virkni bez defisēm.
Mainot jebkuru no šiem iestatījumiem, tiek nekavējoties atkārtoti ģenerēts viss ID komplekts (atbilstoši jaunajam skaitam un opcijām). Tas ir svarīgi, jo dažos gadījumos var būt nepieciešami identifikatori noteiktā formātā – piemēram, bez defisēm, lai tos izmantotu URL bez kodēšanas, vai lielajiem burtiem, lai atbilstu citai sistēmas konvencijai.
Pēc ģenerēšanas lapas apakšā tiek parādīts statusa ziņojums: “Ready.” (sākotnējais stāvoklis), “Generated.” (pēc ģenerēšanas) un “Copied all!” (pēc visu ID nokopēšanas).
Kā darbojas kopēšana un lokālā apstrāde
Katra ģenerētā UUID v4 virkne ir noklikšķināma – uzklikšķinot uz tās, identifikators tiek nokopēts starpliktuvē. Turklāt ir poga “Copy all”, kas nokopē visus sarakstā redzamos ID (atdalītus ar jaunām rindiņām). Tas ir ērti, ja nepieciešams imports vai vienlaicīga izmantošana vairākās vietās.
Visa apstrāde notiek tikai pārlūkprogrammā. Tas nozīmē, ka:
- Dati netiek sūtīti uz serveri, tāpēc nav datu noplūdes riska.
- Ģenerēšana ir pieejama arī bez interneta savienojuma (ja lapa jau ir ielādēta).
- Nav latentuma – visi 100 ID tiek izveidoti +– tūkstošdaļās sekundes.
Šī arhitektūra ir būtiska privātumam un lietojamībai, jo īpaši izstrādātājiem, kas strādā ar sensitīviem datiem vai izstrādā sistēmas, kurās identifikatori nedrīkst nonākt trešo pušu rokās.
Biežākās kļūdas un ierobežojumi
Kolīziju varbūtība. Lai gan 122 nejauši biti teorētiski nodrošina ļoti zemu kolīziju iespējamību, tā nav nulle. Praktiski: lai sasniegtu 50% kolīziju varbūtību, būtu nepieciešams ģenerēt apmēram 2⁶¹ ≈ 2,3 × 10¹⁸ UUID. Pat ģenerējot 1 miljonu UUID sekundē, tas prasītu miljardiem gadu. Tāpēc vienas lapas ietvaros kolīzija nav iespējama, bet, ja tiek izmantoti identifikatori no dažādiem avotiem, teorētiskā iespēja pastāv. Tomēr praktiskiem nolūkiem tā ir nenozīmīga.
Indeksu veiktspēja. Kā minēts, UUID v4 kārtojas patvaļīgi, kas var sadrumstalot B‑koka indeksus relāciju datubāzēs. Ja primārā atslēga ir UUID v4, ierakstu ievietošana bieži vien prasa indeksa lapu sadalīšanu, palēninot rakstīšanu. Ja projektā nepieciešama augsta ierakstu veiktspēja un secīgie laikspiedoli ir pieņemami, vēlams lietot UUID v7 vai ULID.
Opciju pārpratumi. Daži lietotāji var domāt, ka iespēja mainīt lielos burtus vai defises ietekmē pašu identifikatoru nejaušību vai versiju – tā nav. Iekšējie biti paliek tie paši; mainās tikai attēlojums. Turklāt, mainot formātu (piem., uz UUID v7), opcijas var mainīties pavisam – šajā rakstā fokuss ir tikai uz UUID v4.
Skaits ārpus diapazona. Ja ievadīts skaitlis, kas nav starp 1 un 100, lapa to nepieņem. Tas ir drošības un veiktspējas ierobežojums – ģenerēt vairāk par 100 būtu nepraktiski un varētu pārslogot pārlūkprogrammu.
Biežāk uzdotie jautājumi
1. Vai UUID v4 ir pilnībā unikāls? Nē, tas ir ļoti ticams, ka tas ir unikāls, bet teorētiski pastāv kolīzijas iespēja (122 nejauši biti). Praksē tā ir niecīga – jūs, visticamāk, sastapsiet kolīziju tikai pēc kvintiljoniem ģenerētu ID.
2. Kāpēc lapa prasa atkārtoti ģenerēt, mainot jebkuru opciju? Tas nodrošina, ka visi ID ir konsekventi jaunajos iestatījumos. Piemēram, ja maināt no mazajiem burtiem uz lielajiem burtiem, visi ID tiek pārveidoti atbilstoši, nevis tiek mainīts tikai attēlojums esošajiem.
3. Vai varu ģenerēt vairāk nekā 100 ID vienlaikus? Nē, šajā lapā maksimālais ir 100. Ja nepieciešams vairāk, varat veikt vairākas ģenerēšanas secīgi un apvienot rezultātus.
4. Kā tiek ģenerēta nejaušība pārlūkprogrammā?
Izmantojot crypto.getRandomValues() JavaScript API, kas piekļūst operētājsistēmas kriptogrāfiskajam nejaušības avotam. Tas ir piemērots arī drošības žetonu ģenerēšanai.
5. Vai UUID v4 ir drošs lietošanai kā sesijas ID? Jā, ja tas tiek ģenerēts lokāli un ar spēcīgu nejaušību, kā šajā lapā. Tomēr jāņem vērā, ka pats UUID v4 standarts neprasa, lai bits tiktu ģenerēti tikai ar CSPRNG; šajā lapā tas ir nodrošināts.
6. Vai defises ietekmē UUID garumu un unikalitāti? Nē, defises ir tikai formatējuma elementi – tās neietekmē bitus. Unikalitāte ir atkarīga tikai no 122 nejaušajiem bitiem. Noņemot defises, iegūstat īsāku virkni (32 hex cipari), bet tā joprojām reprezentē to pašu 128 bitu vērtību.