Thème

Outils populaires

Générateur UUID

Générez instantanément un UUID v4 aléatoire ou un UUID v7 chronologique, ou jusqu'à 10 000 à la fois. C'est aussi un générateur de GUID en ligne : un nouveau GUID est le même type de valeur de 128 bits. Collez n'importe quel UUID pour décoder sa version, sa date de création et chacun de ses champs.

RFC 9562 · crypto.getRandomValues · créés et lus dans votre navigateur, rien n'est envoyé

Le chiffre en couleur est la version : le premier chiffre du troisième groupe de tout UUID.

v4 · Aléatoire36 caractères · 122 bits aléatoires
xxxxxxxx-xxxx-4xxx-Nxxx-xxxxxxxxxxxx
Anatomie · RFC 9562 §5.4128 bits · 32 chiffres hex · 36 caractères
Survolez ou touchez un champ pour le lire

Créé et lu dans votre navigateur avec crypto.getRandomValues ; rien n'est envoyé.

Format

Qu'est-ce qu'un UUID, et que signifie UUID ?

UUID signifie Universally Unique Identifier (identifiant unique universel) : une étiquette de 128 bits que n'importe quel ordinateur peut créer seul, en comptant qu'aucun autre ordinateur ne créera la même. Il s'écrit en 32 chiffres hexadécimaux répartis en cinq groupes, comme dans cet exemple d'UUID : 919108f7-52d1-4320-9bac-f847db4148a8.

Le format est défini par la RFC 9562 (mai 2024), qui a remplacé la RFC 4122 et ajouté les versions 6, 7 et 8. Aucun registre central ne distribue les UUID : l'unicité vient du hasard, d'un horodatage ou du hachage d'un nom, selon la version.

Les bases de données s'en servent comme clés primaires, les API comme identifiants de requêtes et d'objets, les systèmes d'exploitation pour les disques, les partitions et les composants logiciels. GUID (Globally Unique Identifier) est le nom que Microsoft donne à la même chose.

Une valeur, quatre taillesRFC 9562 §4

UniversallyUniqueIDentifier

  1. 128 bits
  2. 16 octets
  3. 32 chiffres hex
  4. 36 caractères avec les tirets919108f7-52d1-4320-9bac-f847db4148a8

GUIDLe nom que Microsoft donne à la même valeur

L'exemple de version 4 de la RFC 9562, compté de quatre façons. La forme texte ajoute quatre tirets aux 32 chiffres hexadécimaux : 36 caractères.
Générateur UUID : un UUID v7 avec horodatage, version et bits aléatoires repérés champ par champ, et un lot de v7Générateur UUID : un UUID v7 avec horodatage, version et bits aléatoires repérés champ par champ, et un lot de v7Choisir une versionv4 aléatoire, v7 chronologique, v5 basé sur un nom et les autres, chacun avec sa couleur.Un clicCopiez-le ou créez-en un autre ; un lot de 10 000 au maximum s'exporte en texte, CSV, JSON ou SQL.Chaque champLes bits que la RFC 9562 définit pour cette version, avec l'heure que porte un v7, lue en clair.Tout formatAccolades, sans tirets, majuscules, Base64url, un entier ou l'ordre des octets .NET.
Un UUID v7 décortiqué : l'horodatage de 48 bits, le chiffre de version, les bits de variante et la partie aléatoire. Sélectionnez un numéro pour voir ce que montre chaque partie.

Format et longueur d'un UUID : 36 caractères

Un UUID fait 128 bits, écrits en 32 chiffres hexadécimaux et 4 tirets, en groupes de 8, 4, 4, 4 et 12 : 36 caractères. Le premier chiffre du troisième groupe est la version, et le premier chiffre du quatrième groupe indique la variante : 8, 9, a ou b pour les UUID de la RFC 9562.

