Univerzálisan egyedi azonosító - Universally unique identifier

UUID/GUID, amelyet az UEFI változók használnak

Az univerzálisan egyedi azonosító ( UUID ) egy 128 bites címke, amelyet számítógépes rendszerekben használnak. A globálisan egyedi azonosító ( GUID ) kifejezést is használják, gyakran a Microsoft által készített szoftverekben .

Ha szabványos módszerek szerint állítják elő, az UUID -k gyakorlati okokból egyediek. Különlegességük nem függ a központi regisztrációs hatóságtól vagy az őket létrehozó felek közötti koordinációtól, ellentétben a legtöbb más számozási rendszerrel. Bár annak valószínűsége, hogy egy UUID megismétlődik, nem nulla, de elég közel van a nullához ahhoz, hogy elhanyagolható legyen.

Így bárki létrehozhat egy UUID -t, és annak segítségével szinte biztosan azonosíthat valamit, hogy az azonosító nem másolja azt, amelyet már létrehoztak vagy létrehoznak más azonosítására. A független felek által UUID -kkel címkézett információk ezért később egyesíthetők egyetlen adatbázisba, vagy ugyanazon a csatornán továbbíthatók, elhanyagolható valószínűséggel a többszörözéssel.

Az UUID -k elfogadása széles körben elterjedt, számos számítási platform támogatást nyújt ezek előállításához és szöveges ábrázolásuk elemzéséhez.

Történelem

Az 1980 -as években az Apollo Computer eredetileg UUID -ket használt a hálózati számítási rendszerben (NCS), később pedig az Open Software Foundation (OSF) elosztott számítási környezetében (DCE). A kezdeti tervezési DCE UUID alapult NCS UUID, amelynek a tervezési volt viszont ihlette ( 64-bites ) egyedi azonosítók definiált és használt pervasively a Domain / OS , egy operációs rendszer által tervezett Apolló Computer. Később a Microsoft Windows platformok a globális egyedi azonosítóként (GUID) fogadták el a DCE kialakítást. Az RFC 4122 regisztrált egy URN névteret az UUID -k számára, és újra összefoglalta a korábbi specifikációkat, azonos műszaki tartalommal. Amikor 2005 júliusában az RFC 4122 -t közzétették javasolt IETF -szabványként, az ITU szabványosította az UUID -ket is, az RFC 4122 korábbi szabványai és korai verziói alapján.

Szabványok

Az UUID -ket az Open Software Foundation (OSF) szabványosítja az elosztott számítási környezet (DCE) részeként .

Az UUID-ket az ISO / IEC 11578: 1996 " Informatika-  Nyílt rendszerek összekapcsolása- Távoli eljáráshívás (RPC)" és az ITU-T Rec. X.667 | ISO / IEC 9834-8: 2005.

Az Internet Engineering Task Force (IETF) közzétette a Standard-Track RFC 4122 szabványt, amely technikailag egyenértékű az ITU-T Rec. X.667 | ISO/IEC 9834-8.

Formátum

A kanonikus szöveges ábrázolásban az UUID 16 oktettje 32 hexadecimális (alap-16) számjegyként jelenik meg, öt csoportban, kötőjelekkel elválasztva, 8-4-4-4-12 formában, összesen 36 karakterben (32 hexadecimális karakter és 4 kötőjel). Például:

123e4567-e89b-12d3-a456-426614174000
xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

A négybites M és az 1-3 bites N mezők kódolják az UUID formátumát.

A négy bites számjegy Maz UUID verzió, az 1-3 legjelentősebb számjegyű Nkód pedig az UUID változat. (Lásd alább. ) A példában M jelentése 1, és N jelentése a(10xx 2 ), ami azt jelenti, hogy ez egy 1-es verzió, 1-es változat UUID; azaz időalapú DCE/RFC 4122 UUID.

A kanonikus 8-4-4-4-12 formátumú karakterlánc az UUID 16 bájta rekordelrendezésén alapul:

UUID rekord elrendezés
Név Hossz (bájt) Hossz (hexadecimális számjegy) Hossz (bit) Tartalom
time_low 4 8 32 egész szám, amely az idő alacsony 32 bitjét adja
time_mid 2 4 16 egész szám, amely az idő középső 16 bitjét adja
time_hi_and_version 2 4 16 4 bites "verzió" a legjelentősebb bitekben, majd az idő magas 12 bitje
clock_seq_hi_and_res clock_seq_low 2 4 16 1-3 bites "változat" a legjelentősebb bitekben, majd a 13-15 bites órajelsorozat
csomópont 6 12 48 a 48 bites csomópont azonosítója

