Générateur d'UUID en Lot

Générez jusqu'à 10 000 UUID : v4 aléatoire, v7 ordonné par temps, v5 déterministe basé sur le nom (espace + nom). Exportez TXT, CSV, JSON ou SQL INSERT.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Qu'est-ce que le Générateur d'UUID en Lot?

Un outil navigateur gratuit pour générer des Identifiants Uniques Universels (UUIDs) en masse. Un UUID est un identifiant de 128 bits écrit sous forme de 36 caractères dans sa forme canonique — 32 chiffres hexadécimaux plus quatre tirets selon le motif 8-4-4-4-12 (ex. 550e8400-e29b-41d4-a716-446655440000) — utilisé pour étiqueter de manière unique des lignes de base de données, des événements de systèmes distribués, des sessions utilisateur et des fichiers entre machines sans coordination. Ce générateur prend en charge cinq versions définies par RFC 9562 (la norme 2024 qui remplace RFC 4122): v1 (horodatage + nœud), v4 (purement aléatoire — le plus courant), v5 (déterministe, basé sur le nom via SHA-1 depuis un espace + nom), v7 (ordonné par Unix-ms — parfait pour clés primaires de base de données) et v8 (disposition personnalisée). Tout s'exécute dans votre navigateur via l'API WebCrypto, donc aucune donnée ne quitte votre appareil.

Caractéristiques Principales

Générez jusqu'à 10 000 UUIDs en un clic — génération rapide dans le navigateur
Cinq versions RFC 9562: v1 (temps), v4 (aléatoire), v5 (basé sur le nom), v7 (ordonné), v8 (personnalisé)
v5 déterministe: fournissez un espace (DNS/URL/OID/X.500 ou personnalisé) plus une liste de noms — la même entrée donne toujours le même UUID
v4 utilise crypto.randomUUID() natif si disponible (cryptographiquement sécurisé)
v7 intègre les millisecondes Unix dans les 48 premiers bits — triable, indexable, idéal pour clés primaires
Bascule de casse (minuscule / MAJUSCULE) et de format (avec tirets / sans tirets / {avec accolades})
Exporte en TXT, CSV, JSON ou syntaxe SQL INSERT INTO ... VALUES (...)
Confidentialité préservée: v1 utilise des bits de nœud multicast aléatoires (ne révèle jamais la vraie MAC)
100% dans le navigateur — pas d'aller-retour serveur, pas de télémétrie

Générateur d'UUID en Lot — Générez jusqu'à 10 000 UUID : v4 aléatoire, v7 ordonné par temps, v5 déterministe basé sur le nom (espace + nom). Export — **Générateur d'UUID en Lot**

Comment l'Utiliser

Choisissez une version: v4 pour usage général, v7 pour clés BD, v5 pour des IDs déterministes basés sur le nom, v1 pour un ID hérité basé sur le temps
Pour v4/v7/v8/v1: saisissez une quantité de 1 à 10 000. Pour v5: choisissez un espace et collez un nom par ligne
Optionnellement basculez la casse en MAJUSCULE et le format en sans tirets ou {accolades}
Cliquez sur Générer UUIDs — la liste apparaît instantanément
Copiez tout dans le presse-papiers ou téléchargez en TXT, CSV, JSON ou instructions SQL INSERT
Collez le bloc SQL directement dans votre client de base de données pour insérer des IDs en masse

Questions Fréquentes

v4 est 122 bits aléatoires avec 6 bits fixes de version/variante — totalement imprévisible mais sans ordre inhérent, donc insérer des clés v4 dans un index B-tree cause des écritures de page aléatoires et de la fragmentation d'index. v7 est le remplacement moderne de RFC 9562: les 48 premiers bits sont l'horodatage Unix en millisecondes, le reste est aléatoire. Les IDs v7 trient chronologiquement comme chaînes ET comme binaire, donc ils se regroupent bien dans les index B-tree (PostgreSQL, MySQL InnoDB, SQL Server). Utilisez v7 pour les clés primaires dans les nouveaux schémas; utilisez v4 pour les IDs opaques publics où vous ne voulez pas divulguer le temps de création.

Utilisez v5 chaque fois que vous avez besoin d'un ID déterministe et reproductible dérivé d'une clé naturelle — un email, SKU, URL, chemin de fichier, ou une chaîne locataire+ressource. v5 est le hachage SHA-1 d'un UUID d'espace de noms concaténé à un nom, donc le même espace + nom produit toujours exactement le même UUID, sur n'importe quelle machine, pour toujours. Cela le rend parfait pour l'ETL et les imports idempotents (relancer un chargement ne crée jamais de lignes en double), la déduplication, dériver une clé primaire stable sans table de correspondance, et générer des IDs d'événements/documents prévisibles. Choisissez le bon espace : DNS pour les noms d'hôte, URL pour les URL, OID pour les identifiants d'objet, X.500 pour les noms d'annuaire, ou fournissez votre propre UUID d'espace personnalisé pour cadrer les IDs à votre application. v5 (SHA-1) est préférable à l'ancien v3 (MD5). Note : v5 N'EST PAS aléatoire — ne l'utilisez jamais comme jeton secret, car quiconque connaît l'espace et le nom peut recalculer l'UUID.

