ULID-generator

Hva ULID-generatoren gjør

Denne siden lar deg generere unike identifikatorer i ULID-formatet. Du velger ULID som format, angir hvor mange ID-er du trenger – et heltall mellom 1 og 100 – og verktøyet produserer umiddelbart en liste med de forespurte ULID-strengene. Hver streng er 26 tegn lang, består utelukkende av Crockfords base32-alfabet, og inneholder verken bindestreker eller store/små bokstaver som kan forveksles.

Når listen er generert, vises statusmeldingen «Generert.» Før du trykker på genereringsknappen, står det «Klar.». Når du kopierer hele listen ved ett klikk, endres statusen til «Alle kopiert!». Du kan også klikke på en enkelt ULID for å kopiere akkurat den til utklippstavlen. All generering skjer lokalt i nettleseren din ved hjelp av crypto.getRandomValues() – ingen data sendes til noen server.

Hva skiller denne siden fra andre UUID-verktøy

De fleste verktøy for ID-generering tilbyr UUID v4 med bindestreker og store bokstaver, og gir deg brytere for å endre på formatet. Denne siden gjør noe annet. ULID gir identifikatorer som er kortere enn UUID (26 tegn mot 36), og som bare bruker Crockfords base32-alfabet. Det betyr at de er uavhengige av store og små bokstaver og helt uten bindestreker. ULID-er er leksikografisk sorterbare etter opprettelsestidspunktet, fordi de første 10 tegnene koder et tidsstempel med millisekundpresisjon.

Siden tilbyr ingen brytere for store bokstaver eller bindestreker – fordi ULID per definisjon er case‑insensitiv og ikke har noen bindestreker. Det er dette som gjør verktøyet spesialisert og forskjellig fra en generisk UUID-generator. Du får rett og slett en ren, konsistent ULID uten mulighet til å tukle med formatet. Det sparer tid og eliminerer forvirring om hva som er gyldig.

ULIDs interne struktur

En ULID er en 128-biters verdi, akkurat som en UUID v4, men fordelingen er annerledes. De første 10 tegnene i ULID-strengen representerer et 48-biters tidsstempel med millisekundpresisjon. De neste 16 tegnene utgjør en 80-biters tilfeldig komponent. Totalt blir det 26 tegn i Crockford base32.

Tidsstemplet er antall millisekunder siden Unix-epoken (1. januar 1970 00:00:00 UTC). Fordi tidsstemplet utgjør den første delen av strengen, vil ULID-er generert på ulike tidspunkter sortere kronologisk når de sorteres som tekststrenger. Det er dette som gjør ULID spesielt nyttig som primærnøkkel i databaser: nye rader får ID-er som er større enn de forrige, noe som forbedrer B‑tres ytelse ved innsetting.

Den tilfeldige komponenten på 80 bit gir 2^80 mulige verdier. Sammen med den tidsbaserte delen reduserer dette kollisjonssannsynligheten dramatisk, selv ved høy genereringshastighet. Det er imidlertid viktig å merke seg at ULID ikke garanterer streng rekkefølge for ID-er generert i samme millisekund. Da kan den tilfeldige komponenten gjøre at to ID-er med samme tidsstempel ikke nødvendigvis sorteres i den rekkefølgen de ble generert.

Crockford base32 og lesbarhet

Crockford base32 er et 32-tegns alfabet utviklet for å være lett å lese og skrive av mennesker, samtidig som det unngår forveksling. Alfabetet består av sifrene 0-9 og bokstavene A-Z, men utelater bokstavene I, L, O og U. Grunnen er at I og L lett kan forveksles med 1, O med 0, og U med V. Dermed reduseres risikoen for tastefeil når noen manuelt skriver inn en ULID.

Fordi alfabetet er det samme uansett om du bruker store eller små bokstaver, er ULID case‑insensitiv. Du kan skrive den inn med store, små eller blandede bokstaver, og systemet vil tolke det likt. Dette er en fordel i API-er og databaser der store/små bokstaver kan være et problem.

I tillegg består Crockford base32-alphabetet utelukkende av tegn som er URL-sikre i henhold til RFC 3986. Det betyr at du kan sette en ULID direkte inn i en URL uten å måtte prosentkode noe. Sammenlign med UUID v4 som inneholder bindestreker og bokstaver som kan kreve escaping i visse kontekster.

Sammenligning med UUID v4 og UUID v7

For å forstå hvorfor ULID er et godt valg, er det nyttig å sammenligne med de to vanligste UUID-variantene.

UUID v4 er rent tilfeldig og gir ingen tidsinformasjon. Det gjør den mindre egnet som primærnøkkel i databaser med høy innsettingshastighet, fordi tilfeldige nøkler fører til mange side-splittinger i B‑trær.

