Générateur d’ULID – Caractéristiques et fonctionnement
Ce qui distingue cette page des autres générateurs d’identifiants
Contrairement aux autres formats proposés sur le même outil, l’ULID produit des identifiants plus courts que les UUID (26 caractères au lieu de 36). Il utilise exclusivement l’alphabet Crockford en base32, ce qui le rend insensible à la casse et dépourvu de tirets. Les ULID sont triables lexicographiquement par l’instant de création, parce que les dix premiers caractères codent une estampille temporelle à la milliseconde. Ils sont également sûrs pour les URL, sans nécessiter d’encodage. Sur cette page, les boutons de bascule pour les majuscules ou les tirets sont absents, car l’ULID est par nature insensible à la casse et sans tirets. La composante aléatoire occupe les seize caractères restants (80 bits), et l’ensemble représente 128 bits.
L’utilisateur choisit le format ULID, indique le nombre d’identifiants voulu (entre 1 et 100), et l’outil génère instantanément une liste de chaînes uniques. Chaque identifiant peut être copié individuellement ou en bloc, et des messages d’état confirment les étapes (« Prêt », « Généré », « Tout copié »). Toute modification du format ou du nombre régénère la liste.
Structure interne d’un ULID
Un ULID est une chaîne de 26 caractères issue d’un entier de 128 bits, divisé en deux parties:
- 48 bits d’estampille temporelle (10 premiers caractères) – précision à la milliseconde.
- 80 bits aléatoires (16 caractères suivants) – générés par
crypto.getRandomValues()dans le navigateur.
Puisque la valeur temporelle occupe les bits de poids fort, deux ULID créés à des instants différents se classeront dans l’ordre chronologique si leurs estampilles diffèrent d’au moins une milliseconde. En revanche, si plusieurs identifiants sont produits exactement dans la même milliseconde, l’ordre n’est plus garanti: la seconde moitié aléatoire peut placer n’importe lequel avant un autre. Ce comportement est connu et documenté dans la spécification ULID.
Exemple d’un ULID: 01ARZ3NDEKTSV4RRFFQ69G5FAV. Les dix premiers caractères (01ARZ3NDEK) correspondent à une estampille, les seize suivants (TSV4RRFFQ69G5FAV) à la partie aléatoire. L’ensemble est représenté en base32 Crockford.
L’encodage Crockford et l’insensibilité à la casse
L’alphabet Crockford utilise les chiffres 0‑9 et les lettres A‑Z, à l’exception de I, L, O, U. Ces lettres sont omises pour éviter les confusions visuelles: I avec 1, L avec 1, O avec 0, U avec V. Puisque l’alphabet ne contient que 32 symboles, chaque caractère code 5 bits (32 = 2⁵). Ainsi 26 caractères × 5 bits = 130 bits, mais le dernier caractère n’utilise que 2 bits, pour un total de 128 bits utiles.
L’insensibilité à la casse signifie qu’un ULID écrit en minuscules (01arz3ndektsv4rrffq69g5fav) est identique à la version en majuscules. Les lettres minuscules sont converties lors de la lecture. Cela simplifie la saisie manuelle et évite les erreurs de frappe, surtout dans des contextes où l’utilisateur doit recopier un identifiant.
Les caractères ULID font tous partie des caractères non réservés de l’URI (RFC 3986), ce qui élimine tout besoin d’encodage‑pourcentage. Un identifiant ULID peut donc être placé directement dans une URL, un paramètre de requête ou un fragment sans transformation.
Comparaison avec UUID v4 et UUID v7
| Propriété | ULID | UUID v4 | UUID v7 |
|---|---|---|---|
| Longueur (caractères) | 26 | 36 | 36 |
| Tiret | non | oui (4) | oui (4) |
| Sensible à la casse | non | oui (hexadécimal) | oui (hexadécimal) |
| Tri temporel | oui (ms) | non | oui (ms) |
| Alphabet | Crockford base32 | hexadécimal (0‑9, A‑F) | hexadécimal (0‑9, A‑F) |
| Sécurité URL | intrinsèque | nécessite parfois encodage | nécessite parfois encodage |
L’UUID v7, proposé en standard, intègre également une estampille temporelle, mais il conserve les tirets et la représentation hexadécimale de 32 caractères. L’ULID offre une chaîne plus courte et insensible à la casse, deux avantages pour les API publiques et les interfaces utilisateur.
Tri, probabilité de collision et performances B‑arbre
Les ULID trient lexicographiquement par ordre chronologique tant que les estampilles diffèrent d’au moins une milliseconde. Dans une base de données utilisant un index B‑arbre, l’insertion de clés primaires triées améliore les performances – contrairement aux UUID v4 complètement aléatoires qui provoquent des éclatements de pages et une fragmentation. Les ULID se rapprochent du comportement des clés auto‑incrémentées, sans les problèmes de centralisation ni de prédictibilité.
La probabilité de collision dépend des 80 bits aléatoires. Pour une cadence de 1 000 identifiants par milliseconde, la probabilité de duplication est d’environ 10⁻¹⁶ par milliseconde, ce qui est négligeable dans la quasi‑totalité des applications. Toutefois, il n’existe aucune garantie que deux ULID générés dans la même milliseconde soient distincts – la spécification recommande de vérifier l’unicité au niveau applicatif si le risque est critique.
Génération locale et confidentialité
Tous les identifiants sont créés dans le navigateur de l’utilisateur à l’aide de crypto.getRandomValues(), une méthode sécurisée fournie par l’API Web Cryptography. Aucune donnée n’est envoyée vers un serveur. Cela garantit la confidentialité des identifiants générés, car même l’administrateur du site ne peut pas les connaître. En cas de perte de la page ou de rafraîchissement, les identifiants ne sont pas récupérables – il faut les avoir copiés.
Ce modèle contraste avec les générateurs serveur où l’horodatage et le hasard sont produits côté serveur. Ici, l’utilisateur garde le contrôle complet. La précision de l’estampille dépend de l’horloge du navigateur, ce qui peut être moins fiable qu’une horloge atomique, mais suffisant pour ordonner des identifiants générés en rafale dans un même onglet.
Foire aux questions (FAQ)
1. Puis‑je utiliser des ULID comme clés primaires dans une base de données SQL?
Oui. Leur nature triable améliore l’indexation B‑arbre. Veillez simplement à stocker la chaîne de 26 caractères (insensible à la casse) dans une colonne adaptée – souvent un CHAR(26) ou VARCHAR(26). Certaines bases autorisent un type binaire de 16 octets pour économiser de l’espace.
2. Quelle est la probabilité de générer deux ULID identiques en même temps?
Extrêmement faible. Avec 80 bits aléatoires, même en produisant 10 000 identifiants par milliseconde, la probabilité de collision reste inférieure à 10⁻¹⁰. Pour la plupart des usages, elle est négligeable.
3. L’ULID est‑il un standard officiel?
Il ne s’agit pas d’une norme RFC formelle comme UUID, mais d’une spécification ouverte (github.com/ulid/spec) largement adoptée. Il existe des implémentations dans de nombreux langages.
4. Pourquoi l’outil n’offre‑t‑il pas d’option pour les tirets ou la casse?
Parce que l’ULID ne comporte jamais de tirets et est insensible à la casse par définition. Proposer ces options serait trompeur et irait à l’encontre de la spécification.
5. Que se passe‑t‑il si je génère plus de 100 identifiants?
La page n’accepte qu’un nombre compris entre 1 et 100. Au‑delà, il faut faire plusieurs générations. Cette limite évite des listes trop longues à copier et à manipuler.
6. Puis‑je copier un ULID individuel sans devoir copier toute la liste?
Oui. Cliquez sur l’identifiant souhaité, il est copié dans le presse‑papiers. Le message « Copié » s’affiche brièvement. La copie de toute la liste se fait par le bouton « Tout copier », qui affiche alors « Tout copié ».
Tous les identifiants sont générés localement dans votre navigateur. Aucune donnée n’est transmise à un serveur. Les ULID produits respectent la spécification ULID (v1.0) et utilisent l’alphabet Crockford en base32.