GUID vs UUID : quelle est la différence ?

GUID et UUID décrivent généralement le même type d'identifiant : une valeur 128 bits conçue pour être unique sans demander à un compteur central le numéro suivant. Les mots proviennent de différentes traditions de dénomination. UUID est le terme standard, tandis que GUID est particulièrement courant dans les logiciels et outils de développement Microsoft.

Cette réponse courte est utile, mais elle ne résout pas toutes les questions pratiques. Deux identifiants peuvent partager le familier 8-4-4-4-12 forme du texte et utilise toujours différentes versions UUID, règles de génération, comportement de classement ou conventions de sérialisation binaire. Lorsqu'une colonne de base de données, une API ou une application indique GUID, l'approche la plus sûre consiste à confirmer le format et la version acceptés plutôt que de se fier uniquement à l'étiquette.

Utilisez le ClockTools GUID Générateur lorsque vous avez besoin de valeurs UUID v4 ou UUID v7 générées par le navigateur, d'une sortie groupée, d'une validation ou d'un formatage prêt à l'exportation. Les étapes de génération et de validation s'exécutent localement dans le navigateur.

GUID vs UUID : sont-ils identiques ?

Dans la plupart des travaux de développement quotidiens, GUID et UUID sont des noms interchangeables pour un identifiant 128-bit. La norme actuelle de l'IETF, RFC9562, note explicitement que les UUID sont également connus comme des identifiants globalement uniques. Une valeur telle que 550e8400-e29b-41d4-a716-446655440000 peut donc être appelé soit un UUID, soit un GUID sans changer ses caractères.

La distinction importante est entre un nom et un schéma de génération. Appeler une valeur a GUID ne vous indique pas s'il s'agit de la version 4, de la version 7, d'une ancienne version temporelle ou d'une construction spécifique à la plate-forme. L'appeler UUID ne garantit pas qu'une application accepte toutes les versions standardisées. L'étiquette identifie le type de données général ; la version et le contrat environnant identifient le comportement de la valeur.

C'est pourquoi une comparaison GUID vs UUID devrait moins se concentrer sur le mot « correct » et davantage sur la configuration système requise derrière le mot.

Pourquoi y a-t-il deux noms ?

UUID signifie identifiant universellement unique. C'est la terminologie utilisée par les normes de l'IETF qui définit la mise en page, les variantes, les versions, la représentation du texte et les considérations de génération. GUID signifie identifiant unique au monde et s'est profondément implanté sur les plateformes Microsoft. Le Type .NET `System.Guid` est un exemple familier.

Les deux noms ont survécu parce que les écosystèmes logiciels conservent leur vocabulaire par souci de compatibilité. Une API Microsoft peut exposer un Guide, un schéma PostgreSQL peut utiliser un uuide colonne, et une API JSON peut appeler le champ identifiant. Tous les trois peuvent porter la même valeur de texte canonique.

Il n'est pas nécessaire de renommer chaque champ GUID en UUID simplement pour des raisons de terminologie. Il est nécessaire de documenter la version acceptée, de savoir si la casse est importante, si les accolades sont acceptées et comment la valeur est sérialisée lorsqu'elle traverse les limites du système.

À quoi ressemble un UUID ?

Le formulaire commun lisible par l'homme contient 32 chiffres hexadécimaux séparés en cinq groupes :

```texte

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

```

Les longueurs de groupe sont 8, 4, 4, 4 et 12. Comprenant quatre tirets, la chaîne canonique comporte 36 caractères. M indique la version nibble dans les mises en page couvertes par la norme, tandis que les bits représentés par N identifier la variante. Par exemple, le 4 dans 550e8400-e29b-41d4-a716-446655440000 identifie UUID version 4.

La casse hexadécimale ne modifie pas la valeur numérique. A716 et a716 représentent les mêmes bits. Des traits d'union, des accolades, un urne:uuid: un préfixe ou une forme compacte peuvent modifier la chaîne acceptée par un analyseur, mais ils ne modifient pas nécessairement l'identifiant sous-jacent. C'est l'une des raisons pour lesquelles ClockTools sépare la génération du formatage.

En quoi UUID v4 et UUID v7 diffèrent-ils ?

UUID v4 est la version aléatoire largement utilisée. La plupart de ses bits disponibles sont remplis à partir d'une source aléatoire ou pseudo-aléatoire, les bits requis étant définis pour la version et la variante. Cela fonctionne bien lorsque les identifiants ne doivent pas révéler l'ordre de création et lorsque la génération s'effectue indépendamment entre de nombreux clients ou services.

UUID v7 est commandé dans le temps. Ses premiers bits 48 portent un horodatage d'époque Unix en millisecondes, suivi de la version, de la variante et des données aléatoires. Les valeurs générées ultérieurement sont généralement triées après les valeurs générées précédemment. Cela peut être plus convivial pour les index et les journaux ordonnés, car les nouveaux enregistrements sont moins susceptibles d'arriver à des positions non liées dans l'espace clé.

Le temps ordonné ne signifie pas parfaitement séquentiel. Plusieurs valeurs UUID v7 créées dans la même milliseconde nécessitent toujours des données supplémentaires pour rester distinctes, et le comportement de l'horloge est important. Cela ne signifie pas non plus secret : une valeur v7 expose le temps de création approximatif de par sa conception. La RFC 9562 contient les présentations normatives et les conseils de génération pour les deux versions.

