Strumenti per sviluppatori · Generatore UUID
Cosa rende una stringa UUID ben formata e cosa non può sapere un controllore
· Come funziona
uuid crittografia API del browser
Maiuscole, parentesi graffe, urna: prefissi e trattini mancanti compaiono tutti nell'input reale. Questo post definisce la forma canonica, mostra ciò che un validatore indulgente dovrebbe accettare e separa la buona forma dall'esistenza.
Il 400 che avrebbe dovuto essere un 404: quanto la convalida sciatta di UUID produce errori API confusi
Un endpoint API riceve un identificatore da un client: {12345678-90AB-CDEF-1234-567890ABCDEF}. Il codice di convalida controlla se corrisponde a /[0-9a-f]{32}/ e lo rifiuta come non valido. Il client riceve una richiesta 400 errata laddove si intendeva 404 Non trovato. L'identificatore è ben formato (è un UUID valido in formato tra parentesi graffe) ma il validatore è troppo rigido. Al contrario, un endpoint che accetta qualsiasi stringa esadecimale di 32 caratteri (senza trattini) accetterà 123456789012345678901234567890123456, la analizzerà come valida e non terrà conto dell'errore di battitura. RFC 9562 definisce la rappresentazione testuale canonica, ma l'input del mondo reale arriva in cinque formati diversi e un validatore che accetta solo la forma canonica rifiuterà il 1 fino al 5 percento dell'input ben intenzionato.
La forma testuale canonica: 32 cifre esadecimali minuscole in 8-4-4-4-12, esattamente 36 caratteri, come specificato dallo standard per l'output
La forma testuale canonica è costituita da 32 cifre esadecimali minuscole divise in cinque gruppi separati da trattini: 8-4-4-4-12. Rappresentato come 550e8400-e29b-41d4-a716-446655440000. Lo standard richiede la scrittura in minuscolo per l'output; all'input, si consiglia la corrispondenza senza distinzione tra maiuscole e minuscole. Questo modulo non è ambiguo, viene analizzato in byte allo stesso modo su ogni piattaforma ed è ciò che ogni libreria UUID restituisce per impostazione predefinita. Se stai generando un nuovo UUID da un CSPRNG, la forma canonica è ciò che dovresti produrre e ciò che ToolAcre produce. Gli input del mondo reale si discostano in modi prevedibili. Gli identificatori maiuscoli (550E8400-E29B-41D4-A716-446655440000) sono comuni nei sistemi che utilizzano per impostazione predefinita il maiuscolo; rappresentano gli stessi byte e dovrebbero essere accettati dopo la normalizzazione in minuscolo.
Varianti che incontrerai in natura: esadecimale maiuscolo, {braces}, il prefisso urn:uuid: e forme senza trattino 32-caratteri e che lo standard dice di accettare
La forma tra parentesi graffe ({550e8400-e29b-41d4-a716-446655440000}) è l'output standard del modulo uuid di Python e dei sistemi Microsoft; togliendo le parentesi graffe si ottiene una forma canonica valida. Il prefisso URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) è definito da RFC 8141 per nomi di risorse uniformi; la rimozione dello schema e del prefisso identificativo di eliminazione lascia la forma canonica. La forma senza trattino (550e8400e29b41d4a716446655440000) è composta da 32 cifre esadecimali senza struttura; sono byte validi ma perde il 8-4-4-4-12 raggruppamento che rende leggibili le versioni e le varianti. Tutte queste varianti sono mappate allo stesso valore 128bit. RFC 9562 la sezione 3 afferma che in input vengono accettate le varianti maiuscole SHOULD. Non vieta altre varianti; dice che in output deve essere utilizzata la forma canonica minuscola MUST.
Validità della versione e della variante: se rifiutare un UUID il cui terzo gruppo inizia con 0 o il cui quarto gruppo inizia con f
Un validatore ben formato dovrebbe: accettare la forma canonica 8-4-4-4-12 in minuscolo o maiuscolo; accettare le varianti tra parentesi graffe e urna: rimuovendole e convalidando la forma principale; accettare stringhe esadecimali di 32 cifre senza trattino e formattarle come canoniche per il confronto; rifiutare stringhe con un numero errato di cifre esadecimali o caratteri non esadecimali. L'errore più comune è rifiutare l'input in maiuscolo o tra parentesi graffe perché il validatore è stato scritto a mano per corrispondere solo alla forma canonica. Un controllo di integrità sulla versione e sulla variante può rilevare errori di battitura. Se il terzo gruppo inizia con 0 o 9, UUID non è valido o riservato; se il quarto gruppo inizia con eof, la variante non è RFC 9562.
Esempio pratico: sei stringhe candidate vengono sottoposte a un controllo rigoroso e uno indulgente, con le ragioni per cui ciascuna passa o fallisce
Un validatore indulgente accetta questi valori; un validatore rigoroso può rifiutarli. Il controllo ben formato ToolAcre esegue una convalida rigorosa: conferma la forma canonica del carattere 36 con trattini nei punti giusti, verifica le cifre esadecimali in ogni posizione e controlla che i bit della versione e della variante siano nell'intervallo. Non controlla che UUID esista nel tuo database o che sia stato generato da una fonte crittograficamente sicura; questi sono controlli separati eseguiti dalla logica dell'applicazione. Ben formato non è la stessa cosa di reale. Una stringa UUID analizzata correttamente in base alla sua forma potrebbe non identificare alcuna riga nel database.
Ben formato non è reale: perché un UUID sintatticamente perfetto potrebbe non esistere nei tuoi dati e perché il controllore non dovrebbe mai essere il tuo livello di autorizzazione
UN UUID formato perfettamente potrebbe essere stato indovinato o copiato e incollato in modo errato. La convalida del formato è il primo cancello; i controlli di esistenza e i controlli di autorizzazione sono il secondo e il terzo. Eseguire una ricerca nel database per ogni input con formato non valido è uno spreco; rifiutare input con formato non valido prima delle query sul database consente di risparmiare tempo. IL ToolAcre uscite del generatore standard 36-UUID dei caratteri; se stai costruendo il tuo validatore, accetta le varianti tra parentesi graffe e urna: per corrispondere all'input del mondo reale e rifiuta le stringhe che non soddisfano le regole di forma di base prima di chiedere al tuo database. L'implementazione di un validatore rigoroso richiede espressioni regolari e gestione dei casi limite. La forma canonica è semplice: /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i (senza distinzione tra maiuscole e minuscole). La forma tra parentesi aggiunge parentesi graffe: /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. La variante urn: aggiunge uno schema: /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
Cosa non copre: la normalizzazione degli ID per l'archiviazione e la scelta di un tipo di colonna, che sono decisioni separate
Una singola espressione regolare che gestisce tutte le varianti è meno leggibile ma possibile. La maggior parte dei validatori normalizza prima: togli le parentesi graffe e l'urna: prefisso, converti in minuscolo, quindi abbina il modello canonico. I bit della versione e della variante possono essere controllati dopo la corrispondenza del modello esaminando la posizione 14 e la posizione 19 come descritto nell'articolo 403. Gestire con garbo l'input non valido fa parte della progettazione della convalida. Quando un client invia un UUID non valido, non esporre il modello regex o le regole di convalida interne nel messaggio di errore. Restituisce un errore chiaro: "Formato UUID non valido. Previsto formato 8-4-4-4-12, ad esempio 550e8400-e29b-41d4-a716-446655440000 " Non tentare di correggere l'input; chiedere al cliente di inviare nuovamente.
Conclusione: convalida la forma in anticipo, cerca l'esistenza separatamente: il controllo ToolAcre conferma la forma nel browser prima di toccare un database
Alcuni sistemi registrano input non validi per il controllo di sicurezza (rilevando tentativi di injection o attacchi di confusione di formato). Il validatore ToolAcre rifiuta i moduli non canonici con un messaggio di errore chiaro e non tenta la correzione automatica. Perché la forma canonica è importante per l'interoperabilità: se un sistema memorizza gli UUID come esadecimali senza trattino e un altro li memorizza come canonici 8-4-4-4-12, confrontarli per l'uguaglianza richiede la normalizzazione. Maiuscolo e minuscolo richiedono un confronto senza distinzione tra maiuscole e minuscole. Rinforzato o nudo richiede lo spogliamento. Queste variazioni rendono più difficili le operazioni di massa (importazioni, migrazioni, confronti). Gli strumenti standard che producono una forma canonica riducono l'attrito. Il generatore ToolAcre restituisce sempre la forma canonica minuscola di 36 caratteri; quando importi UUID da altri sistemi, normalizzali in questo formato nel tuo processo ETL per garantire la coerenza.