Strumenti per sviluppatori · Generatore UUID
Come crypto.getRandomValues trasforma 16 byte casuali in un v4 UUID
· Come funziona
uuid crittografia API del browser
Una versione 4 UUID proviene da 16 bytes da un generatore crittograficamente sicuro con sei bit sovrascritti. Questo post guida i byte dalla chiamata Web Crypto alla familiare stringa di caratteri 36.
L'ID di cui hai bisogno prima che il server risponda: perché la generazione lato client si presenta in moduli offline-first, interfaccia utente ottimistica e importazioni batch
Un modulo offline potrebbe richiedere un identificatore prima che un server risponda e un'interfaccia utente ottimistica potrebbe creare più oggetti contemporaneamente. Un UUIDv4 è progettato per essere generato in modo indipendente senza un contatore centrale. Non è una prova dell'identità dell'utente o un segreto che puoi tranquillamente inserire al posto dell'autenticazione. Se il tuo database necessita di valori ordinati in base all'ora di creazione, gli ID v4 casuali non vengono ordinati; questa è una decisione di schema separata piuttosto che una ragione per indebolire la loro casualità.
Cosa fa effettivamente crypto.getRandomValues: riempire un array digitato dalla fonte di entropia del sistema operativo, non da una formula JavaScript
crypto.getRandomValues riempie un Uint8Array con 16 bytes dal generatore casuale crittograficamente sicuro della piattaforma browser. Non deriva i valori da Date.now() o Math.random(). Il sistema operativo e il browser implementano la sorgente di entropia sottostante, quindi il codice JavaScript riceve byte anziché implementare una formula di numeri casuali. ToolAcre rifiuta di generare un identificatore se la sua fonte sicura è assente.
Sovrascrittura del byte 6 e del byte 8: come il nibble della versione diventa 4 e i bit della variante diventano 10xx e perché vengono persi solo sei bit
RFC 9562 descrive una versione nibble e un campo variante. Iniziando con sedici byte casuali, imposta i quattro bit più alti del byte 6 sul binario 0100 (versione 4) e imposta i due bit più alti del byte 8 su 10 (la variante standard). L'implementazione utilizza (byte6 & 0x0f) | 0x40 e (byte8 e 0x3f) | 0x80. Sei bit vengono sovrascritti, lasciando 122 bit casuali nello schema UUIDv4. Quei bit costanti non rendono i byte rimanenti meno casuali.
Dai byte a 8-4-4-4-12: codifica esadecimale, output in minuscolo e posizionamento del trattino come li definisce lo standard
Codifica ogni byte esattamente come due caratteri esadecimali con uno zero iniziale quando necessario. Inserisci i trattini dopo 4, 6, 8 e 10 bytes, producendo il familiare 8-4-4-4-12 gruppi di caratteri esadecimali. Una stringa v4 valida ha un 4 all'inizio del terzo gruppo e uno tra 8, 9, aob all'inizio del quarto. La formattazione non aggiunge entropia; rende solo interoperabile il valore 128-bit sottostante con gli strumenti che prevedono il formato di testo UUID.
Esempio funzionante: un buffer 16-byte tracciato tramite mascheramento e formattazione fino alla stringa finale UUID
Tracciare i byte illustrativi 00 11 22 33 44 55 F6 77 38 99 AA BB CC DD EE FF. Il mascheramento F6 al byte 6 produce 46; il mascheramento 38 al byte 8 produce B8. Dopo la formattazione esadecimale minuscola e i trattini il risultato è 00112233-4455-4677-b899-aabbccddeeff. Questo è un esempio didattico deliberatamente fissato, non un identificatore da riutilizzare nella produzione. Generane uno nuovo per ogni oggetto reale e confronta tu stesso la versione e le posizioni delle varianti.
crypto.randomUUID() come scorciatoia con una sola chiamata: cosa fa per te il metodo più recente e dove non è disponibile
Su un'origine sicura, crypto.randomUUID() esegue la generazione e la formattazione v4 in un'unica chiamata. ToolAcre lo utilizza dove disponibile e altrimenti ricorre a getRandomValues con le operazioni bit esplicite di cui sopra. La disponibilità del browser varia in base al contesto: randomUUID è limitato a contesti protetti, mentre getRandomValues potrebbe ancora esistere su una pagina HTTP LAN. Nessuno dei due rami ricorre a Math.random semplicemente per mantenere un pulsante apparentemente funzionante.
Cosa non copre: versioni basate sul tempo (v1, v7) e sul nome (v3, v5), che richiedono input diversi rispetto ai byte casuali
Questo meccanismo non descrive gli identificatori v1 o v7 basati sul tempo, gli identificatori v3/v5 basati sul nome o i layout sperimentali v8. Gli UUID casuali hanno una probabilità di collisione molto bassa con una sana casualità, non un'assoluta impossibilità matematica di collisione. Un UUID v4 di per sé non deve essere utilizzato come controllo del controllo degli accessi o token di reimpostazione della password senza considerare la segretezza, la durata e l'autorizzazione in modo indipendente.
Conclusione: la casualità sicura è l'intero lavoro: il generatore ToolAcre UUID attinge dallo stesso browser CSPRNG, quindi ciò che copi è ciò che il tuo codice produrrebbe
La casualità sicura è il lavoro. Il generatore ToolAcre UUID utilizza CSPRNG del browser, applica i bit di versione e variante e offre un controllo di correttezza per i valori copiati. Confronta un risultato generato con l'esempio di layout in byte, quindi utilizza il nuovo output univoco solo per il ruolo effettivamente assegnato dall'applicazione.