ToolDecks UUID-verktyg täcker alla viktiga format för unika identifierare på ett ställe. Samlingen inkluderar: UUID v4 Generator för slumpmässiga, kryptografiskt starka ID; UUID v7 Generator för primärnycklar sorterbara efter tidsstämpel; UUID v1 Generator för tids- och MAC-adressbaserade identifierare; UUID v2 Generator för äldre DCE-system; UUID v3 Generator för deterministiska MD5-baserade ID; ULID Generator för kompakta, sorterbara strängar; NanoID Generator för korta URL-säkra tokens; CUID Generator för det ursprungliga kollisionsresistenta formatet; CUID2 Generator för dess moderna efterföljare; och UUID Decoder för att inspektera befintliga identifierare. Alla verktyg körs helt i webbläsaren med Web Crypto API — inga data skickas till någon server, inget konto krävs.
Vad är UUID- och unika ID-verktyg?
UUID (Universally Unique Identifier) är en 128-bitars identifierare standardiserad i RFC 9562 (tidigare RFC 4122). Skriven som 32 hexadecimala tecken i formatet 8-4-4-4-12 ser en UUID ut så här: 550e8400-e29b-41d4-a716-446655440000. Standarden definierar flera versioner, var och en med en annan strategi för att garantera unikhet: slumpmässiga tal, tidsstämplar eller deterministisk hashning.
UUID:er designades för att distribuerade system ska kunna generera identifierare utan en central koordinator. Oavsett om du tilldelar en primärnyckel i PostgreSQL, genererar en sessionstoken i en webbapp eller namnger en fil i objektlagring — låter UUID:er varje nod i ditt system skapa ett globalt unikt ID självständigt, med en kollisionssannolikhet så låg att den är försumbar i praktiken.
Utöver UUID-standarden har flera alternativa unika ID-format uppstått för att hantera specifika begränsningar: ULID och UUID v7 lägger till lexikografisk sorterbarhet för effektivare databasindexering; NanoID minskar storleken för URL:er och kakor; CUID2 prioriterar fingeravtrycksbaserad kollisionsresistens för generering i stora volymer på klientsidan.
Varför använda UUID-verktyg på ToolDeck?
ToolDecks UUID-verktyg körs helt i webbläsaren. Inga API-anrop, ingen serverbearbetning, ingen dataloggning. Varje generator använder Web Crypto API (crypto.getRandomValues) för kryptografiskt stark entropi — samma källa som webbläsare använder för TLS-nyckelmaterial.
🔐Kryptografiskt stark entropi
Alla slumpmässighetsbaserade generatorer (UUID v4, NanoID, CUID2) använder crypto.getRandomValues, inte Math.random. Utdata är lämplig för säkerhetskänsliga användningsfall som sessionstoken och API-nycklar.
📦Alla viktiga ID-format på ett ställe
UUID v1 till v7, ULID, NanoID, CUID och CUID2 — alla format en utvecklare behöver, med möjlighet till bulkgenerering och kopiering med ett klick.
🔍Avkoda och inspektera befintliga ID
UUID Decoder extraherar version, variant, tidsstämpel och nodfält från valfri UUID. Användbart för felsökning, revision och förståelse av äldre ID i kodbasen.
⚡Ingen konfiguration, fungerar offline
Ingen installation, ingen registrering, inga körtidsberoenden. Öppna sidan och generera. Alla verktyg fungerar offline när sidan är laddad — användbart i luftgapade miljöer eller begränsade nätverk.
Användningsfall för UUID-verktyg
Unika identifierare förekommer på varje lager av stacken. Så här använder olika roller UUID-genereringsverktyg:
Databasprimitärnycklar
Backendutvecklare tilldelar UUID v4 eller UUID v7 som primärnycklar i PostgreSQL, MySQL och MongoDB. UUID v7:s tidsstämpelprefix håller rader fysiskt ordnade på disk, vilket undviker siddelningar vid insättningsintensiva arbetsbelastningar.
Frontendtillstånd och komponent-ID
Frontendutvecklare använder NanoID eller UUID v4 för att generera stabila React-nycklar för dynamiskt skapade listobjekt, dialog-ID för ARIA-tillgänglighetsattribut och idempotency-tokens för formulärinlämningar.
Distribuerade eventströmmar
I händelsedrivna system behöver varje händelse ett globalt unikt, sorterbart ID. DevOps- och plattformsingenjörer använder ULID eller UUID v7 så att Kafka-konsumenter, loggaggregatorer och revisionsspår kan sorteras efter skapandetid utan ett sekundärt tidsstämpelfält.
Testdatagenerering
QA-ingenjörer bulkgenererar UUID-satser för att fylla testdatabaser med realistiska, icke-sekventiella ID. Deterministiska UUID v3 eller v5 låter dem återskapa samma ID från en känd indata — användbart för reproducerbara testfixtures.
Korrelations-ID i mikrotjänster
Att bifoga ett UUID till varje inkommande HTTP-förfrågan och propagera det via tjänstanrop (X-Request-ID-huvud) gör att distribuerade spårningssystem kan korrelera loggar över tjänster. UUID v4 är de facto-standarden för förfrågningskorrelation.
Namngivning av tillgångar och resurser
Objektlagringsnycklar (S3, GCS, Cloudflare R2) och CDN-tillgångsfilnamn bäddar ofta in ett UUID för att förhindra cachekollisioner och URL-gissning. NanoID:s kompakta 21-teckensformat minskar URL-längden jämfört med fullständiga 36-teckens UUID:er.
UUID-versions- och formatreferens
Tabellen nedan jämför alla UUID-versioner med de mest använda UUID-alternativen. Använd den för att snabbt identifiera vilket format som passar dina krav.
| Identifierare | Algoritm | Sorterbar | Deterministisk | Bäst för |
|---|
| UUID v4 | Slumpmässig (CSPRNG) | — | — | Allmänna ID, sessionstoken, primärnycklar |
| UUID v7 | Unix ms-tidsstämpel + slumpmässig | ✓ | — | Sorterbara primärnycklar, distribuerade händelse-ID (RFC 9562) |
| UUID v1 | Tidsstämpel + MAC-adress | ✓ | — | Tidsordnade ID, enkelnodssystem, äldre kompatibilitet |
| UUID v3 | Namnutrymme + namn + MD5 | — | ✓ | Reproducerbara ID från kända indata (DNS, URL:er) |
| UUID v5 | Namnutrymme + namn + SHA-1 | — | ✓ | Samma som v3 med starkare hash; föredra v5 framför v3 |
| UUID v2 | Tidsstämpel + DCE UID/GID | ✓ | — | Äldre POSIX/DCE-miljöer; undvik för nya projekt |
| ULID | Tidsstämpelprefix + slumpmässig | ✓ | — | Sorterbara ID, URL-säkra, utan bindestreck (26 tecken) |
| NanoID | Slumpmässig (CSPRNG), URL-säkert alfabet | — | — | Korta ID för URL:er, kakor, HTML-attribut (21 tecken) |
| CUID2 | Fingeravtryck + tidsstämpel + slumpmässig | — | — | Storskalig klientgenerering, kollisionsresistent |
UUID v3 och v5 är deterministiska: samma namnutrymme + namn producerar alltid samma UUID. Alla andra format genererar ett nytt värde vid varje anrop.
Hur du väljer rätt UUID-verktyg
Rätt identifierare beror på dina krav på sorterbarhet, storlek och determinism. Använd den här beslutsguiden:
- 1
Om du behöver ett allmänt unikt ID utan särskilda krav → UUID v4 Generator - 2
Om du behöver ID som sorteras kronologiskt och är kompatibla med UUID-standarden → UUID v7 Generator - 3
Om du behöver tidsordnade ID med inbäddad tidsstämpel för enkelnodssystem eller system med låg parallellitet → UUID v1 Generator - 4
Om du behöver sorterbara ID som är URL-säkra och bindestrecksfria → ULID Generator - 5
Om du behöver kompakta, URL-säkra ID kortare än ett fullständigt UUID → NanoID Generator - 6
Om du genererar många ID på klientsidan och behöver stark kollisionsresistens → CUID2 Generator - 7
Om du behöver CUID v1-formatet för kompatibilitet med befintliga system byggda på den ursprungliga specifikationen → CUID Generator - 8
Om du behöver reproducera samma ID deterministiskt från ett namnutrymme och ett namn → UUID v3 Generator - 9
Om du arbetar med äldre DCE- eller POSIX-system som kräver v2-identifierare → UUID v2 Generator - 10
Om du har ett befintligt UUID och vill inspektera dess version, variant eller tidsstämpel → UUID Decoder
Både UUID v7 och ULID erbjuder tidsstämpelprefix med millisekundsprecision och lexikografisk sorterbarhet. Den viktigaste skillnaden: UUID v7 använder standard-UUID-formatet (8-4-4-4-12, 36 tecken) för maximal ekosystemkompatibilitet, medan ULID använder en anpassad Base32-kodning (26 tecken, URL-säker, inga bindestreck). Om din databas, ORM eller ramverk stöder UUID-kolumner nativt, föredra UUID v7. Om du behöver kortare ID utan ramverksbegränsningar är ULID mer kompakt.
Vanliga frågor
Vad är ett UUID?
UUID (Universally Unique Identifier) är ett 128-bitarsvärde standardiserat i RFC 9562. Det skrivs som 32 hexadecimala siffror i fem grupper separerade av bindestreck: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Standarden definierar flera versioner med olika unikhetsstrategier — slumpmässig (v4), tidsstämpelbaserad (v1, v7) eller namnbaserad deterministisk (v3, v5).
Vad är skillnaden mellan UUID v4 och UUID v7?
UUID v4 fyller alla 122 icke-fasta bitar med slumpmässiga data från en kryptografiskt säker källa. UUID v7 kodar en 48-bitars Unix-millisekunds-tidsstämpel i de första 48 bitarna, följt av slumpmässiga bitar. Resultatet: UUID v7 sorteras kronologiskt som vanliga strängar, vilket håller databas-B-trädindex ordnade vid infogning. UUID v7 lades till i RFC 9562 (april 2024) och är det föredragna valet för nya databasprimitärnycklar.
Är UUID v4-värden kryptografiskt säkra?
UUID v4-värden genereras med en kryptografiskt säker pseudoslumpmässig nummergenerator (CSPRNG). De är lämpliga som icke-gissbara tokens — sessions-ID, lösenordsåterställningslänkar och liknande. Ett UUID är dock inte en hemlighet i sig: det har ingen HMAC, inget förfallodatum och ingen bindning till en specifik användare. Behandla UUID som ogenomskinliga identifierare, inte som autentiseringsuppgifter.
Kan två olika system generera samma UUID?
Kollisionssannolikheten för UUID v4 är ungefär 1 av 2^122 per par. För att ha 50% chans för någon kollision behöver du generera ungefär 2,7 × 10^18 UUID — långt bortom vad något verkligt system producerar. UUID v1 och v7 bäddar dessutom in en tidsstämpel och/eller slumpmässiga bitar, vilket gör oavsiktlig kollision ännu mer osannolik. För alla praktiska ändamål kommer UUID från separata system inte att krocka.
Varför är UUID 36 tecken långa?
Ett UUID är 128 bitar = 16 byte. Kodat som hexadecimalt är det 32 tecken. UUID-formatet lägger till 4 bindestreck på fasta positioner (efter grupper om 8, 4, 4 och 4 hexsiffror) för att förbättra läsbarheten och göra versions- och variantbitar lätta att se visuellt, vilket ger totalt 36 tecken. Bindestrecken bär ingen data.
Vad är ULID och hur skiljer det sig från UUID?
ULID (Universally Unique Lexicographically Sortable Identifier) är en 128-bitars identifierare kodad i Crockford Base32 (26 tecken, skiftlägesokänslig, inga bindestreck). De första 48 bitarna kodar Unix-tid i millisekunder; de återstående 80 bitarna är slumpmässiga. ULID:er sorteras korrekt som vanliga strängar och är mer kompakta än UUID:er. De är inte en del av UUID RFC — de använder en annan kodning och saknar versions-/variantfälten i UUID:er.
Bör jag använda UUID eller auto-inkrement-heltal som primärnycklar?
Auto-inkrement-heltal är sekventiella, kompakta och indexvänliga men kräver en central koordinator (databasen) för tilldelning — vilket misslyckas i distribuerade system och avslöjar radantal. UUID:er (särskilt v7 eller ULID) kan genereras på klientsidan utan en databasresa, vilket möjliggör optimistiska infogningar och distribuerade skrivningar. Avvägningen är lagring (16 byte vs. 4–8 byte) och något lägre indexlokalitet för slumpmässiga UUID:er (v4). UUID v7 och ULID eliminerar indexlokalitetsproblemet genom att använda tidsstämpelprefix.
Vad är skillnaden mellan UUID v3 och UUID v5?
Både UUID v3 och v5 är deterministiska: de producerar alltid samma UUID för samma namnrymd + namnpar, vilket gör dem användbara för att generera reproducerbara ID för saker som DNS-poster, URL:er eller objektidentifierare. Den enda skillnaden är hashalgoritmen: v3 använder MD5 (128 bitar, äldre), v5 använder SHA-1 (160 bitar, trunkerad till 128 bitar). Föredra UUID v5 för nya projekt — SHA-1 är starkare än MD5, även om ingen version används som kryptografisk hash.