Outils de développement · Générateur UUID
UUID Nil et Max : les deux valeurs spéciales et quand les utiliser
· Contexte
uuid flux de travail du développeur validation des données
Le UUID tout zéro Nil est dans la norme depuis 2005 et le tout-F Max UUID a rejoint 2024. Cet article explique à quoi ils servent, comment ils interagissent avec les validateurs et les erreurs de valeur sentinelle à éviter.
La ligne avec l'ID 00000000-0000-0000-0000-000000000000 — comment un espace réservé devient un bug de production
Une ligne dont l'identifiant est 00000000-0000-0000-0000-000000000000 peut avoir la forme de UUID tout en ayant une signification différente de celle d'un identifiant généré. Si une application utilise discrètement cette valeur pour « pas encore attribué », chaque ligne inachevée partage le même marqueur. Le code qui suppose tous les noms UUID acceptés qu'un objet réel peut alors demander, mettre en cache ou rejoindre sur l'espace réservé comme s'il s'agissait d'une clé ordinaire. Le format visible ne communique pas la règle métier ; seul un contrat sentinelle explicite le fait.
Le bug de production commence lorsqu'une couche connaît l'espace réservé et une autre non. Un formulaire peut soumettre Nil, une API peut l'accepter et une couche de persistance peut le stocker, tandis qu'un travailleur en aval traite chaque chaîne non nulle comme une clé étrangère utilisable. L’échec n’est pas que Nil soit mal formé. ToolAcre le reconnaît délibérément. L’échec permet au « texte valide », à l’« identifiant généré » et à la « relation attribuée » de s’effondrer en une seule condition non vérifiée.
Le Nil UUID — sa définition et pourquoi chaque vérification de version et de variante échoue techniquement
Dans l'implémentation vérifiée, Nil est la chaîne canonique composée uniquement de zéros. Il reçoit une branche dédiée avant que le modèle UUID normal ne soit testé, donc isValidUuid renvoie true même si l'expression régulière nécessite un chiffre de version de 1 à 8 et un quartet de variante RFC de 8 à b. inspectUuid suit la même exception : il signale une valeur valide, attribue la version 0 et indique que le UUID est entièrement composé de zéro bit et n'est pas aléatoire. Il s’agit d’un comportement d’application vérifié, et non d’une affirmation générale selon laquelle chaque validateur doit faire le même choix.
Cette branche est importante car Nil ne transmet pas la route ordinaire de version et de variante utilisée pour les identifiants générés. Une valeur ToolAcre version-4 porte 4 dans la position de version et l'un des 8, 9, a ou b dans la position de variante ; Nil porte zéro aux deux endroits. Qualifier ces contrôles d’« échec » sans mentionner l’exception serait trompeur. Le vérificateur reconnaît d'abord la valeur spéciale, puis contourne le modèle ordinaire par conception. Les consommateurs ont besoin d’une commande tout aussi visible s’ils l’acceptent.
Le Nil UUID est une exception valide explicite dans ToolAcre, signalée comme version 0
La chaîne all-f ffffffff-ffff-ffff-ffff-ffffffffffff ne reçoit aucune branche spéciale dans ce référentiel. Il échoue également au modèle normal car f est en dehors de la plage de versions acceptée et en dehors de l'ensemble de quartets de variantes RFC accepté. Par conséquent, ToolAcre le signale comme non canonique plutôt que de le traiter comme Nil. Le classeur attribue à Max un historique de normalisation et un objectif de limite de plage, mais ni l'enregistrement de l'outil, ni l'implémentation, ni les tests ne vérifient ces affirmations, donc cet article ne les répète pas.
Cette différence est plus utile qu'un historique non pris en charge : Nil est une constante nommée avec un comportement testé, tandis que Max est une entrée rejetée par le vérificateur. Un projet peut définir une sémantique sentinelle supplémentaire dans son propre protocole, mais ce choix ne doit pas être déduit de ToolAcre. Si l'interopérabilité dépend de l'acceptation d'une valeur all-f, documentez cette règle et testez-la dans le système propriétaire. Ne présumez pas que chaque bibliothèque classera une chaîne en forme de UUID de la même manière.
La valeur all-f Max est rejetée par ToolAcre ; aucun historique RFC ou utilisation prévue de la plage n'est affirmé
Une sentinelle et une valeur nulle répondent à des questions différentes uniquement lorsque le schéma l'indique. Null peut représenter directement l’absence de relation. Une sentinelle maintient la colonne remplie et peut être utile lorsqu'une interface environnante ne peut pas transporter null, mais elle crée une valeur qui ressemble à des données et par conséquent parcourt les index, les jointures, les sérialiseurs et les caches. L'apparente commodité confère une responsabilité à chaque lecteur : chacun doit se rappeler qu'un UUID accepté ne nomme pas une entité assignée.
Ce commerce devient un piège lorsque la sentinelle peut satisfaire à une vérification de forme de clé étrangère sans satisfaire le sens de la relation. Il peut également brouiller des états distincts tels qu'inconnu, intentionnellement non attribué, supprimé ou pas encore traité. Si ces états affectent le comportement, représentez-les explicitement plutôt que de surcharger un identifiant magique. Lorsque Nil est retenu pour des raisons de compatibilité, donnez à l'État une signification documentée, rejetez-le partout ailleurs et convertissez-le selon une limite clairement définie au lieu de disperser les comparaisons dans le code commercial.
Validateurs et valeurs spéciales : pourquoi une vérification stricte de la version/variant peut rejeter Nil et Max, et comment décider si la vôtre doit le faire
ToolAcre présente deux couches à l'intérieur d'un validateur. L'entrée normale est coupée, les accolades extérieures facultatives sont supprimées et la chaîne restante est vérifiée par rapport à la disposition canonique 8-4-4-4-12 ainsi que les positions de version et de variante acceptées. Nil est testé avant ce modèle et accepté délibérément. Max n'a aucune exception et échoue. Cela signifie qu'un appelant ne peut pas prédire la politique de valeur spéciale à partir de la seule expression régulière ; le flux de contrôle entourant le modèle fait partie du contrat de validation.
Concevez votre propre politique en séparant trois questions. Premièrement, le texte est-il reconnaissable sous les formes permises par vos limites ? Deuxièmement, la valeur est-elle un UUID ordinaire ou une exception nommée ? Troisièmement, cette catégorie est-elle autorisée pour ce domaine et cette opération ? Un point de terminaison de création peut rejeter Nil même lorsqu'un analyseur de diagnostic le reconnaît, tandis qu'une limite d'importation peut traduire un marqueur Nil hérité documenté en null. Le renvoi de ces résultats séparément empêche « l'analyseur l'a accepté » de devenir une autorisation accidentelle de le stocker.
ToolAcre accepte explicitement Nil et rejette Max selon son modèle de version et de variante
Considérez une table de tâches avec un identifiant de responsable qui utilise Nil pour « non affecté ». Une requête écrite comme WHERE assignee_id IS NOT NULL apparaît pour sélectionner les tâches assignées, mais elle sélectionne également chaque ligne Nil car la sentinelle est une chaîne concrète. Une jointure peut alors supprimer ces lignes si aucun utilisateur ne possède cette clé, produisant un deuxième résultat moins évident. Les deux requêtes sont localement raisonnables ; ils ne sont pas d'accord parce que le schéma a caché l'état dans un identifiant d'apparence ordinaire au lieu d'exposer directement l'affectation.
La solution durable consiste à modéliser l'affectation comme une affectation : utiliser une relation nullable lorsque le contrat de stockage le permet, ou ajouter un statut explicite lorsque plusieurs états doivent être distingués. Si une limite de compatibilité envoie toujours Nil, traduisez-la une fois avant la persistance et inversez le mappage uniquement pour cette limite. Testez ensuite les valeurs de version-4 générées, Nil, Max, l'entrée vide et le texte mal formé dans des cas distincts. L'application doit décider de chaque résultat plutôt que d'hériter de la réponse renvoyée par une vérification de format générique.
À retenir : les valeurs spéciales nécessitent une gestion explicite – générez de vrais identifiants avec le générateur ToolAcre et traitez Nil et Max comme des exceptions délibérées
Les valeurs spéciales nécessitent une gestion nommée car leur forme ne peut pas contenir l'intention de votre application. ToolAcre génère des UUID version-4 ordinaires à partir de Web Crypto, en revenant de randomUUID à getRandomValues si nécessaire et en refusant d'utiliser une source aléatoire non sécurisée. Son inspecteur peut alors distinguer une valeur générée de l'exception Nil explicitement reconnue. Cela rend l'outil utile pour l'observation, mais il ne choisit pas une politique de base de données sentinelle ni ne prouve qu'un identifiant accepté appartient à un enregistrement existant.
Utilisez le générateur pour de nouveaux identifiants et traitez chaque sentinelle comme une décision protocolaire distincte. Dans le vérificateur actuel, Nil est valide, version 0, et non aléatoire ; Max est rejeté. Conservez cette distinction lorsque vous testez la page, puis comparez-la avec les règles de votre langage, de votre base de données et de votre API avant d'accepter l'une ou l'autre valeur. La sécurité à retenir est délibérément étroite : les identifiants générés, les exceptions de l'analyseur, les relations manquantes et les états métier sont des concepts différents, et des limites robustes les maintiennent différents.