Exemple : 017f22e2-79b0-7cc3-98c4-dc0c0c07398f est un UUID de version 7, de variante RFC. Majuscules, minuscules et casse mixte sont toutes valides ; la plupart des outils écrivent en minuscules, uuidgen sous macOS en majuscules. Sans tirets, il fait 32 caractères, entre accolades 38 (le format B de .NET), sous la forme urn:uuid: 45, et en Base64url 22.

Une expression régulière qui vérifie la forme RFC : ^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$, avec l'option insensible à la casse. Elle refuse les UUID Nil et Max, valides mais spéciaux ; le décodeur ci-dessus les nomme.

La forme texteRFC 9562 §4
017f22e28-79b04-7cc34-98c44-dc0c0c07398f12

32 chiffres hex + 4 tirets = 36 caractères

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxxM version : 1–8N variante : 8, 9, a ou b
Regex · insensible à la casse^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$
Les mêmes 128 bits, écrits autrement
  • Standard017f22e2-79b0-7cc3-98c4-dc0c0c07398f36
  • Sans tirets017f22e279b07cc398c4dc0c0c07398f32
  • Accolades {…}{017f22e2-79b0-7cc3-98c4-dc0c0c07398f}38
  • urn:uuid:urn:uuid:017f22e2-79b0-7cc3-98c4-dc0c0c07398f45
  • Base64urlAX8i4nmwfMOYxNwMDAc5jw22
  • Base64AX8i4nmwfMOYxNwMDAc5jw==24
  • Base58BihbxwwQ4NZZpKRH9JDCz21
  • Base3201FWHE4YDGFK1SHH6W1G60EECF26
  • Entier1989357241971137676463954034883508623jusqu'à 39
  • Binaire01 7f 22 e2 79 b0 7c c3 98 c4 dc 0c 0c 07 39 8f16 octets
L'exemple v7 de la RFC 9562 elle-même, sous chaque forme écrite. La regex refuse volontairement les UUID Nil et Max : ils n'ont pas de version.

Les versions d'UUID expliquées : de v1 à v8

La version indique comment un UUID a été créé : v4 à partir de bits aléatoires, v7 à partir de l'heure et de bits aléatoires, v1 et v6 à partir d'un horodatage et d'un identifiant de nœud, v3 et v5 par hachage d'un nom, et v8 selon une structure propre à son créateur.

Les versions 2 et 0 ne sont pas générées ici : v2 (DCE Security) est réservée et la RFC 9562 n'en définit pas la structure, et 0 n'est pas une version. Les deux valeurs spéciales n'ont pas de version : l'UUID Nil ne contient que des zéros et l'UUID Max que des uns (ffffffff-ffff-ffff-ffff-ffffffffffff, nouveau dans la RFC 9562).

Pour les nouveaux systèmes, la RFC 9562 recommande v7 plutôt que v1 et v6, et v5 plutôt que v3. v4 reste le choix simple quand la valeur ne doit rien dire du moment de sa création.

VersionSes 128 bitsCréé à partir deTri chronologique
v1Temps + nœud · §5.1Heure (100 ns) + séquence d'horloge + nœudNon
v2DCE Security : réservée, sans structure dans la RFC 9562Non générée : aucune structure définie–
v3Nom · MD5 · §5.3MD5 d'un espace de noms + un nomNon
v4Aléatoire · §5.4Bits aléatoiresNon
v5Nom · SHA-1 · §5.5SHA-1 d'un espace de noms + un nomNon
v6v1 triable · §5.6Les champs de v1, bits de poids fort de l'heure d'abordOui
v7Chronologique · §5.7Temps Unix (ms) + bits aléatoiresOui
v8Personnalisé · §5.8La structure propre au créateurNon
Nil§5.9Que des zéros : « aucune valeur »–
Max§5.10Que des uns : une sentinelle–
  • heure
  • aléatoire
  • hachage
  • séquence d'horloge
  • nœud
  • version
  • variante
Chaque barre représente les 128 bits d'une version tels que la RFC 9562 les organise, d'après ses propres vecteurs de test. Seuls v6 et v7 placent l'heure en premier : eux seuls se trient donc par date comme du texte.