Ezek a mezők megegyeznek az 1. és 2. verziójú UUID-k (azaz az időalapú UUID-k) mezőivel, de ugyanaz a 8-4-4-4-12 ábrázolás minden UUID-hez használatos, még a különbözőképpen létrehozott UUID-k esetében is.

Az RFC 4122 3. fejezete előírja, hogy a karaktereket kisbetűkkel kell előállítani, miközben a kis- és nagybetűket nem kell figyelembe venni.

A Microsoft GUID -jeit néha körbefogó zárójelek jelzik:

{123e4567-e89b-12d3-a456-426652340000}

Ezt a formátumot nem szabad összetéveszteni a " Windows rendszerleíró adatbázis formátumával", amely a göndör zárójeleken belüli formátumra utal .

Az RFC 4122 egységes erőforrásnév (URN) névteret határoz meg az UUID -k számára. Az URN -ként bemutatott UUID a következőképpen jelenik meg:

urn:uuid:123e4567-e89b-12d3-a456-426655440000

Kódolás

Az UUID -k bináris kódolása rendszerekenként eltérő. Az 1. változat UUID-je, manapság a leggyakoribb változat, big-endian formátumban van kódolva . Például bájtként 00112233-4455-6677-8899-aabbccddeeffvan kódolva 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff.

2. változat UUID, történelmileg használt Microsoft COM / OLE könyvtárak , használjon vegyes-endian formátumban, ahol az első három összetevője a UUID vannak little-endian , és az utolsó kettő big-endian . Például bájtként 00112233-4455-6677-8899-aabbccddeeffvan kódolva 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff.

Változatok

Az UUID -k "variáns" mezője vagy az N pozíció jelzi a formátumukat és a kódolást. Az RFC 4122 négy, 1-3 bit hosszúságú változatot határoz meg:

  • A 0 változat (amelyet a 0xxx 2 egybites minta jelez , N  =  0..7) visszafelé kompatibilis a mára elavult Apollo Network Computing System 1.5 UUID formátummal, amelyet 1988 körül fejlesztettek ki. Az UUID első 6 oktettje egy 48 bites időbélyeg ( a 4 mikroszekundumos időegységek száma 1980. január 1. (UTC) óta); a következő 2 oktett fenntartva; a következő oktett a "címcsalád"; és az utolsó 7 oktett egy 56 bites gazdaazonosító a címcsalád által meghatározott formában. Bár a részletekben különböznek, nyilvánvaló a hasonlóság a modern 1. verziójú UUID-kkel. Az aktuális UUID specifikációban szereplő variáns bitek egybeesnek az NCS UUID címcsalád oktettjének magas bitjeivel. Bár a címcsalád a 0..255 tartományban tarthat értékeket, csak a 0..13 értékeket határozták meg. Ennek megfelelően a 0 változatú minta 0xxxelkerüli az ütközést a korábbi NCS UUID-kkel, ha léteznek még ilyenek az adatbázisokban.
  • Az 1. változatra (10xx 2 , N  =  8..b, 2 bit) az eredeti Internet -tervezet szerzői után RFC 4122/DCE 1.1 UUID -ként vagy „Leach – Salz” UUID -ként hivatkozunk .
  • A 2. változatot (110x 2 , N  =  c..d, 3 bit) az RFC "fenntartott, Microsoft Corporation visszafelé kompatibilis" jellemzi, és a korai GUID -ekhez használták a Microsoft Windows platformon. Az 1. változattól csak a bináris tárolás vagy átvitel végessége különbözik: az 1-es változat UUID-k a "network" (big-endian) bájtsorrendet használják, míg a 2-es változat GUID-jai "natív" (little-endian) bájtsorrendet használnak egyes almezőkhöz. az UUID.
  • Fenntartva a 3 bites változat 111x 2 ( N  =  e..f) bitmintája .

Az 1. és 2. változatot az aktuális UUID specifikáció használja. Szöveges ábrázolásukban az 1. és 2. változat ugyanaz, kivéve a variáns biteket. A bináris ábrázolásban van egy végtelenségbeli különbség. Ha a bájtcserére szükség van az 1. változat nagy-endiánus bájtsorrendje és a 2. változat kis-endiánus bájtsorrendje közötti konvertáláshoz, akkor a fenti mezők határozzák meg a cserét. Az első három mező 32 és 16 bites előjel nélküli egész szám, és felcserélhető, míg az utolsó két mező nem értelmezett bájtokból áll, amelyek nem cserélhetők. Ez a bájtcsere még a 3., 4. és 5. verzióra is érvényes, ahol a gyűjtőmezők nem felelnek meg az UUID tartalmának.