UUID v7 introduserer et tidsstempel, men bevarer det tradisjonelle 36-tegns formatet med bindestreker. ULID er 10 tegn kortere, har ingen bindestreker, og bruker et alfabet som er mer lesbart for mennesker. For applikasjoner der hvert tegn teller – for eksempel i URL-er, QR-koder eller i begrensede skjemafelter – er ULID et bedre valg.

Sorteringsatferd og kollisjonssannsynlighet

Siden tidsstemplet er de første 10 tegnene, vil ULID-er som standard sortere kronologisk når du sorterer dem som strenger. Dette er en enorm fordel i distribuerte systemer der du ofte trenger å kunne ordne hendelser etter tid uten en egen tidsstempelkolonne. Du kan for eksempel lagre ULID som primærnøkkel og likevel få hendelser i riktig rekkefølge.

Men det er en viktig begrensning: ULID garanterer ikke streng ordning for ID-er generert i samme millisekund. Innenfor ett millisekund er rekkefølgen bestemt av den tilfeldige komponenten. For de fleste bruksområder er dette akseptabelt, fordi det er svært sjeldent at mange ID-er genereres i nøyaktig samme millisekund. Men hvis du har en ekstremt høy genereringsrate (hundretusenvis per sekund) og trenger garantert ordning, bør du vurdere en annen løsning.

Kollisjonssannsynligheten er svært lav. Med 80 bit tilfeldig data og et 48-biters tidsstempel, er sannsynligheten for å få en duplikat ULID innenfor ett millisekund omtrent 1 av 2^80, altså astronomisk liten. I praksis kan du generere milliarder av ULID-er uten å få en kollisjon, forutsatt at klokken din er nøyaktig og at du ikke genererer mer enn én per millisekund per node. Ved høyere rater (mange per millisekund) øker kollisjonssannsynligheten, men den forblir ekstremt lav i de fleste realistiske scenarioer.

Bruk i databaser og distribuerte systemer

En av de viktigste bruksområdene for ULID er som primærnøkkel i databaser, spesielt i systemer med høy skrivehastighet. Fordi ULID-er er tidsbaserte, vil nye nøkler være større enn de forrige. Det betyr at databasens B‑tre kan sette inn nye rader i rekkefølge uten å måtte omorganisere store deler av indeksen. Dette gir betydelig bedre skriveytelse sammenlignet med tilfeldige UUID v4-nøkler, som spres tilfeldig over hele indeksen.

I distribuerte systemer der flere noder genererer ID-er uavhengig, er ULID også et godt valg. Hver node har sin egen klokke, og den 80-biters tilfeldige komponenten sikrer at ID-er fra ulike noder med samme tidsstempel likevel er unike. Du trenger ingen sentral koordinator for å tildele ID-er. Forutsatt at klokkene er nøyaktige (med millisekundpresisjon), vil ID-er fra forskjellige noder sortere kronologisk når de slås sammen – nesten alltid.

API-designere setter også pris på ULID fordi det er kort, lesbart og URL-sikkert. En URL som /api/v2/users/01ARZ3NDEKTSV4RRFFQ69G5FAV inneholder en ULID som er lett å lese og lime inn, uten fare for at bindestreker blir tolket på feil måte. Mange utviklere synes ULID er mer menneskevennlig enn UUID, spesielt ved feilsøking og logging.

Ofte stilte spørsmål (FAQ)

Kan jeg legge til bindestreker i en ULID? Nei. ULID-formatet har ingen bindestreker per definisjon. Hvis du trenger bindestreker for lesbarhet, må du selv formatere dem, men da er det ikke lenger en gyldig ULID. Verktøyet på denne siden produserer kun rene ULID-er uten bindestreker.

Er ULID case‑sensitiv? Nei. Crockford base32 tolker store og små bokstaver likt. Du kan skrive inn en ULID med store eller små bokstaver, og den vil fungere. Verktøyet genererer alltid store bokstaver, men du kan konvertere dem til små om du foretrekker det.

Hvorfor kan jeg bare generere mellom 1 og 100 ULID-er om gangen? Dette er en praktisk begrensning for å unngå at brukere ved et uhell genererer svært store lister som kan påvirke ytelsen. For de fleste formål er 100 ID-er mer enn nok. Hvis du trenger flere, kan du generere flere ganger.

Garantierer ULID at ID-er kommer i kronologisk rekkefølge? ULID garanterer leksikografisk sorterbarhet basert på tidsstemplet. For ID-er generert i forskjellige millisekunder vil sorteringen være kronologisk. For ID-er i samme millisekund er rekkefølgen tilfeldig. Det er ingen garanti for at den første ID-en som ble generert i millisekundet, er den som sorterer først.

Hvordan genereres ULID lokalt i nettleseren? Verktøyet bruker nettleserens crypto.getRandomValues()-metode for å generere de 80 tilfeldige bitene. Tidsstemplet hentes fra Date.now(). Hele prosessen skjer i nettleseren uten nettverkstrafikk. Ingen data sendes til serveren, noe som beskytter personvernet og muliggjør offline-bruk.