§

UUID generátor — Ingyenes online UUID v4 generátor

A v4 az alapértelmezett. A v7 lexikografikusan rendeződik a generálás ideje szerint, és a legjobb választás adatbázis kulcsokhoz.
Kimeneti formátum
§

Kimenet

    Az univerzálisan egyedi azonosítók rögzítik az identitás oszlopokat az amerikai adatstack egészében: minden alapértelmezett id egy friss Supabase, PlanetScale vagy AWS Aurora PostgreSQL táblában egy uuid típus, minden Stripe objektum UUID alakú kulcsot hordoz, és minden Snowflake vagy BigQuery dimenziótábla, amelynek stabil helyettesítő kulcsra van szüksége, az RFC 9562-höz (korábban RFC 4122) nyúl. Az Egyesült Királyságban működő szervezetek, amelyek az NHS Digital API-kkal integrálódnak, UUID-ket használnak Bundle.identifier értékekként a HL7 FHIR R4 erőforrásokon belül. Ez a generátor kriptográfiailag véletlenszerű v4 UUID-ket és időrendezett v7 UUID-ket állít elő teljes egészében a böngésző Web Crypto API-ján keresztül, így az Ön által a termelés számára fenntartott azonosító értékek soha nem szivárognak ki egy távoli végponton keresztül.

    Mi az az UUID?

    Az UUID (Universally Unique Identifier) egy 128 bites érték, amelyet egy 36 karakterből álló sztringként jelenítenek meg, mint például 550e8400-e29b-41d4-a716-446655440000. A formátumot és a verzió szemantikáját az RFC 4122 határozza meg a v1-től v5-ig, és az RFC 9562 az újabb v6, v7 és v8 verziókhoz. Ez az eszköz v4 (tisztán véletlen), v1 (időbélyeg plusz véletlen csomópont azonosító) és v7 (Unix-milliszekundum időbélyeg előtag plusz véletlen utótag, a generálás ideje szerint rendezhető) UUID-ket generál — mindezt a böngészőjében, a platform Web Crypto API-ját használva. Nem kerül adat a szerverre.

    Hogyan működik az UUID generálás?

    Minden verzió másképp egyensúlyoz a determinizmus, a rendezhetőség és az entrópia között. Az eszköz a kiválasztása alapján választja ki a megfelelő algoritmust:

    1. v4 (véletlen) a böngésző crypto.randomUUID() függvényét hívja, amely 122 bit kriptográfiai véletlenszerűséget ad vissza a 6 rögzített bittel (verzió 0100 és a 10 variáns) a megfelelő pozíciókban. Az ütközések csillagászatilag valószínűtlenek — nagyjából 2,71 kvintillió v4 UUID-t kellene generálnia egyetlen duplikátum eléréséhez 50%-os valószínűséggel.
    2. v1 (időbélyeg + csomópont) egy 60 bites Gergely-naptár időbélyeget (100 nanoszekundumos ketyegések 1582-10-15 óta) csomagol time_low / time_mid / time_hi_and_version mezőkbe, beállítja a verzió négy bitet 0001-re, kiválaszt egy 14 bites óraszekvenciát a variáns bitekkel, és egy véletlen 48 bites csomópont azonosítót használ a multicast bit bekapcsolásával (az RFC 4122 §4.5 kifejezetten engedélyezi a véletlen csomópont azonosítót, ha nincs elérhető hardver MAC cím — a multicast bit jelöli, hogy nem MAC).
    3. v7 (rendezhető időbélyeg), az RFC 9562 §5.7 szerint, egy 48 bites big-endian Unix-milliszekundum időbélyeget helyez el, majd a 4 bites verziót 0111, majd 12 véletlen bitet, majd a 2 bites variánst 10, majd további 62 véletlen bitet. Mivel az időbélyeg a legjelentősebb bitekben van, a v7 UUID-k lexikografikusan rendeződnek a generálás sorrendjében — ez egy olyan tulajdonság, amelyet egyetlen más UUID verzió sem kínál extra kódolás nélkül.
    4. Minden véletlenszerűség a crypto.getRandomValues()-ból származik, a böngésző kriptográfiailag biztonságos véletlenszám generátorából. Mind a v1, mind a v7 tartalmaz egy intra-ketyegés monoton védelmet, így két egymást követő hívás ugyanazon az óra ketyegésen belül is a másodikat rendezi az első fölé — fontos a tömeges generálási futtatásoknál, amelyek versenyeznek a milliszekundumos órával.
    5. A formázási folyamat a generálás után fut. Eltávolíthatja a kötőjeleket, válthat nagybetűkre, becsomagolhatja az értéket kapcsos zárójelekbe ({…} — a Microsoft GUID konvenció), vagy megjelenítheti a nyers 16 bájtot base64-ként (22 karakteres kimenet, kitöltés nélkül). A base64 mód felülírja a többi formázási opciót, mert a base64 a saját reprezentációja.

    Miért használja ezt az UUID generátort?

    • Semmi sem hagyja el a böngészőt. A Web Crypto API helyben fut; az oldal nulla hálózati kérést indít a kezdeti dokumentumbetöltés után. Nyissa meg a DevTools-t, kattintson a Generálásra, és a Hálózat panel csendben marad.
    • RFC-konform kimenet. A v4 az RFC 4122 §4.4, a v1 a §4.2 és §4.5, a v7 az RFC 9562 §5.7 szerint működik. A verzió négy bit és a variáns bitek ott vannak elhelyezve, ahol a szabványok mondják — minden UUID érvényesíthető a kanonikus verzió reguláris kifejezés ellen.
    • Rendezhető v7 adatbázis kulcsokhoz. Egy v7 UUID, amelyet klaszterezett elsődleges kulcsként használnak Postgres-ben, MySQL-ben vagy SQL Server-ben, a beszúrásokat csak hozzáfűző műveletté teszi az indexen — nincs oldalhasadás, nincs véletlenszerű I/O — miközben továbbra is globálisan egyedi. A v4 ezt nem tudja megtenni, mert a bitjei véletlenek.
    • Tömeges generálás sebességkorlátok nélkül. Generáljon 1, 10, 100 vagy 1000 UUID-t egyszerre. Nincs kvóta és nincs regisztráció — az eszköz a lapján fut, így a korlát a CPU-ja, nem egy szállító API szintje.

    Mik az UUID-k gyakori alkalmazásai?

    Az UUID-k bárhol felbukkannak, ahol egy rendszernek globálisan egyedi azonosítóra van szüksége anélkül, hogy egy központi hatósággal kellene egyeztetnie:

    • Adatbázis elsődleges kulcsok. Az automatikusan növekvő egészek kiszivárogtatják a sorok számát és megtörik a sharding-ot. Az UUID-k stabilak a shard-ok között, biztonságosan összevonhatók régiók között, és (v7-tel) a B-fa beszúrásokat forrón tartják oldalhasadás nélkül. Egy tipikus alkalmazás az UUID-t kliens oldalon generálja, elküldi a beszúrásban, és soha nem kell visszautaznia a szerverhez a kulcsért.
    • Kérés korrelációs azonosítók. Az HTTP middleware egy v4 UUID-t csatol minden bejövő kéréshez, naplózza minden span-on, és továbbítja a downstream irányban (gyakran a X-Request-Id fejlécként). Amikor egy ügyfél hibát jelent, a támogatási mérnök beilleszti az azonosítót, és a teljes kérés nyomvonal megjelenik — szolgáltatásokon és időzónákon keresztül — egyértelműség nélkül.
    • Idempotencia kulcsok. A fizetési API-k (Stripe, Adyen, Square) elfogadnak egy Idempotency-Key fejlécet, így egy újrapróbált kérés soha nem terheli meg kétszer az ügyfelet. Egy kliens által generált UUID garantálja, hogy a kulcs egyedi minden logikai művelethez, ami az a szerződés, amelyet ezek az API-k megkövetelnek.

    Hogyan néz ki egy UUID példa?

    A Node.js-ben vagy egy modern böngészőben az egysoros crypto.randomUUID() egy friss v4 UUID-t ad vissza — például 3f50b5a8-2c54-4b9c-9c1f-3e5c7e2b8d12. Használja ezt egy kérés azonosítóhoz vagy egy idempotencia kulcshoz. Amikor az UUID egy olyan adatbázis oszlopba kerül, amely a klaszterezett elsődleges kulcs lesz, generáljon helyette v7-et: két v7 érték, amelyek egy milliszekundum különbséggel készültek, mint például 0190a3b0-7d4f-7c9e-8b21-a4d6f0bd9c11 és 0190a3b0-7d50-7f15-9c4e-72b3e0c1d8a4, lexikografikusan rendeződnek a generálás sorrendjében. A Postgres uuid típusa mindkét verziót azonosan tárolja — a különbség az indexírás időpontjában mutatkozik meg, ahol a v7 beszúrások a B-fa jobb oldalára fűződnek, míg a v4 beszúrások szétszóródnak és véletlenszerű I/O-t kényszerítenek ki.

    Ez az UUID Generátor egy dolgot csinál: egy kattintást egy vagy több RFC-megfelelő azonosítóvá alakít, a szükséges formátumban, anélkül, hogy a kérését szerverre küldené. Válasszon verziót, válasszon darabszámot, válasszon formátumot — generáljon, másoljon, lépjen tovább.