UUID v2 Generator

Generate DCE Security UUID v2 with local domain and ID

Klicka på Generera för att skapa en UUID
Obs:UUID v2 kodar den lokala domänen och ID:t i UUID-strukturen
Note:UUID v2 är ett äldre format definierat för DCE-säkerhetskontexter. Det behövs sällan i moderna applikationer. För allmänna unika ID:n rekommenderas UUID v4.

Vad är UUID v2?

UUID v2 är DCE Security UUID-versionen, standardiserad som en del av Distributed Computing Environment (DCE)-specifikationen och refererad i RFC 4122. Den utökar UUID v1 genom att bädda in en POSIX-användar- eller gruppidentifierare (UID/GID) i tidsstämpelfältet.

Strukturen liknar UUID v1, men det 32-bitars time_low-fältet ersätts av en 32-bitars lokal identifierare (t.ex. ett POSIX UID) och ett 1-bytes local_domain-fält identifierar vilken typ av lokal ID det är. Tidsstämpeln trunkeras som ett resultat, vilket minskar dess precision och unikhetsgaran tier.

UUID v2 är extremt sällsynt i modern mjukvara. De flesta utvecklare behöver aldrig generera ett. Den här sidan dokumenterar formatet för fullständighetens skull och för att hjälpa till att avkoda UUID v2-värden som påträffas i äldre system.

UUID v2-struktur

Ett UUID v2 har samma 128-bitars, bindestreck-format som andra UUID-versioner. Fälten skiljer sig från UUID v1 enligt följande:

FältBitarSyfte
local_id32<code>local_id</code> — 32-bitars lokal domänidentifierare (t.ex. POSIX UID från <code>/etc/passwd</code>), ersätter time_low-fältet i UUID v1
time_mid16<code>time_mid</code> — mellersta 16 bitar av den trunkerade UUID v1-tidsstämpeln
time_hi+version16<code>time_hi_and_version</code> — topp 12 tidsstämpelbitar med versionsnibble satt till <code>2</code>
variant+clock_hi8<code>clock_seq_hi_and_reserved</code> — variantbitar plus hög del av klocksekvensen
local_domain8<code>local_domain</code> — domänidentifierare: <code>0</code> = POSIX-användare (UID), <code>1</code> = POSIX-grupp (GID), <code>2</code> = Organisation
node48<code>node</code> — 48-bitars MAC-adress för den genererande värden

Exempel: 000003e8-92e0-21ef-8000-325096b39f47 — local_id 0x000003e8 = UID 1000, local_domain 0x00 = POSIX-användare

Note:Eftersom local_id-fältet ersätter time_low-fältet är tidsstämpeln i UUID v2 bara 28 bitar bred (jämfört med 60 bitar i UUID v1). Det minskar tidsstämpelprecisionen till ungefär 7,2 minuter — UUID:n som genereras inom samma 7-minutersfönster från samma värd/domän/local_id-kombination kanske inte är unika.

Lokal domänvärden

local_domain-byten anger typen av lokal identifierare inbäddad i UUID:t:

0POSIX_UID
POSIX användar-ID — det numeriska UID:t från <code>/etc/passwd</code>, erhållbart via <code>os.getuid()</code>
1POSIX_GID
POSIX grupp-ID — det numeriska GID:t från <code>/etc/group</code>, erhållbart via <code>os.getgid()</code>
2ORG
Organisation — en anpassad 32-bitars organisationsidentifierare; semantiken är applikationsdefinierad

Domänvärdena definieras av DCE-specifikationen. Värden 3–255 är reserverade. I praktiken är bara domän 0 (Person/UID) vanligen förekommande i verkliga UUID v2-värden.

Varför UUID v2 sällan används

Tre egenskaper gör UUID v2 opraktiskt för de flesta moderna applikationer:

Grov tidsstämpelupplösning

Tidsstämpeln trunkeras till 28 bitar (ungefär 7,2-minutersgranularitet). Inom det fönstret är UUID:n som genereras med samma local_id och domän på samma värd inte unika — specifikationen förlitar sig på clock_seq-fältet för att skilja dem åt, vilket begränsar unikheten till 64 värden per 7-minutersfönster.

Inget standardbiblioteksstöd