UUID v4 ou v7 : lequel utiliser ?

Utilisez v7 pour les clés de base de données et tout ce que vous triez ou indexez : il commence par l'heure de création, donc les nouvelles lignes arrivent en fin d'index. Utilisez v4 quand l'identifiant ne doit pas révéler quand il a été créé : ses 122 bits libres sont tous aléatoires.

Des clés v4 aléatoires dispersent chaque insertion dans tout l'index B-tree, ce qui provoque des divisions de pages et garde une plus grande partie de l'index en mémoire ; les clés v7 arrivent dans l'ordre, comme un nombre auto-incrémenté, mais n'importe quel serveur peut les créer sans interroger la base. Un v7 garde 74 bits aléatoires par milliseconde : deux serveurs qui en créent un au même instant n'entrent donc pas en collision pour autant.

La contrepartie : quiconque voit un v7 peut lire la milliseconde de sa création (collez-en un dans le décodeur ci-dessus). Si cela compte, utilisez v4, ou gardez v7 en interne et affichez publiquement un autre identifiant.

12 insertions dans un index B-tree8 pages feuilles · 16 clés chacune
Les clés v4 arrivent n'importe où7 pages sur 8 touchées · 3 divisions de page
Pages par premier octet
00–1fdivision
20–3f
40–5f
60–7f
80–9f
a0–bf
c0–dfdivision
e0–ffdivision
c100eb4b-4f3f-4b29-ad77-da7cd9d1eda592c97333-2db8-4fc2-b5b6-cedd8c7abede
Les clés v7 arrivent à la fin1 page sur 8 touchée · 0 division de page
Pages par jour de création des clés
17 oct.
18 oct.
19 oct.
20 oct.
21 oct.
22 oct.
23 oct.
24 oct.
01a16d3e-e1c0-70f6-99ec-6d454991b2fa01a16d3e-e1c0-70f6-99ec-6d45c2f6b35b
  • déjà dans l'index
  • libre
  • nouvelle clé v4
  • nouvelle clé v7
  • division de page : la moitié de ses clés passe sur une nouvelle page
Un modèle, pas un benchmark : des pages feuilles de 16 clés. Les clés aléatoires trouvent d'anciennes pages presque pleines et les divisent ; les premiers octets d'un v7 sont l'heure, donc les douze vont sur la page la plus récente, qui a encore de la place.

GUID ou UUID : y a-t-il une différence ?

Un GUID et un UUID sont la même valeur de 128 bits sous la même forme texte ; GUID est le nom que Microsoft lui donne. Guid.NewGuid() en .NET crée un UUID aléatoire de version 4, et Guid.CreateVersion7() de .NET 9 un UUID de version 7.

La différence se trouve en mémoire. La structure GUID de Microsoft stocke ses trois premiers groupes sous forme d'entiers little-endian, si bien que ToByteArray() de .NET donne les 8 premiers octets dans un autre ordre que l'ordre réseau de la RFC 9562 : 919108f7-52d1-… devient les octets f7 08 91 91 d1 52 …. Le texte est identique ; les octets bruts transférés d'un système à l'autre doivent être convertis. Le décodeur montre les deux ordres.

Le type uniqueidentifier de SQL Server trie en outre d'abord par ses six derniers octets, si bien que les valeurs v7 n'y restent pas dans l'ordre chronologique ; NEWSEQUENTIALID() crée des valeurs qui le restent, mais elles peuvent repartir plus bas après un redémarrage et sont faciles à deviner. Les anciens GUID COM peuvent porter les bits de variante propres à Microsoft au lieu de ceux de la RFC 9562 ; le décodeur nomme cette variante.

Un GUID, trois ordres d'octets16 octets
919108f7-52d1-4320-9bac-f847db4148a8
RFC 9562 ordre réseau
.NET Guid.ToByteArray()
SQL Server ordre uniqueidentifierLes six derniers octets décident de l'ordre
  • Data1 · 4 octets, inversés
  • Data2 · inversés
  • Data3 · inversés
  • Data4 · tels quels
