Aller au contenu principal
ToolsByUs

Générateurs

Ces générateurs produisent des identifiants et des valeurs de substitution dans votre navigateur. Le hasard vient de la Web Crypto API — la même source cryptographique que la plateforme utilise pour ses clés — plutôt que de Math.random ou d’un serveur qui vient de voir chaque identifiant qu’il vous a attribué.

12 outils100 % local

Convertir

Analyser

Générer

Quand utiliser un outil générer dans le navigateur ?

Un générateur semble être le seul type d’outil pour lequel l’endroit où le travail s’effectue ne peut pas avoir d’importance. Il en a deux fois.

La première raison est qu’un générateur côté serveur a vu chaque identifiant qu’il vous a donné. Si ceux-ci deviennent des clés primaires, des clés d’API, des tokens d’invitation ou quoi que ce soit d’autre doté d’une autorité, un tiers détient désormais une liste de ces identifiants. Ce risque a peu de chances d’être exploité, il n’en reste pas moins une exposition entièrement évitable, car le navigateur dispose en interne d’une source de hasard cryptographique tout à fait correcte.

La seconde est la qualité. Un nombre décourageant de générateurs en ligne appellent Math.random(), un PRNG rapide et non cryptographique. Sa sortie est assez uniforme pour paraître aléatoire et reste prévisible à partir d’une courte suite de valeurs antérieures. Pour un jeu d’essai, c’est inoffensif. Pour tout ce qui conditionne un accès, c’est une vulnérabilité, et rien dans la sortie ne distingue les deux cas. Ces outils utilisent exclusivement crypto.getRandomValues().

Le choix entre les versions d’UUID est la décision qui mérite le plus d’être bien prise, et elle se prend généralement par hasard. v4 — hasard pur — est le défaut presque partout, et c’est une piètre clé primaire à grande échelle pour une raison structurelle : les valeurs aléatoires se dispersent dans un index B-tree, chaque insertion touche une page différente, le taux de succès du cache s’effondre et l’index se fragmente. Les équipes découvrent généralement cela comme une lente dégradation inexpliquée du débit d’écriture, quelque part après les premiers millions de lignes.

v7 corrige cela en plaçant un horodatage en millisecondes dans les 48 bits de tête, si bien que des identifiants générés à peu de temps d’intervalle se trient l’un près de l’autre et que les insertions s’ajoutent à l’extrémité chaude de l’index. C’est le défaut qui convient pour des clés de base de données selon la RFC 9562. Le compromis est réel et mérite d’être énoncé : un identifiant v7 publie sa propre heure de création à quiconque peut le lire, si bien que pour un identifiant public où cela est sensible, v4 reste le bon choix.

v1 est inclus par souci d’exhaustivité et pour lire des données anciennes. Il encode un horodatage et, dans sa forme d’origine, l’adresse MAC de la machine génératrice — voilà pourquoi il est tombé en désuétude, et pourquoi savoir en inspecter un est plus utile que savoir en créer un. Si vous devez convertir une valeur générée vers une autre représentation, l’outil Base64 est à côté, et le Formateur JSON rangera un fichier de seed dans lequel vous avez collé des identifiants.

Questions fréquentes

Faut-il utiliser UUID v4 ou v7 pour une clé primaire de base de données ?

v7 pour tout ce qui va dans une colonne indexée. v4, c’est 122 bits de hasard, si bien que des insertions consécutives atterrissent à des points aléatoires d’un index B-tree : chaque insertion salit une page différente, l’index se fragmente, et le débit d’écriture se dégrade de façon mesurable à mesure que la table grandit. v7 place un horodatage en millisecondes de 48 bits dans les bits de poids fort, si bien que les valeurs nouvellement générées se trient à proximité les unes des autres et que les insertions s’ajoutent à la même région de l’index. v4 reste le bon choix quand l’identifiant est public et ne doit pas divulguer l’heure de création.

Ces UUID sont-ils réellement aléatoires, ou s’agit-il d’un PRNG amorcé ?

Ils viennent de crypto.getRandomValues(), le générateur cryptographiquement sûr de la Web Crypto API, qui puise dans le réservoir d’entropie du système d’exploitation. C’est la même source que celle du matériel de clé, et elle est catégoriquement différente de Math.random(), un PRNG rapide et non cryptographique dont la sortie est prévisible à partir de quelques valeurs antérieures.

Qu’est-ce que la RFC 9562 et change-t-elle quelque chose ?

La RFC 9562, publiée en mai 2024, a remplacé la RFC 4122 comme norme UUID. Elle a laissé v1 et v4 inchangés et ajouté les versions ordonnées dans le temps v6, v7 et v8. En pratique, le changement qui compte, c’est v7 devenu une norme plutôt qu’une collection d’extensions d’éditeurs incompatibles comme ULID et KSUID.

Puis-je en générer beaucoup d’un coup ?

Oui — la génération en lot va jusqu’à 10,000 par fournée, avec une sortie en lignes simples, en chaînes entre guillemets, en tableau JSON ou avec un séparateur de votre choix, prête à coller dans un fichier de seed ou une fixture. La génération est synchrone et quasi instantanée ; la limite pratique est ce que vous pouvez coller, pas ce que le navigateur peut produire.

Puis-je vérifier ce qu’est un UUID existant ?

Oui. Collez-en un dans l’inspecteur et il rapporte la version, la variante et — pour v1, v6 et v7 — l’horodatage embarqué, décodé en date lisible. C’est le moyen le plus rapide de savoir si les identifiants d’une table sont ordonnés dans le temps, et s’ils divulguent une heure de création que vous n’aviez pas l’intention de publier.

Que trouve-t-on d'autre sur ToolsByUs ?

ToolsByUs — Générateurs