Till skillnad från UUID v1 och v4 stöds UUID v2 inte av de flesta UUID-bibliotek. uuid npm-paketet, Pythons uuid-modul och Javas java.util.UUID utelämnar alla v2. Anpassad implementering krävs.

POSIX-specifik semantik

Det lokala domänkonceptet (UID/GID) är i grunden POSIX-specifikt och översätts inte meningsfullt till Windows, inbyggda system eller molnmiljöer där konceptet med ett POSIX-användar-ID saknas.

Warning:Använd inte UUID v2 för nya projekt. Formatet ger inga fördelar jämfört med UUID v4 eller v7 för allmänna unika ID:n. Om du stötte på ett UUID v2 i ett äldre system, använd det här verktyget för att avkoda dess fält. För ny utveckling, använd UUID v4.

Historisk kontext

UUID v2 definierades som en del av Open Software Foundations Distributed Computing Environment (DCE/RPC) i början av 1990-talet. Målet var att skapa UUID:n som kunde bära auktorisationskontext — specifikt för att låta en RPC-server identifiera den anropande användaren utan ett separat autentiseringssteg.

DCE-säkerhetsmodellen förutsatte en homogen POSIX-miljö där varje nod deltog i ett delat UID/GID-namnområde. Det inbäddade UID:t skulle låta servern snabbt kontrollera åtkomstkontrollistor utan en tur-och-retur till en katalogtjänst.

  • Internet gick bort från homogena POSIX-miljöer mot heterogena molnarkitekturer
  • Modern autentisering använder token (JWT, OAuth) snarare än inbäddade UID:n i identifierare
  • UUID v4 (helt slumpmässigt) och UUID v7 (tidsordnat) täcker de praktiska användningsfallen för unika identifierare
  • DCE/RPC föll självt ur utbredd användning

RFC 4122 (2005) inkluderade UUID v2 med hänvisning till DCE-specifikationen, men utelämnade avsiktligt den detaljerade genereringsalgoritmen — med hänvisning till att den definierades av DCE snarare än IETF.

RFC 9562 (2024), som uppdaterade UUID-standarden, behöll UUID v2 för historisk fullständighet men fortsatte att notera dess POSIX-specifika natur och avsaknaden av en fullständig genereringsalgoritm i IETF-standarden.

UUID v2 vs UUID v1

UUID v2 härleds från UUID v1. Här är hur de jämförs:

AspektUUID v1UUID v2
Tidsstämpelbitar60 bitar (~100ns precision)28 bitar (~7,2-minutersprecision)
Lokal identifierareIngen32-bitars POSIX UID/GID
Lokal domänInte närvarande0=UID, 1=GID, 2=Org
NodfältMAC-adressMAC-adress
BiblioteksstödBrett understöttSällan understött
StandardRFC 4122 / RFC 9562DCE-spec (refererad av RFC 4122)
Praktisk användningÄldre tidsstämpelordnade ID:n (Cassandra)Endast DCE-säkerhetskontexter

UUID v2 erbjuder ingenting jämfört med UUID v1 för allmänt bruk, och är strikt sämre i de flesta avseenden. Det finns ingen anledning att välja UUID v2 för ny utveckling.

Kodexempel

UUID v2 har inget inbyggt stöd i standardbibliotek. Följande exempel visar hur man arbetar med UUID v2-värden:

Python — manuell implementering

Python
import uuid, struct, time

def uuid_v2(local_id: int, local_domain: int = 0) -> str:
    """
    Generate a DCE Security UUID (v2).
    local_domain: 0 = POSIX UID, 1 = POSIX GID, 2 = Org
    local_id: 32-bit unsigned integer (e.g. os.getuid())
    """
    # Get a v1 UUID for the time and node fields
    v1 = uuid.uuid1()
    fields = list(v1.fields)  # [time_low, time_mid, time_hi_version, clock_seq_hi_variant, clock_seq_low, node]

    # Replace time_low with local_id
    fields[0] = local_id & 0xFFFFFFFF

    # Replace version nibble: clear lower 12 bits of time_hi, set version 2
    fields[2] = (fields[2] & 0x0FFF) | 0x2000

    # Replace clock_seq_low with local_domain
    fields[4] = local_domain & 0xFF

    return str(uuid.UUID(fields=tuple(fields)))