Un UUID fait 128 bits = 16 octets. Stocké en texte canonique il nécessite CHAR(36) (ou 32 sans tirets), mais stocké nativement il ne fait que 16 octets — plus de 2x plus petit, ce qui réduit chaque page d'index et accélère les jointures et recherches. Utilisez le type natif : PostgreSQL uuid (16 octets), MySQL/MariaDB BINARY(16) avec UUID_TO_BIN()/BIN_TO_UUID(), SQL Server uniqueidentifier, Oracle RAW(16). Le plus grand gain sur les tables à écriture intensive est l'ordre : les clés aléatoires v4 dispersent les insertions dans le B-tree, causant des divisions de page, de la fragmentation d'index et une mauvaise localité de cache, tandis que les clés ordonnées par temps v7 s'ajoutent près du bord droit de l'index — les benchmarks montrent régulièrement que v7/UUID séquentiels réduisent le gonflement de l'index et améliorent le débit d'insertion en masse plusieurs fois par rapport à v4 aléatoire sur InnoDB et Postgres. Règle générale : stockez en 16 octets et préférez v7 (ou v5 quand vous avez besoin de déterminisme) à v4 pour les clés primaires/clusterisées.

Pratiquement, oui. Un UUID v4 a 122 bits d'aléa, donnant 2^122 ≈ 5,3 × 10^36 valeurs possibles. Par le paradoxe des anniversaires, vous auriez besoin de générer environ 2,71 quintillions (2,71 × 10^18) UUIDs avant que la probabilité d'une seule collision atteigne 50%. Même à 10 000 IDs par seconde sans arrêt, vous atteindriez 50% de probabilité de collision après environ ~9 mille milliards d'années. Pour toutes fins pratiques — y compris les systèmes à l'échelle planétaire — v4 est à l'épreuve des collisions.

La spécification v1 originale du RFC 4122 encode l'adresse MAC réseau du générateur dans les 48 derniers bits, ce qui fuit l'identité (un seul UUID v1 peut être lié à une machine spécifique — cela a été célèbrement utilisé pour identifier l'auteur du virus Melissa en 1999). Notre générateur suit la meilleure pratique moderne: nous randomisons les bits de nœud et définissons le bit multicast, signalant que ce N'EST PAS une vraie adresse matérielle. Donc un ID v1 de cet outil préserve la confidentialité.

v8 est la version 'disposition personnalisée': RFC 9562 la réserve pour des structures spécifiques à l'application. Les seuls bits requis sont le nibble de version (8) et les bits de variante. Vous êtes libre d'encoder n'importe quoi dans les 122 bits restants — un préfixe d'ID de locataire, un indice de sharding, une signature fixe. Ce générateur produit un v8 avec la même disposition ordonnée par temps que v7, simplement renommée. Pour v8 de production, concevez votre propre disposition et documentez-la.

Oui. PostgreSQL a un type uuid natif; utilisez l'export SQL et INSERT INTO table (id) VALUES ('uuid-ici'); — ou téléchargez le CSV et utilisez COPY. MySQL utilise CHAR(36) ou BINARY(16) (plus rapide); UUID_TO_BIN(uuid_string, 1) réordonne v1 pour la localité d'index (pas nécessaire pour v7 — déjà triable). MongoDB stocke les UUIDs comme sous-type Binary 4. Pour SQL Server utilisez uniqueidentifier; pour Oracle RAW(16).

v4 oui (122 bits d'entropie CSPRNG = bien plus qu'une clé symétrique de 128 bits). v1, v7 et v8 ne sont PAS sûrs comme jetons porteurs car ils divulguent l'horodatage de création et ont moins d'aléa (62-77 bits aléatoires selon la version). Si un attaquant peut observer un ID v7 et deviner approximativement quand un compte a été créé, il peut réduire considérablement l'espace de recherche. Pour les jetons de session, liens de réinitialisation de mot de passe, clés API: utilisez v4 ou un jeton CSPRNG dédié.

10 000 atteint un point optimal: assez grand pour presque tout scénario de seed en masse (fixtures de test BD, scripts de migration, tests de charge), assez petit pour rendre dans la zone de texte sans figer le navigateur. Un navigateur typique génère 10 000 UUIDs v4 en 20-80ms via crypto.randomUUID(). Si vous avez besoin de plus de 1M UUIDs, exécutez ce générateur en boucle ou utilisez un script côté serveur — la génération d'UUID se parallélise trivialement.

Voir aussi