Míg néhány fontos GUID, mint például a komponensobjektum-modell IUnknown interfész azonosítója, névlegesen 2-es változatú UUID-k, a Microsoft Windows szoftverben generált és használt sok azonosító, amelyeket "GUID-ként" emlegetnek, az szabványos RFC 4122/DCE 1.1 változat hálózati bájt sorrendű UUID-k, nem pedig a kis endián-variáns-2 UUID-k. A Microsoft guidgeneszköz jelenlegi verziója szabványos 1-es változat UUID-ket készít. Egyes Microsoft dokumentációk szerint a "GUID" az "UUID" szinonimája, az RFC 4122 szabvány szerint. Az RFC 4122 maga azt állítja, hogy az UUID -k "GUID -ként is ismertek". Mindez azt sugallja, hogy a "GUID", bár eredetileg a Microsoft által használt UUID-változatra hivatkozott, egyszerűen az UUID alternatív nevévé vált, és mind az 1-es, mind a 2-es változatú GUID-ok megmaradtak.

Verziók

Mind az 1., mind a 2. változat esetében öt „változatot” határoztak meg a szabványokban, és mindegyik verzió megfelelőbb lehet, mint a többi, bizonyos használati esetekben. A verziót Ma karakterlánc ábrázolása jelzi.

Az 1-es verzió UUID-jeit egy időből és egy csomópont-azonosítóból (általában a MAC-címből ) állítják elő ; a 2. verziójú UUID-k egy azonosítóból (általában csoport vagy felhasználói azonosító), időből és csomópont-azonosítóból jönnek létre; a 3. és 5. verzió determinisztikus UUID -ket állít elő névtér azonosító és név kivonatolásával ; és a 4-es verzió UUID-jeit véletlenszerű vagy ál-véletlenszerű számok segítségével állítják elő .

Nulla UUID

A "nulla" UUID, egy speciális eset, az UUID 00000000-0000-0000-0000-000000000000; vagyis minden bit nullára van állítva.

1. verzió (dátum, idő és MAC-cím)

1. változat összefűzi a 48 bites MAC-címét a „csomópont” (azaz, a számítógép generál az UUID), a 60-bites időbélyeg, hogy az első számú 100- ns időközönként éjféltől október 15, 1582 világidő (UTC ), a Gergely -naptár első elfogadásának dátuma . Az RFC 4122 azt állítja, hogy az időérték az alkalmazott algoritmustól függően 3400 körül mozog, ami azt jelenti, hogy a 60 bites időbélyeg egy aláírt mennyiség. Azonban egyes szoftverek, például a libuuid könyvtár, az időbélyeget alá nem írtként kezeli, így az átbillentési idő 5236 i. Az átforgatási idő az ITU-T Rec. X.667 a 3603 i.

A 13 vagy 14 bites "egyedi" órajel-sorozat meghosszabbítja az időbélyeget, hogy kezelje azokat az eseteket, amikor a processzor órajele nem halad elég gyorsan, vagy ha több processzor és UUID-generátor van csomópontonként. Ha az UUID-k gyorsabban generálódnak, mint amennyit a rendszeróra előre tud lépni, akkor az időbélyegző mezők alsó bitjei generálhatók úgy, hogy minden egyes UUID generálásakor növelik, hogy nagy felbontású időbélyeget szimuláljanak. Mivel minden 1. verziójú UUID megfelel a tér egyetlen pontjának (a csomópont) és az időnek (intervallumok és órarend), annak esélye, hogy két megfelelően generált 1. verziójú UUID véletlenül azonos legyen, gyakorlatilag nulla. Mivel az idő és az óra szekvencia teljes 74 bites, 2 74 (1,8 × 10 22 , vagy 18 sextillion) változat-1 UUID generálható per csomópont azonosítót, egy maximális átlagos mértéke 163 milliárd másodpercenként csomópont-azonosító.