import os
print(uuid_v2(os.getuid(), local_domain=0))   # POSIX UID
print(uuid_v2(os.getgid(), local_domain=1))   # POSIX GID

Go — notera

Go
// The standard "github.com/google/uuid" package does NOT support v2.
// You would need to implement it manually, similar to the Python example above.
// Most Go developers use v4 or v7 for new projects.
import "github.com/google/uuid"

v4 := uuid.New()          // v4 — recommended for most use cases
v7, _ := uuid.NewV7()     // v7 — time-ordered, ideal for database primary keys

JavaScript — extrahera fält

För att extrahera local_id och domän från en befintlig UUID v2-sträng:

JavaScript
// Extracting fields from a UUID v2 string
const uuidStr = '000003e8-1234-2abc-8200-a1b2c3d4e5f6'
//               ^^^^^^^^ ^^^^ ^    ^^
//               local_id      ver  variant+clockSeqHi
//                                  ^^ = local_domain (00 = POSIX UID)

const parts = uuidStr.split('-')

const localId     = parseInt(parts[0], 16)       // → 1000 (0x3e8)
const version     = parseInt(parts[2][0], 16)    // → 2
const localDomain = parseInt(parts[3].slice(2), 16) // low byte of octet pair

const DOMAIN_NAMES = ['POSIX UID', 'POSIX GID', 'Org']
console.log(`Local ID: ${localId}`)                       // Local ID: 1000
console.log(`Version:  ${version}`)                       // Version:  2
console.log(`Domain:   ${DOMAIN_NAMES[localDomain]}`)     // Domain:   POSIX UID
Note:Paketet google/uuid Go stöder UUID v2-generering via uuid.NewDCEGroup() och uuid.NewDCEPerson() — ett av de få mainstream-bibliotek som gör det.

Vanliga frågor

Kan jag generera ett UUID v2 i JavaScript?
Inget standardbibliotek stöder UUID v2-generering i JavaScript. Du skulle behöva konstruera byten manuellt: ta ett UUID v1, ersätt time_low-fältet (byte 0–3) med din lokala identifierare, sätt byte 9 till ditt domänvärde och ange versionsnibble till 2. Det här verktyget genererar inte UUID v2 — det avkodar dem bara.
Vad innehåller local_id-fältet?
local_id är ett 32-bitars osignerat heltal vars betydelse beror på local_domain-byten. För domän 0 är det POSIX UID för användaren som kör processen (t.ex. 1000 för den första icke-root-användaren på ett Linux-system). För domän 1 är det POSIX GID. För domän 2 är betydelsen applikationsdefinierad.
Är tidsstämpeln i ett UUID v2 tillförlitlig?
Bara som en grov indikator. Eftersom bara 28 bitar av den 60-bitars UUID v1-tidsstämpeln behålls är den effektiva precisionen ungefär 7,2 minuter. Du kan avkoda en ungefärlig genereringstid, men inte en exakt. Inom ett 7-minutersfönster kommer flera UUID v2-värden med samma local_id och domän från samma värd att ha identiska tidsstämplar.
Vilka system använder fortfarande UUID v2?
UUID v2 påträffas främst i äldre DCE/RPC-system från 1990-talet, vissa versioner av Microsofts DCOM (som är baserat på DCE/RPC) och äldre distribuerade datorinfrastrukturer. Moderna system använder nästan universellt UUID v4 eller v7.
Varför inkluderar RFC 4122 inte UUID v2-algoritmen?
RFC 4122 anger uttryckligen att UUID v2-genereringsalgoritmen definieras av DCE-specifikationen, inte av IETF. Eftersom IETF inte hade auktoritet över DCE-specifikationen inkluderade de bara en referens. Det är därför de flesta UUID-bibliotek som följer RFC 4122 utelämnar UUID v2-stöd.
Är UUID v2 detsamma som en GUID?
Nej. GUID (Globally Unique Identifier) är Microsofts implementering av UUID-standarden. Microsoft COM använder UUID v1 och v4 GUIDs internt. UUID v2 används inte av Windows GUID-infrastrukturen, trots att båda härstammar från samma DCE/RPC-ursprung.