Le même texte en mémoire : .NET stocke les trois premiers groupes en little-endian, et SQL Server trie d'abord par les six derniers octets, si bien que les clés v7 chronologiques n'y restent pas dans l'ordre.

Comment générer un UUID dans le code

La plupart des langages créent un UUID v4 en une ligne, et beaucoup créent désormais aussi des v7 : uuid.uuid7() de Python 3.14, Guid.CreateVersion7() de .NET 9, UUID.ofEpochMillis() de Java 26, uuid.NewV7() de Go 1.27, crypto.randomUUIDv7() de Node.js 26.1 et uuidv7() de PostgreSQL 18. Les navigateurs n'ont toujours que crypto.randomUUID(), un v4.

Choisissez votre langage pour obtenir la ligne de code. Tous les v7 ne gardent pas dans l'ordre les UUID créés dans la même milliseconde : ceux de Python et de Go le font, ceux de .NET et de Node ne le garantissent pas. Et UUID() de MySQL renvoie un UUID de version 1 qui, sous Linux et Windows, porte la vraie adresse MAC du serveur.

Fonctions UUID intégrées, par langage

Python
import uuid

uuid.uuid4()   # v4
uuid.uuid7()   # v7, Python 3.14+
uuid.uuid5(uuid.NAMESPACE_DNS, "www.example.com")  # v5

uuid7() tient un compteur de 42 bits : les UUID d'une même milliseconde restent dans l'ordre.

Les versions telles que la documentation de chaque langage les liste ; les logos sont ceux des projets eux-mêmes.

Deux UUID peuvent-ils être identiques ?

En théorie oui, en pratique non : un UUID v4 a 122 bits aléatoires, soit environ 5,3 × 10³⁶ valeurs. Il faudrait en créer environ 103 000 milliards pour avoir une chance sur un milliard que deux d'entre eux soient identiques, et environ 2,7 trillions (2,7 × 10¹⁸) pour une chance sur deux.

C'est la borne du paradoxe des anniversaires : avec n valeurs aléatoires parmi N, la probabilité d'un doublon vaut environ 1 − e^(−n(n−1)/2N). À un milliard d'UUID par seconde, une probabilité de 50 % demanderait environ 86 ans. Les vrais doublons viennent de générateurs défaillants : une graine non aléatoire, une machine virtuelle clonée avec son état aléatoire, ou des identifiants copiés à la main.

Pour v7, seuls des UUID créés dans la même milliseconde peuvent coïncider, et 74 bits aléatoires les distinguent. Le générateur de cette page garde aussi un lot dans l'ordre au sein d'une milliseconde (RFC 9562 §6.2) : 10 000 UUID créés d'un coup sont donc uniques et triés.

Le paradoxe des anniversairesnos calculs
Probabilité que deux soient identiques1 sur 1,1 × 1019p ≈ 9,4 × 10−20

À un milliard par seconde, en créer autant prend 1 seconde.

p ≈ 1 − e^(−n(n−1)/2N), avec N = 2¹²² pour v4 et 2⁷⁴ par milliseconde pour v7. La RFC 9562 ne donne aucun chiffre de collision : ce sont les nôtres, issus de la même fonction que celle qu'utilise la page.

Décodeur d'UUID : lire l'horodatage d'un UUID

Collez un UUID dans l'onglet « Décoder et valider », le décodeur et validateur d'UUID ci-dessus : il lit la version et la variante à deux emplacements fixes, puis les champs que cette version définit. Un v7 donne la milliseconde de sa création, un v1 ou un v6 l'heure à 100 nanosecondes près, plus une séquence d'horloge et un identifiant de nœud.

Un nœud v1 ou v6 dont le bit multicast est à 0 peut être la vraie adresse MAC de la carte réseau ; cherchez son fabricant avec la recherche d'adresse MAC. Les générateurs soucieux de la vie privée mettent ce bit à 1 et utilisent un nœud aléatoire, comme celui-ci.

