Générateur d'UUID v7

Générez en masse, directement dans votre navigateur, des UUID v7 — la norme RFC 9562 qui intègre un horodatage de 48 bits en millisecondes permettant de trier les identifiants par ordre de création. Formats standard, majuscules, sans tirets, avec accolades et URN pris en charge, et compatibilité immédiate avec vos colonnes UUID existantes.

UUID v7 face à UUID v4 et ULID

Format Longueur Triable par ordre de création Compatible avec les colonnes UUID existantes Description
UUID v7 36 caractères (dont 4 tirets) Oui (les 48 premiers bits forment un horodatage en millisecondes) Oui (type UUID standard, notation hexadécimale conservée) Normalisé par la RFC 9562. Combine un horodatage Unix avec des bits aléatoires, offrant un tri par ordre de création tout en restant compatible avec l'infrastructure UUID existante. C'est le format généré par cet outil.
UUID v4 36 caractères (dont 4 tirets) Non (entièrement aléatoire) Oui (type UUID standard) Identifiant de 128 bits entièrement aléatoire, normalisé par la RFC 9562. Ne contient aucune information sur son origine et reste la variante la plus utilisée.
ULID 26 caractères Oui (les 10 premiers caractères forment un horodatage) Non (le Base32 nécessite un type de colonne dédié) Spécification indépendante de la norme UUID (RFC 4122/9562) utilisant le Base32 de Crockford. Plus court que l'UUID v7, mais ne peut pas être stocké directement dans une colonne UUID native.

Conseils d'utilisation

  • Chaque UUID v7 est généré directement dans le navigateur via l'API Web Crypto — rien n'est jamais envoyé aux serveurs de toolbase.cc.
  • Comme les 48 premiers bits d'un UUID v7 forment un horodatage Unix en millisecondes, un simple tri alphabétique des valeurs générées suffit à retrouver l'ordre chronologique de création.
  • Un UUID v7 peut être stocké directement dans n'importe quelle colonne contenant déjà des valeurs UUID v4 (colonne CHAR(36), type uuid natif de PostgreSQL, etc.), sans qu'aucun changement de schéma ne soit nécessaire lors de la migration.
  • Le format « sans tirets » est pratique pour les segments de chemin d'URL ou les noms de fichiers, tandis que le format « avec accolades » correspond à la notation GUID utilisée dans le registre ou COM sous Windows.
  • Si vous hésitez entre UUID v7 et ULID (Base32 de Crockford, 26 caractères) : privilégiez UUID v7 lorsque votre système suppose déjà une colonne UUID native, et ULID lorsque la priorité est d'obtenir la chaîne la plus courte possible.

Questions fréquentes

La différence essentielle est la possibilité de trier l'identifiant par date de création. UUID v4 est une valeur de 128 bits entièrement aléatoire, sans ordre intrinsèque, tandis qu'UUID v7 porte un horodatage Unix en millisecondes sur ses 48 premiers bits, ce qui permet à une simple comparaison de chaînes de révéler l'ordre de création.

Les deux sont triables par date de création, mais leur représentation diffère. UUID v7 permet de migrer tout en conservant la compatibilité avec les colonnes et bibliothèques de type UUID existantes, alors qu'ULID utilise un format Base32 de Crockford indépendant et plus court, sur 26 caractères. Choisissez UUID v7 si votre système suppose déjà un type UUID natif, et ULID si la priorité est un identifiant plus court pour un nouveau système.

Il a été officiellement normalisé en mai 2024 par la RFC 9562 de l'IETF. Ce même document a ajouté la variante v6, à horodatage réordonné, ainsi que la variante v7, fondée sur l'horodatage Unix, en complément des UUID v1 à v5 déjà existants.

Oui. Une valeur entièrement aléatoire comme UUID v4 s'insère à des positions aléatoires dans l'index, ce qui tend à fragmenter les index B-tree, alors qu'UUID v7 se trie approximativement par ordre chronologique, si bien que les nouvelles lignes s'ajoutent près de la fin de l'index et que les performances d'insertion s'améliorent. PostgreSQL 18 a même ajouté une fonction native uuidv7(), preuve de son adoption croissante par les principales bases de données.
ツールくん

Anecdote — comment UUID v7 a redonné le sens du temps à la famille UUID

UUID v7 a été normalisé en mai 2024 par la RFC 9562 de l'IETF, la première révision majeure de la spécification UUID depuis la RFC 4122 originale de 2005, publiée près de vingt ans plus tôt. Cette révision a ajouté les variantes triables v6 et v7, ainsi que la variante v8 à champs personnalisés, motivée par un reproche de longue date : le caractère entièrement aléatoire d'UUID v4 nuit à l'efficacité des index de bases de données.

La conception d'UUID v7 ressemble beaucoup à celle de notre outil jumeau, ULID : les deux placent un horodatage en millisecondes en tête et remplissent le reste avec des bits aléatoires. La différence décisive réside dans la représentation — ULID adopte un format Base32 de Crockford de 26 caractères, indépendant de la norme UUID, tandis qu'UUID v7 conserve la notation hexadécimale sur 36 caractères qui définit les UUID depuis la RFC 4122. Ce choix permet à UUID v7 de s'intégrer directement, sans aucune modification, aux colonnes, bibliothèques et contrats d'API de type UUID déjà en place.

La prise en charge d'UUID v7 s'est rapidement répandue parmi les principales bases de données et environnements d'exécution peu après sa publication. PostgreSQL propose une fonction native uuidv7() depuis la version 18, et les bibliothèques d'autres langages et ORM majeurs ont elles aussi rapidement ajouté la prise en charge de v7. Concilier la commodité d'un tri par ordre de création avec la compatibilité de ne pas remettre en cause l'existant UUID explique précisément pourquoi UUID v7, aux côtés d'ULID, a été adopté aussi vite.

Plus d'outils dans cette catégorie