Quelle version choisir ?

Choisissez la version qui correspond au système de réception et au comportement dont vous avez besoin.

Ne changez pas de version uniquement parce que l’une d’elles semble plus récente. Vérifiez d'abord votre pilote de base de données, votre bibliothèque de validation, votre schéma API et vos consommateurs en aval. Un validateur écrit il y a des années peut rejeter une valeur v7 valide car il ne reconnaît que les anciennes versions.

Le même UUID peut-il être différent ?

Oui. Les mêmes bits 128 sous-jacents peuvent être présentés sous forme standard de minuscules, majuscules, accolades, texte cité, hexadécimal compact ou URN. ClockTools peut également regrouper les valeurs générées sous forme de lignes, CSV, JSON ou sortie compatible SQL. Ce sont des choix de représentation, pas de nouveaux identifiants.

L'échange binaire mérite plus d'attention. Certaines API de plate-forme exposent historiquement les champs GUID ou les tableaux d'octets dans un ordre qui diffère de l'ordre des octets du réseau décrit par les spécifications modernes UUID. Un aller-retour de chaîne peut sembler correct, alors qu'un aller-retour brut de 16 octets ne l'est pas. Lorsque les systèmes échangent des UUID binaires, documentez l'ordre des octets et testez par rapport à une valeur connue au lieu de supposer que chaque bibliothèque est sérialisée de manière identique.

Pour les chaînes de requête d'URL ou les segments de chemin, utilisez la forme canonique lorsque cela est possible. Si une valeur environnante doit s'échapper, la ClockTools Encodeur d'URL peut encoder le paramètre complet sans modifier l'identifiant lui-même.

Comment devez-vous stocker les GUID et UUID ?

Préférez le type UUID natif ou identifiant unique d'une base de données lorsqu'il est disponible et pris en charge par vos outils. Un type natif valide la forme et stocke normalement la valeur 128 bits de manière plus compacte qu'une colonne de texte 36 caractères. Cela peut également rendre l'intention plus claire pour les lecteurs de schéma.

Le stockage de texte reste raisonnable lorsqu'un système ne dispose pas d'un type natif ou lorsque la compatibilité nécessite une chaîne. Dans ce cas, normalisez une représentation, définissez la longueur autorisée et évitez de mélanger des accolades, des URN, des majuscules et des valeurs compactes dans la même colonne. Un formatage cohérent simplifie les contrôles d’égalité, les exportations et le travail de support.

Le comportement de l'index dépend de la base de données, de la charge de travail, du modèle d'insertion et de la conception de l'index. UUID v7 peut améliorer la localité pour certaines charges de travail de clé primaire lourdes en ajout, mais il ne s'agit pas d'une garantie de performances universelle. Mesurez avec votre propre base de données et des données réalistes. Conservez la signification commerciale dans des colonnes séparées ; un identifiant ne doit pas remplacer un horodatage de création, un numéro de client ou une règle de contrôle d'accès.

Comment ClockTools peut-il les générer et les valider ?

Le générateur GUID et UUID en ligne offre un flux de travail ciblé :

1. Sélectionnez UUID v4 pour les identifiants aléatoires ou UUID v7 pour les identifiants chronologiques.

2. Choisissez une quantité comprise entre 1 et 1,000.

3. Sélectionnez le formatage standard, majuscules, accolades, entre guillemets, compact ou URN.

4. Choisissez l'encodage plain, Base64, Base64URL ou URL lorsque la destination l'exige.

5. Exportez sous forme de lignes, CSV, JSON ou SQL, ou copiez directement les résultats.

6. Collez une valeur existante dans le validateur pour inspecter sa forme normalisée, sa version, sa variante et ses valeurs spéciales reconnues.

La génération utilise la source aléatoire cryptographique du navigateur. UUID v4 définit la version requise et les bits de variante. UUID v7 combine la valeur en millisecondes de l'époque Unix actuelle avec des données aléatoires et les bits de disposition requis. La page n'a pas besoin de télécharger les identifiants générés pour ces opérations.

Lorsque vous comparez deux listes exportées, utilisez l'option Vérificateur de différences de texte pour repérer une entrée manquante, répétée ou reformatée sans analyser chaque ligne manuellement.

Quelles erreurs faut-il éviter ?

La première erreur consiste à traiter le terme « unique » comme « impossible à entrer en collision ». Les conceptions UUID rendent les collisions accidentelles extrêmement improbables lorsqu'elles sont générées correctement, mais le logiciel doit toujours utiliser une contrainte d'unicité où les doublons seraient nuisibles. Une source aléatoire cassée, un appareil copié, une erreur d'importation ou un bug d'application peuvent créer un doublon même lorsque les mathématiques sont valables.

La deuxième erreur consiste à utiliser un UUID comme preuve d'autorisation. Un identifiant difficile à deviner peut réduire les découvertes occasionnelles, mais il n’accorde pas à lui seul une autorisation en toute sécurité. Vérifiez l'accès de l'utilisateur authentifié sur chaque demande protégée.

La troisième erreur consiste à changer silencieusement la représentation. La suppression des traits d'union, le décodage de Base64 ou la conversion en octets doivent être réversibles et testés. Conservez une valeur canonique dans les journaux afin que les opérateurs puissent la retracer entre les services. Si un analyseur rejette un identifiant, validez la version et le format avant de générer un remplacement ; le remplacement d'un identifiant peut briser les références qui y pointent déjà.