Choisissez le nombre d’UUID et la casse des lettres. Envoyez le formulaire pour générer les valeurs sur le serveur, puis copiez la liste dans vos données de test.
Choisissez le nombre d'identifiants (de 1 à 100) et la casse des lettres ; le formulaire les génère sur le serveur et renvoie la liste, une valeur par ligne. Chaque valeur est un UUID de version 4 sur 128 bits, au format canonique 8-4-4-4-12, prêt à coller dans un jeu de données de test, une fixture ou une clé de base de données.
La version 4 est construite à partir de bits aléatoires : elle ne contient ni horodatage, ni adresse MAC, ni hachage de nom, donc la valeur ne révèle ni la machine ni le moment de sa création. C'est ce qui en fait un identifiant opaque — et c'est aussi pourquoi il ne faut pas s'en servir pour trier des enregistrements par date.
Un UUID, ce sont 128 bits écrits sous forme de 32 chiffres hexadécimaux répartis en cinq groupes séparés par des tirets. En version 4, 122 de ces bits sont aléatoires : le quartet qui ouvre le troisième groupe est fixé à 4 pour signaler la version, et les deux bits de poids fort du quatrième groupe sont fixés à 10 pour respecter la variante du RFC 4122.
Ces six bits fixes expliquent pourquoi un vrai v4 n'est pas simplement 32 caractères hexadécimaux tirés au hasard : les validateurs stricts et les bibliothèques qui vérifient la version rejettent les valeurs produites par un hachage ou un compteur sans ces bits.
Avec 122 bits aléatoires, il existe environ 5,3 × 10^36 valeurs possibles : la probabilité de retomber sur la même est négligeable pour tout volume réaliste. La page vérifie en plus les valeurs du lot et régénère celles qui se répètent : un lot de 100 identifiants ne contient donc jamais de doublon.
La seule collision qui compte en pratique est celle de vos propres données : si vous comparez des chaînes avec une casse différente selon la collation de votre base, vous pouvez vous retrouver avec deux lignes pour la même valeur. Stockez l'UUID sous une seule forme (minuscules, par exemple) ou dans une colonne binaire.
Un v4 fait une bonne clé primaire quand l'ordre n'a pas d'importance : 16 octets d'aléa impossibles à deviner. Si votre base souffre du manque de localité de l'index (insertions dispersées dans l'arbre), regardez plutôt UUID v7 ou ULID, qui ajoutent un horodatage triable ; côté stockage, CHAR(36) reste lisible et BINARY(16) économise de la place.
N'en faites pas un secret : la valeur est générée sur le serveur puis renvoyée à la page, traitez-la donc comme un identifiant public. Pour un jeton de session ou une clé, générez le secret dans votre propre backend avec un générateur cryptographique et ne stockez qu'un hachage.
Il est aléatoire : la version 4 ne code ni horodatage, ni adresse MAC, ni nom, contrairement à la version 1. Elle ne contient que 122 bits aléatoires et six bits fixes qui identifient la version et la variante.
Oui. Le RFC 4122 ne distingue pas la casse : 0BC4… et 0bc4… désignent la même valeur. Choisissez une seule forme pour votre base et vos comparaisons, surtout si la collation de la colonne est binaire.
De 1 à 100 par envoi. Si vous modifiez le formulaire avec une valeur hors plage, le serveur la corrige : 0, un nombre négatif ou un texte non numérique deviennent 1, et tout ce qui dépasse 100 est ramené à 100.
Chaque requête fait générer la liste sur le serveur, y compris le premier chargement, qui affiche un UUID par défaut. Aucun cache ni valeur pré-générée : recharger la page produit des identifiants différents.
Oui, c'est un usage courant : ils ne se répètent pas et ne révèlent rien de votre infrastructure. Si l'ordre d'insertion dans l'index compte, préférez UUID v7 ou ULID ; si la place compte, stockez les 16 octets en BINARY(16) plutôt qu'une chaîne de 36 caractères.
Ce n'est pas l'outil adapté. La valeur est produite sur le serveur et affichée dans la page : considérez-la comme publique et servez-vous-en comme identifiant. Pour des jetons ou des clés, générez l'aléa dans votre backend et ne stockez qu'un hachage.