Générateur de GUID et UUID

UUID v4 est le choix aléatoire généraliste. Une fois les bits requis de version et de variante fixés, 122 bits restent aléatoires. C'est un bon choix par défaut pour des clients indépendants, des données de test, des identifiants publics de ressources et des systèmes qui n'ont pas besoin que l'identifiant lui-même révèle une heure.

UUID v7 place un horodatage Unix en millisecondes dans les 48 bits les plus significatifs, puis utilise des bits aléatoires pour l'espace variable restant dans cette implémentation. Les valeurs de millisecondes différentes se trient ainsi globalement par heure de création lorsque les horloges avancent, ce qui peut aider l'analyse de journaux et certains modèles d'index.

La version 7 ne promet pas un ordre strict de génération. Ce générateur n'ajoute pas de compteur monotone ni de séquence sous la milliseconde. Les valeurs créées dans la même milliseconde contiennent des bits finaux aléatoires, et une horloge d'appareil qui recule peut perturber l'ordre visible.

La forme familière avec tirets est une présentation textuelle de 16 octets. Les cinq groupes ont 8, 4, 4, 4 et 12 chiffres hexadécimaux, mais ces groupes ne sont pas des chaînes aléatoires séparées. Le nibble de version apparaît au début du troisième groupe, et la variante RFC dans le premier chiffre hexadécimal du quatrième groupe.

L'exemple v4 public fixe 550e8400-e29b-41d4-a716-446655440000 a 4 à la position de version et a à la position de variante RFC. Le chiffre de variante peut être 8, 9, a ou b pour la variante RFC parce que les bits de tête sont 10. Ces positions expliquent comment l'inspection reconnaît les champs ; elles ne révèlent pas si les autres bits ont été générés aléatoirement. Une valeur écrite à la main peut imiter le même motif.

L'inspecteur reconnaît aussi les valeurs nil et max comme sentinelles spéciales. Nil est composé uniquement de bits zéro ; max uniquement de bits un. Elles peuvent avoir un sens structurel dans un protocole, mais ce ne sont pas des identifiants générés aléatoirement et elles ne doivent pas être confondues avec des valeurs uniques ordinaires.

Pour UUID v7, ClockTools prend un horodatage en millisecondes de l'horloge de l'appareil pour le lot et l'écrit dans les six premiers octets de chaque valeur. Chaque valeur reçoit tout de même de nouveaux octets aléatoires avant la fixation des bits de version et de variante. Si la valeur de l'horloge est hors de la plage du champ d'horodatage v7 de 48 bits, elle est rejetée et la génération échoue, sans tronquer l'horodatage.

Le nombre unique est local au lot généré courant. Le générateur utilise un Set et des tentatives bornées afin que les sorties aléatoires en double dans le lot demandé ne soient pas renvoyées. Il ne consulte ni registre mondial, ni base de données, ni autre onglet, ni valeurs produites hier.

La probabilité n'est toujours pas la même chose qu'une règle métier. Si des clés dupliquées auraient des conséquences, imposez l'unicité là où les identifiants sont stockés et gérez les conflits à cet endroit. La génération ne peut pas connaître l'état de votre application. Une nouvelle génération échouée efface le lot précédent au lieu de laisser un ancien résultat ressembler à une nouvelle requête réussie ; copiez donc les fixtures nécessaires avant d'expérimenter le lot suivant.

Le format du texte est utile quand le destinataire attend un UUID imprimé. Minuscules est la sortie navigateur canonique utilisée par le générateur, Majuscules sert aux systèmes ayant cette convention, accolades et guillemets sont des enveloppes, sans tirets est la forme compacte de 32 hexadécimaux, et URN ajoute le préfixe urn:uuid:.

L'encodage est une autre couche. Texte brut conserve le format texte choisi. L'encodage URL percent-encode ce texte. Base64 et Base64 URL ignorent l'enveloppe de format texte et encodent les 16 octets bruts en ordre réseau ; le sélecteur de format est désactivé pour ces encodages parce que les accolades ou majuscules ne font pas partie de la valeur d'octets.

La présentation décide comment plusieurs valeurs sont disposées. Un par ligne est le plus facile à relire. CSV crée une ligne de champs séparés par des virgules. Tableau JSON est utile pour les fixtures et le code. Valeurs SQL produit des chaînes entre apostrophes séparées par des virgules ; c'est une liste de valeurs, pas une instruction SQL complète.

Pour l'UUID fixe 550e8400-e29b-41d4-a716-446655440000, les encodages d'octets sont VQ6EAOKbQdSnFkRmVUQAAA== en Base64 et VQ6EAOKbQdSnFkRmVUQAAA en Base64 URL. Le texte ordinaire compte 36 caractères, l'hex compact 32, le Base64 avec ses deux caractères de remplissage finaux (==) 24, et cette forme Base64 URL sans caractères de remplissage 22. Ces représentations correspondent aux mêmes 16 octets. Encoder les 36 caractères ASCII imprimés à la place encoderait une autre entrée et ne donnerait pas ces résultats d'octets.

