Generateur d'UUID

GUID (Globally Unique Identifier) est le nom utilisé par Microsoft pour le même concept. Les UUID et les GUID suivent la même norme RFC 4122 et sont interchangeables en format (32 chiffres hexadécimaux, 4 tirets : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx). Le terme UUID est utilisé dans la plupart des contextes de programmation ; GUID est courant dans la documentation Microsoft/.NET et SQL Server. Vous pouvez également voir des GUID formatés avec des accolades environnantes : {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} — l'outil peut également produire ce format.

Oui. L'outil utilise crypto.getRandomValues() de la Web Crypto API, qui fournit des nombres pseudo-aléatoires cryptographiquement sécurisés soutenus par la source d'entropie du système d'exploitation. Il s'agit de la même source d'aléatéité utilisée par ssh-keygen et les gestionnaires de mots de passe. Ne pas utiliser Math.random() pour la génération d'UUID en production — ce n'est pas cryptographiquement sécurisé et il a été démontré qu'il produit des résultats prévisibles dans certains moteurs JavaScript.

Pour l'UUID v4, les collisions sont théoriquement possibles mais astronomiquement improbables. Le problème des anniversaires nous indique qu'il faudrait générer environ 2,71 quintillions (2,71 × 10^18) d'UUID v4 pour atteindre une probabilité de collision de 50 %. À un rythme de 1 milliard d'UUID générés par seconde, cela prendrait 85 ans. En pratique, l'UUID v4 est considéré comme exempt de collisions pour toutes les applications pratiques. Si vous avez besoin d'une unicité garantie sans dépendre des probabilités, combinez un UUID avec une contrainte d'unicité imposée par la base de données.

Les entiers auto-incrémentés sont plus simples, plus petits (4 ou 8 octets contre 16 octets) et plus efficaces pour les index clusterisés car ils s'insèrent dans l'ordre. Les UUID ont des avantages : ils fonctionnent dans les systèmes distribués sans coordination (deux bases de données peuvent générer des ID sans communiquer entre elles), ils ne révèlent pas le nombre d'enregistrements ou l'ordre de création aux clients, et ils permettent la génération d'ID dans la couche applicative avant une écriture en base de données. L'UUID v7 offre le meilleur des deux mondes — assez aléatoire pour éviter les collisions, mais trié par horodatage pour bien s'organiser dans les index B-tree. Pour la plupart des applications, le bon choix est v7 pour les nouvelles bases de données de systèmes distribués et l'auto-incrément pour les applications simples sur un seul serveur.

Le champ variant (bits 64-65 de l'UUID) identifie quelle spécification d'UUID a été utilisée pour générer l'identifiant. La variante 1 (binaire 10) est la norme RFC 4122 — tous les UUID que vous générez avec cet outil sont de la variante 1. La variante 0 était utilisée dans le format NCS obsolète. La variante 2 était utilisée dans le format GUID de Microsoft (maintenant équivalent à la variante 1). La variante 3 est réservée. Lorsque le validateur affiche "Variant: RFC 4122", l'UUID est un identifiant conforme aux standards. Les informations de variante sont principalement pertinentes lors de l'analyse d'UUID étrangers provenant de systèmes inconnus.

Format standard avec tirets : 550e8400-e29b-41d4-a716-446655440000 (par défaut, le plus courant). Sans tirets : 550e8400e29b41d4a716446655440000 (utilisé dans certaines bases de données et API). En majuscules : 550E8400-E29B-41D4-A716-446655440000 (même valeur, affichage différent). Avec des accolades : {550e8400-e29b-41d4-a716-446655440000} (style Microsoft/COM). Tous les formats représentent la même valeur de 128 bits — seule la représentation en chaîne de caractères diffère.

Non. Toute la génération et la validation d'UUID s'exécutent dans votre navigateur à l'aide de JavaScript et de la Web Crypto API. Aucune donnée, aucun UUID généré et aucun UUID validé ne quittent votre appareil. L'outil fonctionne entièrement hors ligne une fois la page chargée.