A többi UUID verziótól eltérően a hálózati kártyák MAC -címein alapuló 1 -es és -2 -es verziójú UUID -k egyediségükre részben a központi regisztrációs hatóság által kibocsátott azonosítóra támaszkodnak, nevezetesen a MAC -cím szervezetileg egyedi azonosítójára (OUI) , amelyet az IEEE ad ki a hálózati berendezések gyártóinak. Az 1-es és 2-es verziójú UUID-ek egyedisége a hálózati kártya MAC-címein alapul attól is, hogy a hálózati kártyák gyártói megfelelően rendelnek egyedi MAC-címeket a kártyájukhoz, ami más gyártási folyamatokhoz hasonlóan hibás. Ezenkívül néhány operációs rendszer lehetővé teszi a végfelhasználó számára a MAC -cím testreszabását, nevezetesen az OpenWRT -t .

A csomópont hálózati kártya MAC-címének használata a csomópont-azonosítóhoz azt jelenti, hogy az 1-es verziójú UUID visszakövethető a létrehozó számítógéphez. A dokumentumok néha szövegszerkesztő szoftverrel beágyazott UUID -k révén követhetők nyomon azokhoz a számítógépekhez, ahol létrehozták vagy szerkesztették őket . Ezt az adatvédelmi lyukat használták fel a Melissa vírus létrehozójának felkutatásakor .

Az RFC 4122 lehetővé teszi, hogy az 1-es (vagy 2-es) UUID-ben lévő MAC-címet egy véletlenszerű 48 bites csomópont-azonosítóval helyettesítsék, vagy azért, mert a csomópontnak nincs MAC-címe, vagy azért, mert nem kívánatos a leleplezése. Ebben az esetben az RFC megköveteli, hogy a csomópont -azonosító első oktettjének legkevésbé jelentős bitjét 1 -re kell állítani. Ez megfelel a MAC -címek multicast bitjének, és ennek beállítása arra szolgál, hogy megkülönböztesse azokat az UUID -ket, ahol a csomópont -azonosító véletlenszerűen generálódik az UUID -kből hálózati kártyák MAC -címei alapján, amelyek jellemzően unicast MAC -címmel rendelkeznek.

2. verzió (dátum-idő és MAC-cím, DCE biztonsági verzió)

Az RFC 4122 a 2. verziót fenntartja a "DCE security" UUID -okhoz; de semmilyen részletet nem közöl. Emiatt sok UUID-implementáció kihagyja a 2. verziót. A 2. verziójú UUID-k specifikációját azonban a DCE 1.1 hitelesítési és biztonsági szolgáltatások specifikációja biztosítja.

A 2-es verzió UUID-i hasonlóak az 1-es verzióhoz, kivéve, hogy az óra szekvencia legkevésbé szignifikáns 8 bitjét egy "helyi tartomány" szám váltja fel, és az időbélyeg legkevésbé szignifikáns 32 bitjét egy egész szám azonosító helyettesíti helyi domain. A POSIX rendszereken a 0 és 1 helyi tartományi számok a felhasználói azonosítókhoz ( UID ) és a csoportazonosítókhoz ( GID ) tartoznak, a többi helyi tartományi szám pedig helyszíni. Nem POSIX rendszereken minden helyi tartományszám helyfüggő.

A 40 bites tartomány/azonosító UUID-be való beépítésének lehetősége kompromisszummal jár. Egyrészt 40 bit csomópont -azonosítónként körülbelül 1 billió tartomány/azonosító értéket tesz lehetővé. Másrészről, ha az óra értékét a 28 legjelentősebb bitre csonkítják, szemben az 1 -es verzió 60 bitjével, a 2 -es verziójú UUID órája csak 429,49 másodpercenként, valamivel több mint 7 percenként fog "ketyegni". szemben az 100-as verzió minden 100 nanoszekundumával. És csak 6 bites órajel-szekvenciával, szemben az 1-es verzió 14 bitjével, csomópontonként/tartományonként/azonosítónként csak 64 egyedi UUID generálható 7 perces órajel mellett, szemben a 16 384-el óra szekvencia értékei az 1. verzióhoz. Így előfordulhat, hogy a 2. verzió nem alkalmas azokra az esetekre, amikor UUID -k szükségesek csomópontonként/tartományonként/azonosítónként, minden hét percben meghaladó sebességgel.

3. és 5. verzió (névtér név alapú)

A 3-as és az 5-ös verziójú UUID-k a névtér azonosítójának és nevének kivonatolásával jönnek létre . A 3. verzió az MD5- öt használja hash-algoritmusként, az 5. verzió pedig az SHA-1-et .