RFC 4648 décrit les alphabets Base64 et sûrs pour les URL. La forme sûre pour les URL remplace les caractères plus et barre oblique du Base64 ordinaire et, dans cet outil, omet le remplissage final. La casse compte toujours dans les deux alphabets Base64 ; ne mettez pas une valeur Base64 en minuscules comme s'il s'agissait d'un texte UUID hexadécimal. L'encodage URL est un troisième choix : les accolades deviennent %7B et %7D, tandis que les lettres, chiffres et tirets UUID canoniques n'ont pas besoin d'encodage pour cent.

L'ordre des octets fait partie d'un contrat d'échange. Cette page encode les octets dans le même ordre réseau que le texte hexadécimal canonique. La documentation Guid.ToByteArray de Microsoft montre que sa sortie d'octets sans paramètre inverse les trois premiers groupes de champs par rapport au texte. Si le récepteur utilise cette représentation, comparez explicitement l'ordre des octets documenté ; convenir que les deux champs contiennent un GUID ne prouve pas que leurs chaînes Base64 correspondront.

Les guillemets forment aussi une couche. Le format texte Guillemets ajoute des guillemets à chaque valeur ; une présentation JSON doit ensuite échapper ces caractères dans sa chaîne, et CSV les échappe dans un champ. Des guillemets échappés supplémentaires peuvent donc être une sérialisation correcte tout en restant faux pour un récepteur qui voulait un UUID nu. Minuscules plus Texte brut est un point de départ simple pour les imports JSON et CSV. Valeurs SQL utilise des chaînes entre guillemets simples ; fournissez séparément la structure de requête environnante et préférez des requêtes applicatives paramétrées plutôt que de coller des chaînes générées dans une requête active.

Une structure valide signifie que le texte correspond à une forme UUID prise en charge et que ses champs de version et de variante peuvent être lus. Elle ne prouve pas que l'identifiant a été généré par ClockTools, par Web Crypto, par un service particulier ou à l'heure v7 décodée.

Pour UUID v7, l'horodatage n'est une preuve utile qu'à l'intérieur d'une enquête plus large. Il peut refléter l'horloge de l'appareil utilisée par un générateur, un horodatage modifié volontairement ou une valeur de test copiée. Traitez-le comme un indice de tri, puis comparez journaux serveur, horodatages de base de données et traces d'audit fiables.

L'inspecteur accepte l'hex compact ou le texte avec tirets, et il peut retirer des enveloppes courantes comme accolades, parenthèses, guillemets ou un préfixe urn:uuid: avant vérification. Il ne décode pas Base64, Base64 URL ni les entrées encodées URL pour la validation ; décodez ces représentations dans le système récepteur avant l'inspection structurelle.

L'inspection accepte un seul identifiant à la fois, pas une ligne CSV exportée ni un tableau JSON. Utiliser une valeur générée colle le premier UUID original du lot courant, pas son affichage encodé, ce qui permet d'inspecter un lot même lorsque Base64 est sélectionné. L'inspecteur reconnaît les versions RFC prises en charge de 1 à 8, mais la génération ne propose que v4 et v7. Un avertissement de variante non prise en charge peut tout de même afficher une forme normalisée ; ce n'est pas une validation RFC réussie ni une permission de réécrire les champs du protocole source.

Une erreur de quantité signifie que le nombre n'est pas un entier de 1 à 1 000. L'outil n'arrondit pas, ne borne pas et ne réduit pas silencieusement la demande. Une erreur de source aléatoire signifie que Web Crypto n'a pas fourni d'octets aléatoires utilisables, donc aucun identifiant n'a été généré.

Une erreur d'encodage peut survenir lorsqu'un navigateur ne dispose pas de l'API nécessaire à l'encodage de sortie choisi. Passez à Texte brut pour récupérer le lot sous-jacent ou essayez un autre navigateur. Un échec de génération est différent : il écarte le lot au lieu de conserver des valeurs partielles. Les échecs du presse-papiers, du partage et du téléchargement ne régénèrent pas d'identifiants. Lorsque l'accès à l'export échoue, sélectionnez manuellement la sortie visible si elle est disponible ; vérifiez les téléchargements avant de supposer qu'un fichier lancé a été enregistré.

Ne collez pas de secrets de production dans un rapport UUID. Un UUID peut être public, privé ou sensible selon la façon dont votre système l'utilise, mais sa forme seule n'en fait pas un mot de passe. Pour les jetons porteurs, réinitialisations de mot de passe ou identifiants d'API, utilisez un générateur de secret et des contrôles de cycle de vie adaptés.