Outils de développement · Générateur UUID
Qu'est-ce qui fait qu'une chaîne UUID est bien formée et ce qu'un vérificateur ne peut pas savoir
· Comment ça marche
uuid cryptographie API du navigateur
Majuscules, accolades, urne : les préfixes et les traits d'union manquants apparaissent tous dans la saisie réelle. Cet article définit la forme canonique, montre ce qu'un validateur indulgent devrait accepter et sépare la bonne formation de l'existence.
Le 400 qui aurait dû être un 404 — comment une validation bâclée de UUID produit des erreurs d'API déroutantes
Un point de terminaison d'API reçoit un identifiant d'un client : {12345678-90AB-CDEF-1234-567890ABCDEF}. Le code de validation vérifie s'il correspond à /[0-9a-f]{32}/ et le rejette comme invalide. Le client reçoit une requête incorrecte 400 alors qu'il s'agissait de 404 Not Found. L'identifiant est bien formé (il s'agit d'un UUID valide au format entre accolades) mais le validateur est trop strict. À l’inverse, un point de terminaison qui accepte toute chaîne hexadécimale de caractères 32 (sans tirets) acceptera 123456789012345678901234567890123456, l’analysera comme valide et manquera la faute de frappe. La RFC 9562 définit la représentation textuelle canonique, mais les entrées du monde réel arrivent dans cinq formats différents, et un validateur qui n'accepte que la forme canonique rejettera 1 à 5 pour cent des entrées bien intentionnées.
La forme textuelle canonique — 32 chiffres hexadécimaux minuscules en 8-4-4-4-12, exactement 36 caractères, comme le spécifie la norme pour la sortie
La forme textuelle canonique est constituée de 32 chiffres hexadécimaux minuscules répartis en cinq groupes séparés par des tirets : 8-4-4-4-12. Représenté par 550e8400-e29b-41d4-a716-446655440000. La norme impose des minuscules pour la sortie ; en entrée, une correspondance insensible à la casse est recommandée. Ce formulaire est sans ambiguïté, analyse en octets de la même manière sur chaque plate-forme et correspond à ce que chaque bibliothèque UUID génère par défaut. Si vous générez un nouveau UUID à partir d'un CSPRNG, la forme canonique est ce que vous devez produire et ce que ToolAcre produit. Les données du monde réel s'écartent de manière prévisible. Les identifiants en majuscules (550E8400-E29B-41D4-A716-446655440000) sont courants sur les systèmes qui sont par défaut en majuscules ; ils représentent les mêmes octets et doivent être acceptés après normalisation en minuscules.
Variantes courantes — hexadécimal en majuscules, {braces}, préfixe urn:uuid: et formes de 32 caractères sans traits d’union, ainsi que celles que la norme demande d’accepter.
La forme entre accolades ({550e8400-e29b-41d4-a716-446655440000}) est la sortie standard du module uuid de Python et des systèmes Microsoft ; supprimer les accolades donne une forme canonique valide. Le préfixe URN (urn:uuid:550e8400-e29b-41d4-a716-446655440000) est défini par RFC 8141 pour les noms de ressources uniformes ; la suppression du schéma et du préfixe d'identification de suppression laisse la forme canonique. La forme sans trait d'union (550e8400e29b41d4a716446655440000) est constituée de 32 chiffres hexadécimaux sans structure ; il s'agit d'octets valides mais perd le regroupement 8-4-4-4-12 qui rend les versions et variantes lisibles. Ces variantes correspondent toutes à la même valeur 128 bits. La section 3 de la RFC 9562 indique qu'en entrée, les variantes majuscules DEVRAIENT être acceptées. Elle n'interdit pas d'autres variantes ; il indique qu'en sortie, la forme canonique minuscule DOIT être utilisée.
Intégrité des versions et des variantes : s'il faut rejeter un UUID dont le troisième groupe commence par 0 ou dont le quatrième groupe commence par f
Un validateur bien formé doit : accepter la forme canonique 8-4-4-4-12 en minuscules ou en majuscules ; accepter les variantes contreventées et urnes : en les supprimant et en validant la forme de base ; accepter les chaînes hexadécimales de 32 chiffres sans trait d'union et les formater comme canoniques à des fins de comparaison ; rejeter les chaînes contenant un nombre incorrect de chiffres hexadécimaux ou de caractères non hexadécimaux. L'erreur la plus courante consiste à rejeter les entrées en majuscules ou entre accolades, car le validateur a été écrit à la main pour correspondre uniquement à la forme canonique. Une vérification de l'intégrité de la version et de la variante peut détecter des fautes de frappe. Si le troisième groupe commence par 0 ou 9, l'UUID est invalide ou réservé ; si le quatrième groupe commence par e ou f, la variante n'est pas la RFC 9562.
Exemple concret : six chaînes candidates sont soumises à une vérification stricte et à une vérification clémente, avec les raisons pour lesquelles chacune réussit ou échoue.
Un validateur indulgent accepte ces valeurs ; un validateur strict peut les rejeter. La vérification bien formée de ToolAcre effectue une validation stricte : elle confirme la forme canonique du caractère 36 avec des tirets aux bons endroits, vérifie les chiffres hexadécimaux dans chaque position et vérifie que la version et les bits de variante sont dans la plage. Il ne vérifie pas que le UUID existe dans votre base de données ou qu'il a été généré à partir d'une source cryptographiquement sécurisée ; ce sont des vérifications distinctes effectuées par la logique de votre application. Bien formé n’est pas la même chose que réel. Une chaîne UUID qui est analysée correctement en fonction de sa forme peut n'identifier aucune ligne dans votre base de données.
Bien formé n'est pas réel - pourquoi un UUID syntaxiquement parfait peut ne pas exister dans vos données et pourquoi le vérificateur ne devrait jamais être votre couche d'autorisation
Un UUID parfaitement formé a peut-être été deviné ou copié de manière incorrecte. La validation du format est la première porte ; les contrôles d'existence et les contrôles d'autorisation sont les deuxième et troisième. Exécuter une recherche dans la base de données pour chaque entrée dont le format n'est pas valide est un gaspillage ; le rejet des entrées dont le format n'est pas valide avant les requêtes de base de données permet de gagner du temps. Le générateur ToolAcre génère des UUID standard à 36 caractères ; si vous créez votre propre validateur, acceptez les variantes accolades et urn: pour correspondre aux entrées du monde réel et rejetez les chaînes qui ne respectent pas les règles de forme de base avant de demander à votre base de données. L'implémentation d'un validateur strict nécessite des expressions régulières et une gestion des cas extrêmes. La forme canonique est simple : /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i (insensible à la casse). La forme entre accolades ajoute des accolades : /^\{[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\}$/i. La variante urn : ajoute un schéma : /^urn:uuid:[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i.
Ce que cela ne couvre pas : normaliser les identifiants pour le stockage et choisir un type de colonne, qui sont des décisions distinctes
Une seule expression régulière qui gère toutes les variantes est moins lisible mais possible. La plupart des validateurs normalisent d'abord : supprimez les accolades et l'urne : préfixe, convertissez en minuscules, puis faites correspondre le modèle canonique. Les bits de version et de variante peuvent être vérifiés après la correspondance de modèle en examinant la position 14 et la position 19 comme décrit dans l'article 403. La gestion gracieuse des entrées non valides fait partie de la conception de la validation. Lorsqu'un client soumet un UUID mal formé, n'exposez pas le modèle d'expression régulière ou les règles de validation internes dans le message d'erreur. Renvoie une erreur claire : "Format UUID non valide. Format 8-4-4-4-12 attendu, tel que 550e8400-e29b-41d4-a716-446655440000. " N'essayez pas de corriger la saisie ; demander au client de soumettre à nouveau.
À retenir : validez la forme tôt, recherchez l'existence séparément - la vérification ToolAcre confirme la forme dans le navigateur avant de toucher une base de données
Certains systèmes enregistrent les entrées non valides pour l'audit de sécurité (détection des tentatives d'injection ou des attaques par confusion de format). Le validateur ToolAcre rejette les formulaires non canoniques avec un message d'erreur clair et ne tente pas de correction automatique. Pourquoi la forme canonique est importante pour l'interopérabilité : si un système stocke les UUID sous forme hexadécimale sans trait d'union et qu'un autre les stocke sous forme canonique 8-4-4-4-12, leur comparaison pour l'égalité nécessite une normalisation. Les majuscules et les minuscules nécessitent une comparaison insensible à la casse. Contreventé ou nu nécessite un décapage. Ces variations rendent les opérations groupées (importations, migrations, comparaisons) plus difficiles. Les outils standard qui génèrent une forme canonique réduisent la friction. Le générateur ToolAcre génère toujours une forme canonique de 36 caractères minuscules ; lorsque vous importez des UUID à partir d'autres systèmes, normalisez-les sous cette forme dans votre processus ETL pour garantir la cohérence.