A névtér -azonosító maga UUID. A specifikáció UUID -ket biztosít az URL -ek névterének , teljesen minősített tartományneveknek , objektumazonosítóknak és X.500 megkülönböztetett neveknek a reprezentálására ; de bármilyen kívánt UUID használható névtér -kijelölőként.

A megadott névtérnek és névnek megfelelő 3-as verziójú UUID meghatározásához a névtér UUID-jét bájtos karakterlánccá alakítják, összekapcsolják a bemeneti névvel, majd kivonatolják az MD5-tel, és 128 bitet kapnak. Ezután 6 vagy 7 bitet rögzített értékek, a 4 bites verzió (pl. 0011 2 a 3. verzió) és a 2 vagy 3 bites UUID "változat" (pl. 10 2 egy RFC 4122 UUID-t jeleznek, vagy 110 2) egy korábbi Microsoft GUID -t jelez). Mivel így 6 vagy 7 bit van előre meghatározva, csak 121 vagy 122 bit járul hozzá az UUID egyediségéhez.

Az 5-ös verzió UUID-i hasonlóak, de az SH5-1-et használják az MD5 helyett. Mivel az SHA-1 160 bites kivonatokat generál, a kivonat 128 bitre van csonkolva, mielőtt a verzió és a változat biteket kicserélik.

A 3-as és az 5-ös verziójú UUID-k rendelkeznek azzal a tulajdonsággal, hogy ugyanaz a névtér és név ugyanahhoz az UUID-hez társul. Azonban sem a névtér, sem a név nem határozható meg az UUID-ból, még akkor sem, ha az egyiket megadták, kivéve a nyers erővel történő keresést. Az RFC 4122 az 5-ös (SHA-1) verziót javasolja a 3-as verzió (MD5) helyett, és óva int attól, hogy bármelyik verzió UUID-jét biztonsági hitelesítő adatként használja.

4. verzió (véletlenszerű)

A 4 -es verziójú UUID véletlenszerűen jön létre. A többi UUID -hez hasonlóan 4 bitet használnak a 4 -es verzió jelzésére, és 2 vagy 3 bitet a változat megjelölésére (10 2 vagy 110 2 az 1 -es és 2 -es változatnál). Így az 1. változat (azaz a legtöbb UUID) esetében a véletlenszerű 4-es verziójú UUID 6 előre meghatározott változat- és verzióbitet tartalmaz, így 122 bit marad a véletlenszerűen generált részre, összesen 2 122 vagy 5,3 × 10 36 (5,3  Millió ) lehetséges 4-es verziójú 1-es verziójú UUID-k. Fele fele annyi lehetséges 4-es változat-2 változatú UUID (örökölt GUID) van, mert eggyel kevesebb véletlenszerű bit áll rendelkezésre, 3 bit kerül felhasználásra a változathoz.

Ütközések

Ütközés akkor fordul elő, ha ugyanazt az UUID -t többször generálják, és különböző referenciákhoz rendelik hozzá. A szabványos 1-es és 2-es verziójú UUID-k esetében, amelyek hálózati kártyák egyedi MAC-címét használják, nem valószínű, hogy ütközések fordulnak elő, nagyobb a lehetőség, ha a megvalósítás akaratlanul vagy szándékosan eltér a szabványoktól.

Ellentétben az 1-es és a 2-es verziójú UUID-kkel, amelyeket MAC-címek használatával hoztak létre, az 1-es és -2-es UUID-kkel, amelyek véletlenszerűen generált csomópont-azonosítókat, a hash-alapú 3-as és 5-ös UUID-ket, valamint a 4-es random UUID-ket használják, ütközések megvalósítási problémák nélkül is előfordulhatnak, bár olyan kicsi a valószínűsége, hogy általában figyelmen kívül hagyható. Ez a valószínűség pontosan kiszámítható a születésnapi probléma elemzése alapján .

Például a véletlenszerű, 4-es verziójú UUID-k száma, amelyeket legalább egy ütközés 50% -os valószínűsége érdekében létre kell hozni, 2,71 quintillion, az alábbiak szerint számítva:

Ez a szám egyenértékű azzal, hogy másodpercenként 1 milliárd UUID -t generálnak körülbelül 85 éven keresztül. Egy ennyi UUID -t tartalmazó fájl, 16 bájt UUID -nként, körülbelül 45 exabájt lenne  .

A legkisebb számú 4-es verziójú UUID-t, amelyet létre kell hozni ahhoz, hogy az ütközés valószínűsége p legyen, a képlet közelíti

Így annak valószínűsége, hogy 103 billió 4-es verziójú UUID-n belül másolatot találnak, egymilliárd.