L'heure est celle que le générateur a écrite, pas la preuve du moment où l'UUID a été créé. Un v4 ne contient aucune heure, seulement des bits aléatoires, et v3, v5 et v8 contiennent des hachages : il n'y a rien à relire, et un hachage ne permet pas de retrouver le nom. Collez une liste pour en vérifier jusqu'à 1 000 d'un coup : lignes invalides, doublons et ordre des UUID basés sur le temps.

Deux façons d'écrire le même instantRFC 9562 · Appendix A
017f22e2-79b0-7cc3-98c4-dc0c0c07398f
  1. unix_ts_ms0x017f22e279b0
  2. ms depuis 19701 645 557 742 000
  3. UTC2022-02-22T19:22:22.000Z
c232ab00-9414-11ec-b3c8-9f6bdeced846
  1. time_high · time_mid · time_low1ec 9414 c232ab00
  2. pas de 100 ns depuis le 1582-10-15138 648 505 420 000 000
  3. UTC2022-02-22T19:22:22.0000000Z

Le même instant : les exemples de la RFC 9562 ont été créés ensemble.

Un v7 commence par les millisecondes écoulées depuis 1970. Un v1 stocke d'abord la partie basse de son heure : le décodeur remet donc les trois parties dans l'ordre avant de compter à partir du 15 octobre 1582.

UUID basés sur un nom : v5 et v3

Un UUID v5 est le hachage SHA-1 d'un UUID d'espace de noms et d'un nom, tronqué à 128 bits avec la version et la variante fixées ; v3 fait de même avec MD5. Le même espace de noms et le même nom donnent toujours le même UUID, sur n'importe quel ordinateur : choisissez v5 ci-dessus pour utiliser cette page comme générateur d'UUID v5.

La RFC 9562 définit quatre espaces de noms : DNS pour les noms de domaine, URL, OID et X.500. Ainsi, www.example.com dans l'espace de noms DNS donne toujours 2ed6657d-e927-568b-95e1-2665a8aea6a2 en v5. Utilisez les UUID basés sur un nom pour donner un identifiant stable à quelque chose qui a déjà un nom unique, sans stocker de table de correspondance.

Préférez v5 à v3 : MD5 est plus faible, et la RFC 9562 recommande v5. Ni l'un ni l'autre ne cache le nom : quiconque peut le deviner peut calculer le même UUID. L'option v8 de cette page utilise SHA-256 de la même façon, comme l'exemple v8 de la RFC elle-même.

Espace de noms + nom → v5RFC 9562 §5.5
  1. Espace de noms6ba7b810-9dad-11d1-80b4-00c04fd430c8DNS · 16 octets
  2. Nom"www.example.com"UTF-8 · 15 octets
  3. Empreinte SHA-1, 160 bits2ed6657de927468b55e12665a8aea6a22dee3e35les 128 premiers bits sont conservés
  4. L'UUID2ed6657d-e927-568b-95e1-2665a8aea6a2chiffre de version 4 → 5 · chiffre de variante 5 → 9
  • DNS6ba7b810…
  • URL6ba7b811…
  • OID6ba7b812…
  • X.5006ba7b814…
L'exemple v5 de la RFC 9562 elle-même : www.example.com dans l'espace de noms DNS. Tout ordinateur qui hache le même espace de noms et le même nom obtient le même UUID.

ULID ou UUID v7 (et autres identifiants)

Un ULID et un UUID v7 commencent tous deux par un horodatage de 48 bits en millisecondes et se trient par date. La différence : un ULID consacre ses 80 autres bits au hasard et s'écrit en 26 caractères Base32, tandis qu'un v7 dépense 6 bits pour sa version et sa variante et s'intègre à toute colonne et toute bibliothèque UUID.

Si votre base de données, votre ORM ou votre API parle déjà UUID, v7 vous donne l'ordre chronologique sans nouveau type. NanoID et les identifiants courts similaires sont des chaînes aléatoires d'une longueur choisie, sans heure ni structure standard. Tout UUID peut aussi s'écrire plus court : 22 caractères en Base64url, 22 au plus en Base58.

