Générateur et décodeur de ULID

Qu’est-ce qu’un ULID ?

Un ULID est un identifiant de 26 caractères qui porte en lui l’heure de sa création. Les 10 premiers caractères sont un compte de 48 bits de millisecondes depuis 1970 ; les 16 suivants sont 80 bits d’aléa. Les deux moitiés s’écrivent dans le base32 de Crockford, un alphabet formé des dix chiffres et de vingt-deux lettres, qui laisse de côté le I, le L, le O et le U précisément parce que ce sont ceux que l’on lit de travers.

L’intérêt de placer l’horloge en tête, c’est que trier le texte revient à trier par date. Un UUID version 4 n’est que du hasard : une table indexée dessus disperse ses écritures dans tout l’index, là où des identifiants croissants gardent les nouvelles lignes ensemble. C’est le même raisonnement qui a donné l’UUID version 7, normalisé par la RFC 9562 en 2024 et préférable dès qu’on peut l’employer — le ULID est antérieur, n’est pas une norme de l’IETF, et vaut surtout d’être connu parce que beaucoup de logiciels en produisent déjà.

Le format tient aussi là où un UUID ne tient pas : 26 caractères contre 36, sans traits d’union, insensible à la casse, et bien plus robuste que l’hexadécimal lorsqu’il faut le dicter ou le recopier depuis un écran.

Comment s’en servir

1. Choisissez combien il vous en faut, puis copiez. Jusqu’à cent d’un coup, tirés de la source d’aléa cryptographique de votre navigateur. Copiez-en un seul, ou tout le lot ligne par ligne.
2. Laissez la case d’ordre cochée, sauf si vous savez vouloir le contraire. Elle fait que les identifiants créés dans la même milliseconde s’incrémentent au lieu d’être tirés séparément, ce qui est exactement ce qui met un lot dans l’ordre de sa création.
3. Collez n’importe quel ULID dans le second champ pour le relire. Vous obtenez l’instant de création dans votre propre fuseau, la moitié aléatoire, la forme canonique et les mêmes bits écrits en hexadécimal.

Trois choses que les autres outils ULID ratent

La première : un lot d’ULID n’est presque jamais trié. Vingt-six caractères de base32 ne sont dans l’ordre que si les valeurs derrière croissent, et deux identifiants créés dans la même milliseconde partagent leur horodatage : c’est donc la moitié aléatoire qui décide. Or deux tirages indépendants sont aussi probables dans un sens que dans l’autre — c’est un pile ou face par construction, pas un raté occasionnel — et c’est bien ce que donne la mesure. Sur 20 000 appels dans une seule milliseconde, le taux d’inversion s’établit à 49,9, 49,6 et 50,2 pour cent pour trois flux d’aléa différents, et à 49,6 et 50,1 pour cent sur deux passages contre l’implémentation de référence en JavaScript, en temps réel. Sa fabrique monotone ramène tout cela à zéro. Puisque le tri est la seule vraie raison de préférer ce format, le comportement ordonné est activé par défaut ici, et c’est une case à cocher plutôt qu’un présupposé.

La deuxième : le dépassement. Vingt-six caractères base32 portent 130 bits, un ULID en fait 128, donc le premier caractère ne peut aller que de 0 à 7 — le plus grand ULID possible est 7ZZZZZZZZZZZZZZZZZZZZZZZZZ. La spécification demande que toute tentative de décoder un ULID plus grand soit rejetée par toutes les implémentations, justement pour éviter les bogues de dépassement. En essayant les trente-deux premiers caractères possibles contre l’implémentation de référence, son validateur répond vrai pour chacun tandis que son propre décodeur lève une erreur sur vingt-quatre : trois quarts des chaînes qu’elle déclare valides ne sont pas des ULID. Ici, ce cas a son propre verdict au lieu de passer inaperçu.

La troisième : la transcription. Crockford a conçu cet alphabet pour que les lettres écartées soient récupérables à la lecture — I et L se décodent en 1, O en 0, et la casse est ignorée. L’implémentation de référence rejette les trois et fournit à part une fonction de réparation qu’il faut appeler soi-même : un ULID recopié depuis une capture d’écran échoue donc sans raison valable. Cet outil les résout et vous le dit, ce qui n’est pas la même chose que les résoudre en silence.

Limites assumées

L’horodatage ne vaut que ce que vaut l’horloge de la machine qui a produit l’identifiant. Un ULID indique l’heure que cette machine croyait ; sur un appareil mal réglé, ou revenu en arrière à cause d’une seconde intercalaire ou d’une correction NTP, la valeur est fausse et rien dans le format ne le signale. Le tri est un confort, pas une piste d’audit.

La moitié aléatoire n’est pas une signature. N’importe qui peut fabriquer un identifiant avec l’horodatage de son choix : le format n’a ni secret ni somme de contrôle, donc un ULID ne prouve rien sur son auteur ni sur sa date. À traiter comme un nom, jamais comme une preuve.

La conversion ULID vers UUID que tous les outils proposent est exacte, mais le résultat n’est pas un UUID. Ce sont les mêmes 128 bits écrits en hexadécimal, et un UUID réserve quatre bits à son numéro de version et deux à sa variante, dont la moitié aléatoire d’un ULID ignore tout. Environ un ULID sur soixante-quatre tombe par hasard sur des valeurs qui passeraient pour un UUID version 4 ; les autres sont des chaînes hexadécimales en forme d’UUID qu’aucun analyseur conforme n’acceptera. Cette page affiche l’hexadécimal et vous dit dans quel cas vous êtes.

Enfin, l’ordre monotone vaut par générateur, pas globalement. Deux serveurs produisant des identifiants dans la même milliseconde s’entremêleront selon leurs moitiés aléatoires, et rien ne les coordonne. Dans un onglet, un processus ou un pool de connexions, l’ordre tient ; entre machines, non.

Pourquoi est-ce gratuit ?

Tout se passe dans votre navigateur. Les bits aléatoires viennent de votre propre source cryptographique, l’horloge est la vôtre, et aucun identifiant n’est envoyé où que ce soit — ce qui compte plus que d’habitude ici, puisqu’un identifiant qu’un serveur a vu passer n’est plus tout à fait à vous pour servir de jeton.

Pas de compte, pas de limite, pas de filigrane : il n’y a aucun coût serveur à récupérer.