Felhasználások

Jelentős felhasználási területek az ext2 / ext3 / ext4 fájlrendszer felhasználói tér eszközei (az e2fsprogs az util-linux által biztosított libuuidot használja ), az LVM , a LUKS titkosított partíciók, a GNOME , a KDE és a macOS , amelyek többsége Theodore Ts'o eredeti megvalósításából származik .

Az UUID -k egyik felhasználása a Solaris -ban (az Open Software Foundation implementációját használva) egy futó operációs rendszer -példány azonosítása abból a célból, hogy a rendszermag -pánik esetén összekapcsolják az összeomlási kiírási adatokat a Hibakezelési Eseménnyel.

Gyakran használják a Bluetooth -protokollokban a szolgáltatások és az általános Bluetooth -profil meghatározásához.

A COM -ban

A Microsoft komponensobjektum -modelljében (COM) többféle GUID -t használnak :

  • IID - interfész azonosító; (Az is, hogy regisztrált a rendszer tárolja a Windows Registry at [HKEY_CLASSES_ROOT\Interface])
  • CLSID - osztályazonosító; (Tárolva [HKEY_CLASSES_ROOT\CLSID])
  • LIBID - típusú könyvtár -azonosító; (Tárolva [HKEY_CLASSES_ROOT\TypeLib])
  • CATID - kategóriaazonosító; (jelenlétét egy osztály azonosítja azt tartozó bizonyos osztály-kategória, felsorolt [HKEY_CLASSES_ROOT\Component Categories])

Adatbázis kulcsként

Az UUID -ket általában egyedi kulcsként használják az adatbázis -táblákban. A NEWID függvény a Microsoft SQL Server 4-es Transact-SQL verziójában standard, véletlenszerű, 4-es verziójú UUID- ket ad vissza , míg a NEWSEQUENTIALID függvény olyan 128 bites azonosítókat ad vissza, amelyek hasonlóak az UUID- ekhez , és amelyek a következő rendszerindításig elkötelezettek. Az Oracle Database SYS_GUID függvény a név ellenére nem ad vissza standard GUID -t . Ehelyett egy 16 bájtos 128 bites RAW értéket ad vissza, amely egy gazdaazonosítón és egy folyamat- vagy szál-azonosítón alapul, némileg hasonlóan a GUID-hez. A PostgreSQL tartalmaz egy UUID adattípust, és a modulokból származó funkciók használatával generálhatja az UUID -k legtöbb verzióját. A MySQL egy UUID funkciót biztosít, amely szabványos verziójú UUID-ket generál.

A véletlenszerű jellege szabvány UUID változatban 3, 4 és 5, és a megrendelő a mezők belül szabvány 1 és 2 változat problémákat okozhatnak tárol településen vagy teljesítmény UUID használják elsődleges kulcsokat . Például 2002-ben Jimmy Nilsson a Microsoft SQL Server teljesítményének jelentős javulásáról számolt be, amikor a kulcsként használt 4-es verziójú UUID-ket úgy módosították, hogy a rendszeridő alapján nem véletlenszerű utótagot tartalmazzanak. Ez az úgynevezett "COMB" (kombinált idő-GUID) megközelítés tette az UUID-eket nem szabványossá és jelentősen nagyobb valószínűséggel duplikálásra, ahogy Nilsson elismerte, de a Nilsson csak egyediséget igényelt az alkalmazáson belül. Ha átrendezi és kódolja az 1 -es és 2 -es verziójú UUID -ket úgy, hogy az időbélyeg legyen az első, a beszúrás teljesítményvesztése elkerülhető.

Néhány webkeret, például a Laravel támogatja az "időbélyegző első" UUID -ket, amelyek hatékonyan tárolhatók egy indexelt adatbázis oszlopban. Ez COMB UUID-t készít a 4-es verziójú formátumban, de az első 48 bites időbélyegzőt alkotja, mint az UUIDv1. A COMB UUID ötleten alapuló pontosabb formátumok a következők:

  • Az "ULID", amely a 4 -es verzió jelzésére használt 4 bitet kiiktatja, alapértelmezés szerint base32 kódolást használ, és a teljes monotonitást állapítja meg.
  • UUID 6–8 verzió, három COMB UUID formátum hivatalos ajánlata.

Lásd még

Hivatkozások

Külső linkek

Szabványok

ITU-T UUID generátor

Műszaki cikkek

Vegyes

Végrehajtás különböző nyelveken