Trois identifiants, 128 bits chacunà l'échelle
UUID v7l'heure, puis l'aléatoire
36 caractèresse trie par date
ULIDl'heure, puis l'aléatoire
26 caractèresse trie par date
UUID v4aléatoire uniquement
36 caractèresaucun ordre
  • millisecondes depuis 1970
  • aléatoire
  • version et variante
UUID v7 et ULID partagent l'horloge de 48 bits en millisecondes ; v7 consacre 6 bits à sa version et à sa variante, ULID utilise les 80 pour le hasard. Un v4 n'est qu'aléatoire ; en Base64url, tout UUID fait 22 caractères.

Les UUID sont-ils sûrs comme jetons ?

Non. La RFC 9562 dit de ne pas supposer que les UUID sont difficiles à deviner, et de ne jamais en utiliser un comme capacité de sécurité : un identifiant dont la simple possession donne un accès, comme un lien de réinitialisation de mot de passe ou une clé d'API.

Un v4 issu d'un bon générateur est aléatoire, mais un v1, v6 ou v7 révèle sa date de création et un v3 ou v5 peut être recalculé à partir de son nom. Pour les secrets, utilisez un jeton prévu pour cela, par exemple 256 bits aléatoires issus d'un générateur cryptographique, et vérifiez les droits à chaque requête. Les UUID conviennent comme identifiants publics quand l'accès est contrôlé séparément.

IDCe qu'il révèle à qui le voitComme secret
v1, v6Sa date de création, et peut-être l'adresse MAC de la carte réseauNon
v7La milliseconde de sa créationNon
v5, v3Rien de nouveau, mais un nom deviné donne le même UUIDNon
v4Rien, s'il vient d'un générateur fiableNon
Jeton de 256 bitsRien : conçu pour les secretsOui
La RFC 9562 dit de ne pas supposer que les UUID sont difficiles à deviner, ni de les utiliser comme capacités de sécurité. Pour les secrets, utilisez un jeton issu d'un générateur cryptographique, et contrôlez l'accès à chaque requête.

Générateur UUID : questions et réponses

Comment générer un UUID ?

Ouvrez cette page : un UUID v4 aléatoire est prêt à copier, et le bouton « Nouvel UUID » en crée un autre. Choisissez v7 pour l'utiliser comme générateur d'UUID v7, indiquez un nombre pour en créer jusqu'à 10 000 à la fois, et choisissez un format comme les accolades ou Base64url. Dans le code, crypto.randomUUID() en JavaScript, uuid.uuid4() en Python et Guid.NewGuid() en C# créent chacun un v4 en une ligne.

Que signifie UUID ?

Universally Unique Identifier, soit identifiant unique universel. C'est une valeur de 128 bits, écrite en 36 caractères comme 919108f7-52d1-4320-9bac-f847db4148a8, que les ordinateurs créent chacun de leur côté, sans registre central, en comptant tout de même sur son unicité. La RFC 9562 la définit. Microsoft appelle la même valeur un GUID, Globally Unique Identifier.

Un GUID est-il la même chose qu'un UUID ?

Oui, en pratique : les mêmes 128 bits et la même forme texte, et Guid.NewGuid() crée un UUID standard de version 4. Deux détails diffèrent. Sous .NET, les trois premiers groupes sont stockés en little-endian, si bien que les tableaux d'octets bruts sortent dans un autre ordre ; et SQL Server trie les valeurs uniqueidentifier en commençant par le dernier groupe. Pour générer un GUID, utilisez cette page comme générateur de GUID aléatoire : le texte copié fonctionne dans les deux mondes.

Quelle version d'UUID utiliser ?

