Strumenti per sviluppatori · Generatore UUID
UUID pari a zero e massimo: i due valori speciali e quando utilizzarli
· Sfondo
uuid flusso di lavoro dello sviluppatore convalida dei dati
Il tutto zero Nil UUID è nello standard da 2005 e il tutto-F Max UUID si è unito a 2024. Questo post spiega a cosa servono, come interagiscono con i validatori e gli errori sentinella da evitare.
La riga con ID 00000000-0000-0000-0000-000000000000: come un segnaposto diventa un bug di produzione
Una riga il cui identificatore è 00000000-0000-0000-0000-000000000000 può avere la forma di UUID pur avendo un significato diverso da un identificatore generato. Se un'applicazione utilizza tranquillamente quel valore per "non ancora assegnato", ogni riga non completata condivide lo stesso indicatore. Il codice che presuppone qualsiasi nome UUID accettato da un oggetto reale può quindi richiedere, memorizzare nella cache o unirsi al segnaposto come se fosse una chiave ordinaria. Il formato visibile non comunica la regola aziendale; solo un contratto sentinella esplicito lo fa.
Il bug di produzione inizia quando un livello conosce il segnaposto e un altro no. Un modulo può inviare Nil, un API può accettarlo e un livello di persistenza può memorizzarlo, mentre un lavoratore a valle tratta ogni stringa non nulla come una chiave esterna utilizzabile. Il fallimento non è che Nil sia malformato. ToolAcre lo riconosce deliberatamente. L'errore sta consentendo al "testo valido", all'"identificatore generato" e alla "relazione assegnata" di collassare in un'unica condizione non controllata.
Il Nil UUID: la sua definizione e perché ogni controllo di versione e variante tecnicamente fallisce
Nell'implementazione verificata, Nil è la stringa canonica tutta zero. Riceve un ramo dedicato prima che venga testato il modello normale UUID, quindi isValidUuid restituisce true anche se l'espressione regolare richiede una cifra di versione da 1 a 8 e un bocconcino di variante RFC da 8 a b. inspectUuid segue la stessa eccezione: riporta un valore valido, assegna la versione 0 e dice che UUID è tutto a bit zero e non casuale. Si tratta di un comportamento verificato dell'applicazione, non di un'affermazione generale secondo cui ogni validatore deve fare la stessa scelta.
Quel ramo è importante perché Nil non passa il percorso ordinario di versione e variante utilizzato per gli identificatori generati. Un valore ToolAcre versione-4 porta 4 nella posizione della versione e uno tra 8, 9, a o b nella posizione della variante; Nil porta zero in entrambi i posti. Definire questi controlli “falliti” senza menzionare l’eccezione sarebbe fuorviante. Il controllore riconosce innanzitutto il valore speciale, quindi ignora il modello ordinario in base alla progettazione. I consumatori hanno bisogno di un ordine altrettanto visibile se lo accettano.
Il Nil UUID è un'eccezione valida esplicita in ToolAcre, segnalata come versione 0
La stringa tutta f ffffffff-ffff-ffff-ffff-ffffffffffff non riceve alcun ramo speciale in questo repository. Inoltre non rispetta il modello normale perché f è al di fuori dell'intervallo di versioni accettate e al di fuori del set di bocconcini RFC-variante accettato. Di conseguenza, ToolAcre lo segnala come non canonico anziché trattarlo come Nil. La cartella di lavoro attribuisce a Max la storia della standardizzazione e uno scopo di delimitazione dell'intervallo, ma né il record dello strumento, né l'implementazione né i test verificano tali affermazioni, quindi questo articolo non le ripete.
Questa differenza è più utile della cronologia non supportata: Nil è una costante denominata con comportamento testato, mentre Max è un input che il controllo rifiuta. Un progetto può definire una semantica sentinella aggiuntiva nel proprio protocollo, ma tale scelta non deve essere dedotta da ToolAcre. Se l'interoperabilità dipende dall'accettazione di un valore all-f, documentare tale regola e testarla nel sistema proprietario. Non dare per scontato che ogni libreria classificherà una stringa a forma di UUID in modo identico.
Il valore all-f Max viene rifiutato da ToolAcre; non viene dichiarata alcuna cronologia RFC o utilizzo del raggio d'azione previsto
Una sentinella e un valore nullo rispondono a domande diverse solo quando lo schema lo dice. Null può rappresentare direttamente l'assenza di una relazione. Una sentinella mantiene la colonna popolata e può essere utile quando un'interfaccia circostante non può contenere null, ma crea un valore che assomiglia a dati e quindi viaggia attraverso indici, join, serializzatori e cache. L'apparente comodità sposta la responsabilità in ogni lettore: ciascuno deve ricordare che un UUID accettato non nomina un'entità assegnata.
Questo scambio diventa una trappola quando la sentinella può soddisfare un controllo di forma della chiave esterna senza soddisfare il significato della relazione. Può anche offuscare stati distinti come sconosciuto, intenzionalmente non assegnato, eliminato o non ancora elaborato. Se questi stati influenzano il comportamento, rappresentateli esplicitamente anziché sovraccaricare un identificatore magico. Laddove Nil viene mantenuto per compatibilità, dare allo stato un significato documentato, rifiutarlo ovunque e convertirlo in un confine chiaramente posseduto invece di spargere confronti in tutto il codice aziendale.
Validatori e valori speciali: perché un controllo rigoroso di version/variant può rifiutare Nil e Max e come decidere se il tuo dovrebbe farlo
ToolAcre dimostra due livelli all'interno di un validatore. L'input normale viene tagliato, le parentesi graffe esterne opzionali vengono rimosse e la stringa rimanente viene confrontata con il layout canonico 8-4-4-4-12 più la versione accettata e le posizioni delle varianti. Il nulla viene testato prima di quel modello e accettato deliberatamente. Max non ha eccezioni e fallisce. Ciò significa che un chiamante non può prevedere la politica dei valori speciali solo dall'espressione regolare; il flusso di controllo che circonda il modello fa parte del contratto di validazione.
Progetta la tua politica separando tre domande. Innanzitutto, il testo è riconoscibile nelle forme consentite dal tuo confine? In secondo luogo, il valore è un UUID ordinario o un'eccezione denominata? Terzo, quella categoria è consentita per questo campo e operazione? Un endpoint di creazione potrebbe rifiutare Nil anche quando un parser diagnostico lo riconosce, mentre un confine di importazione potrebbe tradurre un marcatore Nil legacy documentato in null. Restituire questi risultati separatamente impedisce che "il parser lo abbia accettato" diventi un'autorizzazione accidentale per archiviarlo.
ToolAcre accetta Nil esplicitamente e rifiuta Max in base al modello di versione e variante
Considera una tabella delle attività con un identificatore assegnatario che utilizza Nil per "non assegnato". Una query scritta come WHEREassignee_id IS NOT NULL sembra selezionare le attività assegnate, ma seleziona anche ogni riga Nil perché la sentinella è una stringa concreta. Un join potrebbe quindi eliminare quelle righe se nessun utente dispone di quella chiave, producendo un secondo risultato meno ovvio. Entrambe le query sono ragionevoli a livello locale; non sono d'accordo perché lo schema nascondeva lo stato all'interno di un identificatore dall'aspetto ordinario invece di esporre direttamente l'assegnazione.
La soluzione duratura consiste nel modellare l'assegnazione come assegnazione: utilizzare una relazione nullable quando il contratto di archiviazione lo consente o aggiungere uno stato esplicito quando è necessario distinguere più stati. Se un confine di compatibilità invia ancora Nil, traducilo una volta prima della persistenza e inverti la mappatura solo per quel confine. Quindi testa i valori version-4 generati, Nil, Max, input vuoto e testo non valido come casi separati. L'applicazione dovrebbe decidere ciascun risultato anziché ereditare la risposta restituita da un controllo di formato generico.
Conclusione: i valori speciali richiedono una gestione esplicita: genera ID reali con il generatore ToolAcre e tratta Nil e Max come eccezioni intenzionali
I valori speciali necessitano di una gestione denominata perché la loro forma non può trasmettere l'intento dell'applicazione. ToolAcre genera UUID della versione ordinaria4 da Web Crypto, passando da randomUUID a getRandomValues quando necessario e rifiutandosi di utilizzare una fonte casuale non sicura. Il suo ispettore può quindi distinguere un valore generato dall'eccezione Nil esplicitamente riconosciuta. Ciò rende lo strumento utile per l’osservazione, ma non sceglie una politica sentinella del database né dimostra che un identificatore accettato appartiene a un record esistente.
Utilizza il generatore per nuovi identificatori e tratta ogni sentinella come una decisione di protocollo separata. Nel controllo corrente, Nil è valido, versione 0 e non casuale; Max viene rifiutato. Mantieni questa distinzione durante il test della pagina, quindi confrontala con le regole della tua lingua, del database e di API prima di accettare uno dei due valori. Il concetto di sicurezza è deliberatamente ristretto: ID generati, eccezioni del parser, relazioni mancanti e stati aziendali sono concetti diversi e confini robusti li mantengono diversi.