Générateur et décodeur d'ULID | Des identifiants triables par le temps

Générez un ULID de 26 caractères en Crockford Base32 d'un clic, ou collez-en un pour en extraire l'heure de création. Les 10 premiers caractères portent un timestamp de 48 bits en millisecondes et les 16 derniers 80 bits d'aléa, si bien que le panneau décodé affiche la valeur en millisecondes, la date ISO 8601 UTC, la queue aléatoire en hexadécimal et la validité de la chaîne.

💡 À propos de cet outil

Un ULID ressemble à un bloc opaque de 26 caractères, mais la moitié de cette chaîne est un timestamp lisible dissimulé à la vue de tous. Le hic, c'est que ce timestamp est en Crockford Base32, ni en hexadécimal ni en décimal, donc regarder 01ARZ3NDEKTSV4RRFFQ69G5FAV ne vous dit pas quand il a été créé. Le décoder à la main revient à associer chacun des dix premiers caractères à une valeur de 5 bits, à les cumuler en base 32 puis à convertir le résultat en date.

Cet outil effectue cet aller-retour dans les deux sens. Quand vous collez un ULID, il valide la longueur, rejette tout caractère hors de l'alphabet Crockford (qui exclut volontairement I, L, O et U pour éviter les confusions visuelles), sépare le timestamp de la queue aléatoire et restitue l'heure de création sous forme de chaîne ISO 8601. La vue par segments colore distinctement la moitié temporelle et la moitié aléatoire, de sorte que la structure se saisit d'un coup d'œil, ce qu'un simple appel de bibliothèque ne donne pas.

🧐 Questions fréquentes

En quoi diffère-t-il d'un UUID v4 ? Un UUID v4, ce sont 122 bits d'aléa pur, sans ordre intrinsèque. Un ULID place en tête un timestamp de 48 bits en millisecondes : deux ULID créés à des instants différents se trient donc chronologiquement par simple comparaison de chaînes. UUID v7 a introduit plus tard un préfixe temporel similaire ; ULID le porte depuis sa spécification de 2016.

Pourquoi l'ordre alphabétique coïncide-t-il avec l'ordre temporel ? Parce que les bits de poids fort viennent en premier. Le timestamp occupe les 10 caractères de tête, donc trier les chaînes ULID par ordre alphabétique place les plus anciennes devant. Cela les rend pratiques comme clés primaires de base de données, où des insertions ordonnées gardent les index B-tree bien compacts.

Qu'est-ce que le Crockford Base32 ? C'est un alphabet en base 32 qui écarte les lettres I, L, O et U. I et L sont exclues pour ne pas se confondre avec 1, O avec 0, et U pour éviter de former des mots inappropriés. Restent les chiffres 0-9 et 22 lettres majuscules, soit 32 symboles, chacun codant 5 bits.

Deux ULID peuvent-ils entrer en collision ? Au sein d'une même milliseconde, la collision dépend des 80 bits aléatoires, qui offrent environ 1,2 × 10^24 combinaisons. Un choc pratique est astronomiquement improbable. L'aléa provient ici de crypto.getRandomValues du navigateur, et non d'un générateur pseudo-aléatoire faible.

Distingue-t-il majuscules et minuscules ? Non. Le décodage Crockford est insensible à la casse, l'entrée est donc normalisée en majuscules avant validation. Vous pouvez coller un ULID en minuscules et obtenir un décodage propre.

📚 Le saviez-vous : pourquoi 26 caractères

ULID a été publié par Alizain Feerasta en 2016 en réponse au fait qu'UUID v4 s'accordait mal aux bases de données triées, et le format réserve quelques particularités voulues qu'il vaut la peine de connaître. Le champ de timestamp fait 48 bits, ce qui couvre les dates jusqu'à l'an 10889 avant débordement : un souci que vous ne rencontrerez pas. L'encodage ajuste la valeur à exactement 26 caractères Crockford : 48 bits de timestamp et 80 d'aléa font 128 au total, la même largeur qu'un UUID, ce qui n'a rien d'un hasard puisqu'il a été conçu pour tenir dans la même colonne de 128 bits. S'il aboutit à 26 caractères et non aux 25 attendus de 128 bits divisés par 5, c'est que le premier caractère n'utilise que 3 de ses 5 bits, raison pour laquelle un ULID valide ne commence jamais par un caractère supérieur à 7.