La version 7 pour les clés de base de données et tout ce qui se trie, car elle commence par l'heure de création et garde les index compacts. La version 4 quand l'identifiant ne doit pas révéler sa date de création. La version 5 quand un même nom doit toujours donner le même identifiant. Évitez v1 pour les nouveaux projets : la RFC 9562 recommande v7 à la place, et un v1 peut contenir une vraie adresse MAC.

Peut-on obtenir deux fois le même UUID ?

Seulement par un hasard astronomiquement improbable, si le générateur est fiable. Un v4 a 122 bits aléatoires : environ 103 000 milliards d'UUID donnent une chance sur un milliard d'un seul doublon, et une chance sur deux en demande environ 2,7 trillions (2,7 × 10¹⁸). Les doublons réels viennent de générateurs défectueux, de machines virtuelles clonées ou de données copiées, pas des mathématiques.

Peut-on décoder un UUID ?

En partie. Tout UUID indique sa version et sa variante. Un v7 révèle aussi la milliseconde de sa création, et un v1 ou un v6 l'heure à 100 nanosecondes près, une séquence d'horloge et un identifiant de nœud, parfois une vraie adresse MAC. Un v4 ne contient que des bits aléatoires, et v3 et v5 des hachages qui ne permettent pas de retrouver le nom. Collez-en un dans l'onglet « Décoder et valider ».

Quelle est la longueur d'un UUID ?

128 bits, soit 16 octets. En texte, il fait 36 caractères : 32 chiffres hexadécimaux et 4 tirets, en groupes de 8-4-4-4-12. Sans tirets, il fait 32 caractères, entre accolades 38, avec le préfixe urn:uuid: 45, en Base64url 22 et en entier décimal jusqu'à 39 chiffres. Stockez-le de préférence dans un type UUID natif ou sur 16 octets plutôt qu'en texte.

Qu'est-ce qu'un GUID vide ou UUID Nil ?

La valeur dont les 128 bits sont à zéro : 00000000-0000-0000-0000-000000000000. La RFC 9562 l'appelle UUID Nil, et Guid.Empty de .NET est la même valeur, souvent utilisée pour signifier qu'aucun identifiant n'est défini. La RFC 9562 définit aussi l'UUID Max, entièrement à un, ffffffff-ffff-ffff-ffff-ffffffffffff, comme valeur sentinelle (.NET 9 : Guid.AllBitsSet). Aucun des deux n'est aléatoire : ne les utilisez jamais comme vrais identifiants.

L'UUID v7 est-il triable ?

Oui. Ses 48 premiers bits sont le temps Unix en millisecondes : trier des UUID v7 comme texte ou comme octets les trie donc par date de création, à la milliseconde près. Au sein d'une milliseconde, l'ordre dépend du générateur : celui-ci garde un lot strictement croissant, comme le décrit la section 6.2 de la RFC 9562. Le type uniqueidentifier de SQL Server fait exception : il compare d'abord le dernier groupe.

Peut-on utiliser un UUID comme mot de passe ou jeton d'accès ?

Non. La RFC 9562 déconseille de supposer que les UUID sont difficiles à deviner ou de les utiliser comme capacités de sécurité. Les versions basées sur le temps révèlent leur date de création, et celles basées sur un nom peuvent être recalculées. Pour les secrets, utilisez un jeton aléatoire issu d'un générateur cryptographique, et traitez les UUID comme des identifiants publics, avec un contrôle d'accès séparé. Pour les mots de passe, utilisez le générateur de mot de passe.

Les UUID créés ici sont-ils envoyés quelque part ?

Non. Ils sont créés dans votre navigateur avec crypto.getRandomValues, son générateur aléatoire cryptographiquement sûr, et les UUID collés sont décodés sur votre appareil. Rien de ce que vous générez ou collez ne nous est envoyé, ni à personne d'autre. Un lien de partage ne contient que ce que vous avez choisi : la version, le nombre et le format, le nom pour v5, ou les UUID collés dans le décodeur ; partagez-le donc comme vous partageriez ces données.

Il vous manque quelque chose ?Suggérez une fonction ou un nouvel outil

Outils associés