Outils de développement · Générateur UUID
De 128 bits à 36 caractères : comment fonctionne l'encodage de texte UUID
· Comment ça marche
uuid cryptographie API du navigateur
Un UUID fait 16 octets, mais sa forme familière est de 36 caractères. Cet article explique le doublement hexadécimal, les traits d'union, les règles de casse et les encodages plus courts que les gens utilisent lorsque le formulaire standard est trop long.
Pourquoi la colonne est plus large que la valeur – la valeur de 16 octets qui coûte 36 caractères en texte et ce que cela signifie pour les URL et le stockage
La largeur de la colonne de stockage explose lorsque vous choisissez un format UUID. Une valeur 128 bits équivaut à 16 octets, mais sa représentation textuelle dépend du codage : hexadécimal (36 caractères avec tirets, 32 sans), base64url (22 caractères), base58 (22–23 caractères), Crockford base32 (26 caractères). Si votre schéma stocke les UUID sous la forme VARCHAR(36), vous dépensez 36 caractères dans chaque ligne. Dans une table avec 1 milliards de lignes et aucune autre colonne, cela représente 36 Go de texte par rapport à 16 Go de binaire. Le choix n’est pas seulement esthétique ; cela affecte la taille des requêtes, les allers-retours sur le réseau et la pression du cache. Le format canonique est de 36 caractères : huit chiffres hexadécimaux, trait d'union, quatre chiffres hexadécimaux, trait d'union, quatre chiffres hexadécimaux, trait d'union, quatre chiffres hexadécimaux, trait d'union, douze chiffres hexadécimaux.
Hex double tout — chaque octet devient deux caractères et quatre traits d'union complètent le 36
Chaque octet devient exactement deux caractères hexadécimaux (0–9, a–f). Les traits d'union sont là pour des raisons de lisibilité et pour des raisons héritées de la première spécification des UUID. Le codage hexadécimal double le nombre d'octets : 16 octets deviennent 32 chiffres hexadécimaux plus 4 tirets. C’est l’encodage le plus lent et le plus long, mais lisible par l’homme et pris en charge partout. Règles de casse : la RFC 9562 impose les minuscules pour la sortie canonique, mais l'entrée n'est pas sensible à la casse. Le stockage des majuscules gaspille une opportunité de normalisation, alors stockez les minuscules et comparez sans tenir compte de la casse lors de l'entrée. Le codage Base64url représente trois octets sous forme de quatre caractères en utilisant un alphabet de 64 caractères (A–Z, a–z, 0–9, moins, trait de soulignement). Seize octets deviennent 21 caractères plus un caractère de remplissage, soit un total de 22 caractères. Base64url supprime le remplissage et les caractères standard (plus et barre oblique) réservés dans les URL.
Règles de casse : minuscules en sortie, insensible à la casse en entrée et raisons pour lesquelles les comparaisons de casse mixtes provoquent des incompatibilités silencieuses
Un UUID au format base64url enregistre 14 caractères par rapport à l'hexadécimal et est valide dans les URL sans codage en pourcentage. Le compromis : il est moins lisible (les lettres minuscules ressemblent à des chiffres ; b, 8, B et 8 sont faciles à confondre). Base58 est utilisé par Bitcoin et d'autres blockchains et supprime les caractères ambigus (0, O, I, l), rendant le résultat 22–23 caractères tout en restant lisible. Crockford base32 (conçu pour les formats de type ISBN avec somme de contrôle) utilise des caractères 26 et donne la priorité à l'exactitude plutôt qu'à la brièveté. L’interruption de l’ordre des octets du GUID Microsoft s’applique au stockage UUID dans certaines bases de données. RFC 9562 spécifie l'ordre des octets du réseau (big-endian) pour tous les octets. Certaines configurations Microsoft SQL Server stockent les GUID avec un ordre d'octets petit-boutiste dans les trois premiers champs.
Encodages plus courts - base64url à 22 caractères, base58 et Crockford base32, avec leurs compromis en termes de lisibilité et de sécurité du copier-coller
La même valeur 128-bit stockée en big-endian et small-endian produit des chaînes hexadécimales différentes. Un UUID 550e8400-e29b-41d4-a716-446655440000 stocké en tant que GUID Microsoft peut être récupéré sous le nom 00840e55-9be2-d441-a716-446655440000 (octets 0–3 et 4–5 et 6–7 inversés). Si votre système fait le pont entre les systèmes conformes à RFC et Microsoft, vous devez en être conscient et soit normaliser à la limite, soit documenter le format que vous utilisez dans chaque colonne. Exemple travaillé : la v4 UUID 9b2e4f1a-4f3e-4c1a-8a7d-1b2c3d4e5f60 en hexadécimal occupe 36 caractères. Sous forme de 16 octets, il s'agit de 9b 2e 4f 1a 4f 3e 4c 1a 8a 7d 1b 2c 3d 4e 5f 60. Dans base64url : divisé en morceaux de trois octets, convertissez en base64, supprimez le remplissage : my5PGk8-TBqKfRssPTRPX2A. En hexadécimal sans tirets : 9b2e4f1a4f3e4c1a8a7d1b2c3d4e5f60 (32 caractères).
Le piège de l'ordre des octets de Microsoft : comment les trois premiers champs d'un GUID sont stockés en petit-boutiste, afin que les mêmes octets puissent s'imprimer sous la forme de deux chaînes différentes.
Base64url enregistre 14 caractères ; base58 économiserait à peu près la même chose ; L'hexadécimal est la norme. Choisissez en fonction de votre cas d'utilisation : si l'identifiant apparaît dans les URL et que chaque caractère compte, utilisez base64url ; s'il apparaît dans les journaux et les interfaces utilisateur où les humains le lisent, utilisez la forme canonique hexadécimale ; si vous construisez un système blockchain ou un système distribué où la somme de contrôle est importante, utilisez base58 ou Crockford base32. Lorsque vous choisissez un type de colonne, stockez la valeur qui optimise votre modèle d'accès réel. Si vous interrogez fréquemment les UUID et avez besoin d'une correspondance insensible à la casse, stockez binaire(16) et laissez la base de données gérer la représentation. Si vous effectuez une requête par sous-chaîne (en recherchant des UUID commençant par un préfixe), l'hexadécimal est plus lisible dans la sortie de débogage.
Exemple concret : un identifiant écrit sous forme d'octets, un hexadécimal canonique et une forme abrégée, montrant chaque étape de conversion
Si vous exportez vers CSV et envoyez un e-mail à des utilisateurs non techniques, l'hexadécimal est plus reconnaissable. Si vous êtes limité en espace (application mobile avec cache local), base64url ou base58 économise de la bande passante. Le générateur ToolAcre génère un format hexadécimal canonique de caractères 36 ; si vous avez besoin d'un encodage différent, la vérification bien formée fonctionne toujours car elle normalise toute représentation valide avant de vérifier le format. Les considérations de performances sont importantes lors de l’encodage ou du décodage de millions d’UUID. Le codage hexadécimal est simple : convertissez chaque octet en deux caractères en O(1) temps par octet. Le décodage est tout aussi simple. L'encodage et le décodage Base64 utilisent des tables de recherche et sont légèrement plus lents (environ 2–3 fois plus lent que l'hexadécimal par octet, selon le matériel et l'implémentation). Base58 est nettement plus lent car il s’agit essentiellement d’une conversion de base et nécessite une arithmétique modulaire.
Ce que cela ne couvre pas : les choix de colonnes de base de données tels que les types uuid natifs par rapport aux binaires (16), traités séparément
Si votre système encode ou décode les UUID dans une boucle chaude (génération d'identifiants haute fréquence, exportation en masse), l'hexadécimal est plus rapide. Si le codage est peu fréquent et que les économies de caractères 14 sont importantes, base64url est un compromis raisonnable. Le générateur ToolAcre produit en hexadécimal, vous bénéficiez donc d'un avantage en termes de performances sans sacrifier la compatibilité. La sémantique de comparaison de chaînes diffère selon l’encodage. Les UUID hexadécimaux peuvent être comparés sous forme de chaînes : 550e8400-e29b-41d4-a716-446655440000 < 550e8400-e29b-41d4-a716-446655440001 (travaux de comparaison lexicographique). Les UUID binaires peuvent être comparés sous forme d'octets : la comparaison octet par octet est la même que la comparaison numérique. Cependant, les UUID codés en base64url et en base58 ne conservent pas l'ordre numérique dans la comparaison de chaînes lexicographiques. Si votre système repose sur le tri lexicographique des UUID (un modèle étonnamment courant pour créer des index ou des clés de base de données), vous devez utiliser soit une variante hexadécimale, binaire ou une variante triable UUID (v6 ou v7).
À retenir : conservez la forme canonique aux limites - le générateur ToolAcre génère des UUID standard de 36 caractères et sa vérification accepte les chaînes sous cette forme.
Le générateur ToolAcre produit actuellement des UUID v4, qui ne peuvent pas être triés par ordre d'encodage. L'interopérabilité nécessite une standardisation sur un seul encodage. Un système qui accepte simultanément les UUID en hexadécimal, base64 et base58 doit normaliser toutes les entrées sous une forme canonique avant le traitement. C'est possible mais cela ajoute de la complexité. Les API ou bases de données externes peuvent nécessiter un encodage spécifique : certaines API attendent urn:uuid: hex préfixé, d'autres attendent un hex sans trait d'union, d'autres encore attendent une base64url. Documentez clairement les attentes d'encodage UUID de votre système dans les contrats d'API. Le générateur ToolAcre génère toujours un hexadécimal canonique ; si vous avez besoin d'autres encodages, effectuez la conversion explicitement et documentez les compromis (espace, performances, lisibilité, tri) à l'équipe.