Varför en ULID-generator är något annat
Till skillnad från UUID-formatet på samma verktyg producerar ULID identifikatorer som är kortare – 26 tecken mot UUID:s 36 – och som enbart använder Crockfords base32-alfabet. Det gör dem skiftlägesokänsliga och helt utan bindestreck. ULID är lexikografiskt sorterbara efter skapelsetid eftersom de första 10 tecknen kodar en tidsstämpel med millisekundsprecision. De är dessutom URL-säkra utan någon escaping. Sidan erbjuder inga växlingsknappar för versaler eller bindestreck – ULID har helt enkelt inga sådana. Den slumpmässiga delen upptar de återstående 16 tecknen (80 bitar), och det totala underliggande värdet är 128 bitar.
Intern struktur – hur en ULID är uppbyggd
En ULID är en 26-teckensträng som börjar med en tidsstämpel (första 10 tecknen) följd av en slumpmässig komponent. Tidsstämpeln utgörs av 48 bitar som lagrar antalet millisekunder sedan Unix-epoch (1970-01-01). Den slumpmässiga delen är 80 bitar lång. Tillsammans bildar de 128 bitar, precis som UUID – men representationen är kompaktare tack vare Crockfords base32-encoding.
Crockfords base32-alfabet består av siffrorna 0–9 och bokstäverna A–Z, med undantag för I, L, O och U. Dessa fyra bokstäver utesluts eftersom de lätt förväxlas med 1, 0 och V. Resultatet blir ett teckenförråd som är visuellt entydigt och skiftlägesokänsligt – en ULID fungerar lika bra med versaler som gemener. Eftersom alfabetet bara använder 32 tecken ryms varje tecken i 5 bitar (2⁵ = 32). 128 bitar ÷ 5 bitar per tecken = 25,6, vilket avrundas uppåt till 26 tecken – därav längden.
En typisk ULID kan se ut så här: 01ARZ3NDEKTSV4RRFFQ69G5FAV. De första 10 tecknen (01ARZ3NDEK) är tidsstämpeln, resten slump. Timestamp-värdet kan avkodas till ett datum och en tid med millisekunders noggrannhet.
Jämförelse med UUID v4 och UUID v7
Längd och läsbarhet
UUID v4 och v7 är båda 36 tecken långa (32 hexsiffror plus fyra bindestreck). ULID är 26 tecken, vilket sparar 28 % utrymme i en databasrad eller en URL. Dessutom saknas bindestreck, så strängen är enhetlig.
Sorterbarhet
UUID v4 är helt slumpmässigt – två på varandra genererade UUID har ingen inbördes ordning. UUID v7 är tidsbaserat (liknande ULID) men använder en annan struktur med 36 tecken och bindestreck. ULID är likt UUID v7 sorterbart efter skapelsetid, men med den skillnaden att ULID inte använder bindestreck och är skiftlägesokänsligt.
Slumpmässighet och entropi
UUID v4 har 122 bitar slump (6 bitar reserverade för version och variant). ULID har 80 bitar slump. Det är färre, men fortfarande tillräckligt för att kollisionsrisken vara försumbar i praktiken (se avsnittet om kollisionssannolikhet nedan). UUID v7 har 62 bitar slump (resten är tidsstämpel).
Representation
ULID använder Crockford base32, vilket ger tecken som är både URL-säkra och lätta att avläsa manuellt. UUID använder hexadecimalt (0–9, A–F) plus bindestreck. Publicerade tester visar att base32 är mindre felbenäget vid manuell inmatning eftersom det inte finns någon risk att blanda ihop exempelvis 1, l och I.
Sorteringsbeteende och klockbaserad ordning
Eftersom ULID inleds med en millisekundstidsstämpel sorteras strängarna lexikografiskt i samma ordning som de skapades. Det innebär att om du genererar 10 ULID:er efter varandra kommer de i listan att vara ordnade från äldsta till nyaste.
Begränsning: ULID garanterar inte strikt ordning för ID:n som genereras inom samma millisekund. Om din applikation skapar 1 000 ULID:er på samma millisekund kan den slumpmässiga delen göra att ordningen inte speglar den exakta tidsordningen. För de flesta användningsfall (t.ex. primärnycklar i databaser) är detta acceptabelt eftersom millisekundupplösningen ändå ger en tillräcklig kronologisk gruppering.
I praktiken beter sig ULID som en monotont ökande sekvens sett över tid, vilket är fördelaktigt för B-träd i databaser. Om du använder UUID v4 som primärnyckel sprids nya rader slumpmässigt över indexet, vilket leder till fragmentering och långsammare infogningar. ULID minskar detta problem dramatiskt.
Kollisionssannolikhet – hur stor är risken?
Den slumpmässiga delen är 80 bitar, vilket ger 2⁸⁰ ≈ 1,2 · 10²⁴ möjliga värden. För att beräkna sannolikheten för minst en kollision vid N genererade ULID:er använder man födelsedagsparadoxen. Approximationen är:
P(kollision) ≈ 1 - e^(-N² / (2 · 2⁸⁰))
För att uppnå 50 % sannolikhet för en kollision krävs ungefär 2^(80/2) = 2⁴⁰ ≈ 1,1 · 10¹² genererade ID:n. Det är mer än en biljon stycken. I de flesta verkliga system är antalet ID:n långt lägre, så risken är försumbar.
Värt att notera: Verktyget använder crypto.getRandomValues() i webbläsaren, vilket ger kryptografiskt stark slump. Det finns alltså inga svagheter i slumpproduktionen.
URL-säkerhet och användning i databaser
Alla tecken i Crockford base32 är unreserved i RFC 3986 – det vill säga de kräver ingen percent-encoding i URL:er. Siffror och bokstäver (förutom de uteslutna) är fullt kompatibla med webbstandarder. Du kan sätta en ULID direkt i en URL som https://exempel.se/produkt/01ARZ3NDEKTSV4RRFFQ69G5FAV utan att oroa dig för att tecknet + eller / (som förekommer i Base64) behöver kodas om.
I databasvärlden är ULID populärt som primärnyckel i tabeller där infogningsordningen har betydelse. Eftersom ULID är sorterbara efter tid undviker man de prestandaproblem som slumpmässiga UUID v4 orsakar i B-träd. Dessutom är det kortare – 26 tecken mot 36 – vilket minskar indexstorleken marginellt. För stora tabeller med miljarder rader kan den skillnaden bli märkbar.
Lokal generering och integritet
All ULID-generering sker lokalt i din webbläsare med hjälp av crypto.getRandomValues(). Ingenting skickas till någon server. Det innebär att dina data stannar hos dig – om du genererar ID:n för en känslig applikation behöver du inte oroa dig för att någon tredje part får tillgång till dem. Verktyget har ingen backend som loggar eller lagrar genererade värden. Detta står i kontrast till online-tjänster som genererar ID:n på serversidan, där integriteten kan vara svårare att verifiera.
FAQ – vanliga frågor
Kan jag få samma ULID två gånger? Teoretiskt ja, men praktiskt nej. Med 80 bitars slump och en kollisionssannolikhet på 50 % först efter drygt en biljon genererade ID:n är risken extremt låg. Verktyget garanterar unika värden inom samma generationsomgång, men upprepar du genereringen får du nya slumpmässiga strängar.
Varför är ULID sorterbar? De första 10 tecknen är en tidsstämpel som kodas med Crockford base32. När två ULID:er jämförs lexikografiskt motsvarar teckenordningen tidsordningen (förutsatt att de inte är skapade i exakt samma millisekund).
Hur många tecken är en ULID? 26 tecken, alltid. Det är en fast längd, till skillnad från exempelvis NanoID som kan variera.
Kan jag använda ULID som primärnyckel i MySQL/PostgreSQL? Ja, det går utmärkt. Eftersom ULID är sorterbar efter tid infogas nya rader i stort sett i stigande ordning, vilket minskar indexfragmentering. Du bör dock lagra dem som en textkolumn (VARCHAR(26)) eller konvertera till ett binärt format för bättre prestanda (128 bitar = 16 byte).
Är ULID versal/versal oberoende? Ja, Crockford base32 är skiftlägesokänsligt. Verktyget genererar alltid versaler, men du kan använda gemener och det blir samma ID. Detta gör ULID mindre känsligt för inmatningsfel.
Vad händer om jag försöker generera fler än 100 ULID:er? Verktyget accepterar bara ett heltal mellan 1 och 100 i räknaren. Om du anger ett värde utanför intervallet sker ingen generering. Du kan dock upprepa processen så många gånger du vill.
Varför finns det inga inställningar för versaler eller bindestreck? ULID-formatet har varken bindestreck eller krav på versaler. Eftersom det är skiftlägesokänsligt finns det ingen anledning att växla mellan stora och små bokstäver. Verktygets gränssnitt hålls därför enkelt och fokuserat.