Identificador únic universal

Identificador únic universal

Un identificador universalment únic (UUID) és una etiqueta de 128 bits utilitzat per identificar informació en sistemes informàtics. També s'utilitza el terme identificador global únic (GUID).

Quan és generat segons mètodes estàndard, els UUID son a efectes pràctics, únics. La seva unicitat no depèn de una autoritat de emissió central o coordinació entre parts que els generen, a diferència de altres esquemes de numeració. Encara que la probabilitat que existeixi un UUID duplicat no és zero, és prou propera a zero per ser negligible.[1][2]

Per tant, qualsevol pot crear un UUID i utilitzar-lo per identificar alguna cosa amb la certesa que l'identificador no duplica un que ja ha estat, o sigui, creat per identificar una altra cosa. La informació etiquetada amb UUID per part de terceres parts independents es pot combinar més tard en una única base de dades o transmetre en el mateix canal, amb una probabilitat negligible de duplicació.

L'adopció de UUID està molt estesa, amb moltes plataformes de computació que proporcionen suport per generar-los i per analitzar la seva representació textual.

Història modifica

A la decada de 1980 Apollo Computer va utilitzar originalment UUIDs en el Sistema de Computació de la Xarxa (NCS) i més tard la Open Software Foundation (OSF) Distributed Computing Environment (DCE). El disseny inicial dels UUID de DCE es basava en els UUIDs NCS, el disseny del qual s'inspirava en els identificadors únics (64-bit) definits i utilitzats de forma generalitzada en un sistema operatiu anomenat Domain/OS, dissenyat per Apollo Computer. Més tard, les plataformes Microsoft Windows van adoptar el disseny DCE com a "identificadors globals únics" (GUID). Al RFC 4122 va registrar un espai de noms URN per a UUID i va reagrupar les especificacions anteriors, amb el mateix contingut tècnic. Al juliol de 2005 es va publicar el {{RFC|4122}} com un estàndard proposat per IETF, la ITU també va estandarditzat els UUID, basat en els estàndards anteriors i les primeres versions del {{RFC|4122}}.[cal citació]

Estàndards modifica

Els UUID s'han estandarditzat per la Open Software Foundation (OSF) com part del Distributed Computing Environment (DCE).[3][4]

Els UUID estan documentats com a part de la ISO / IEC 11578:1996 " Tecnologia de la informació – Interconnexió de sistemes oberts – Remote Procedure Call (RPC)" i més recentment a la Rec. X.667 | ISO / IEC 9834-8:2005.[5]

L' Internet Engineering Task Force (IETF) va publicar el Standards-Track {{RFC|4122}}, tècnicament equivalent a la Rec. X.667 | ISO/IEC 9834-8.

Format modifica

En la seva representació textual canònica, els 16 octets d'un UUID es representen com 32 dígits hexadecimals (base 16), que es mostren en cinc grups separats per guions, en la forma 8-4-4-4-12 per a un total de 36 caràcters. (32 caràcters hexadecimals i 4 guions). Per exemple:

123e4567-e89b-12d3-a456-426614174000
xxxxxxxx-xxxx- M xxx- N xxx-xxxxxxxxxxxx

Els camps M de quatre bits i els camps N d'1 a 3 bits codifiquen el format del propi UUID.

Els quatre bits del dígit M són la versió UUID, i els 1 a 3 bits més significatius del dígit N codifiquen la variant UUID. (Veure a continuació.) A l'exemple, M és 1 i N és a (10xx ₂), el que significa que es tracta d'un UUID versió-1, variant-1; és a dir, un UUID DCE/{{RFC|4122}} basat en el temps.

La cadena de format canònica 8-4-4-4-12 es basa en el disseny del registre per als 16 bytes de l'UUID:

Disseny de l'estructura del UUID
Nom Longitud (bytes) Longitud (dígits hexadecimals) Longitud (bits) Continguts
temps_baix 4 8 32 enter que dóna els 32 bits més baixos del temps
time_mid 2 4 16 enter que dóna els 16 bits del mig del temps
temps_hi_i_versió 2 4 16 "Versió" de 4 bits en els bits més significatius, seguit dels alts 12 bits del temps
clock_seq_hi_and_res clock_seq_low 2 4 16 "Variant" d'1 a 3 bits als bits més significatius, seguida de la seqüència de rellotge de 13 a 15 bits
node 6 12 48 l'identificador del node de 48 bits

Aquests camps corresponen als dels UUID de la versió 1 i 2 (és a dir, UUID basats en el temps), però s'utilitza la mateixa representació 8-4-4-4-12 per a tots els UUID, fins i tot per als UUID construïts de manera diferent.

[[rfc:4122#section-3|La secció 3 de la RFC 4122]] requereix que els caràcters es generin en minúscules, mentre que no es distingeixen entre majúscules i minúscules a l'entrada.

Els GUID de Microsoft de vegades es representen amb claus circumdants:

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

Aquest format no s'ha de confondre amb "Format del registre de Windows ", que fa referència al format dins de les claus.[6]

{{RFC|4122}} defineix un espai de noms de nom de recurs uniforme (URN) per als UUID. Un UUID presentat com a URN apareix de la següent manera:

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

Codificació modifica

La codificació binària dels UUID varia entre els sistemes. Els UUID de la variant 1, avui dia la variant més comuna, estan codificats en format big-endian. Per exemple, 00112233-4455-6677-8899-aabbccddeeff està codificat com els bytes 00 11 22 33 44 55 66 77 88 99 aa bb cc dd ee ff .[7][8]

Els UUID de la variant 2, utilitzats històricament a les biblioteques COM/OLE de Microsoft, utilitzen un format mixed-endian, en el qual els tres primers components de l'UUID són little-endian i els dos últims són big-endian. Per exemple, 00112233-4455-6677-8899-aabbccddeeff està codificat com els bytes 33 22 11 00 55 44 77 66 88 99 aa bb cc dd ee ff .[9][10]

Variants modifica

El camp "variant" dels UUID, o la posició N indiquen el seu format i codificació. {{RFC|4122}} defineix quatre variants de longituds d'1 a 3 bits:

  • La variant 0 (indicada pel patró d'un bit 0xxx ₂, N = 0..7) és per a la compatibilitat enrere amb el format UUID Apollo Network Computing System 1.5, ara obsolet, desenvolupat al voltant de 1988. Els primers 6 octets de l'UUID són una marca de temps de 48 bits (el nombre d'unitats de temps de 4 microsegons des de l'1 de gener de 1980 UTC); es reserven els 2 octets següents; el següent octet és la "família d'adreces"; i els 7 octets finals són un identificador d'amfitrió de 56 bits en la forma especificada per la família d'adreces. Tot i que és diferent en detall, la similitud amb els UUID moderns de la versió 1 és evident. Els bits variants de l'especificació UUID actual coincideixen amb els bits alts de l'octet de la família d'adreces als UUID NCS. Tot i que la família d'adreces podia contenir valors en el rang 0..255, només es van definir els valors 0..13. En conseqüència, el patró de bits variant-0 0xxx evita conflictes amb els UUID històrics de NCS, si encara n'hi hagués a les bases de dades.[11]
  • La variant 1 (10xx ₂, N = 8..b, 2 bits) s'anomena UUID {{RFC|4122}}/DCE 1.1, o UUID "Leach–Salz", després dels autors de l'Internet Draft original.
  • La variant 2 (110x ₂, N = c..d, 3 bits) es caracteritza a l'RFC com a "reservat, compatibilitat amb versions anteriors de Microsoft Corporation" i es va utilitzar per als primers GUID a la plataforma Microsoft Windows. Difereix de la variant 1 només per l'endianitat en l'emmagatzematge o transmissió binari: els UUID de la variant-1 utilitzen l'ordre de bytes "xarxa" (big-endian), mentre que els GUID de la variant-2 utilitzen l'ordre de bytes "natiu" (little-endian) per a alguns subcamps. de l'UUID.
  • Com a reservat es defineix el patró de bits variant de 3 bits 111x ₂ (N = e..f).

Les variants 1 i 2 s'utilitzen per l'especificació UUID actual. En les seves representacions textuals, les variants 1 i 2 són iguals, excepte els bits variants. En la representació binària, hi ha una diferència d'endianisme. Quan es requereix l'intercanvi de bytes per convertir entre l'ordre de bytes big-endian de la variant 1 i l'ordre de bytes little-endian de la variant 2, els camps anteriors defineixen l'intercanvi. Els tres primers camps són nombres enters de 32 i 16 bits sense signe i estan subjectes a intercanvi, mentre que els dos últims camps consisteixen en bytes no interpretats, no subjectes a intercanvi. Aquest intercanvi de bytes s'aplica fins i tot per a les versions 3, 4 i 5, on els camps canònics no es corresponen amb el contingut de l'UUID.[12]

Tot i que alguns GUID importants, com ara l'identificador de la interfície Component Object Model IUnknown, són nominalment UUID de la variant-2, molts identificadors generats i utilitzats al programari de Microsoft Windows i anomenats "GUID" són la variant estàndard-1 {{RFC|4122}}/DCE 1.1. UUID d'ordre de bytes de xarxa, en lloc dels UUID de variant-2 de little-endian. La versió actual de l'eina guidgen de Microsoft produeix UUID estàndard de la variant-1. Alguna documentació de Microsoft afirma que "GUID" és un sinònim de "UUID",[13] tal com està estandarditzat a {{RFC|4122}}. El mateix {{RFC|4122}} estableix que els UUID "també es coneixen com a GUID". Tot això suggereix que "GUID", tot i que originalment es referia a una variant de l'UUID utilitzada per Microsoft, s'ha convertit simplement en un nom alternatiu per a l'UUID, amb els GUID de la variant-1 i de la variant-2 existents.

Versions modifica

Per a les dues variants 1 i 2, es defineixen cinc "versions" als estàndards, i cada versió pot ser més adequada que les altres en casos d'ús concrets. La versió s'indica amb la M a la representació de cadena.

Els UUID de la versió 1 es generen a partir d'un temps i un ID de node (normalment l'adreça MAC); Els UUID de la versió 2 es generen a partir d'un identificador (normalment un ID de grup o d'usuari), temps i ID de node; les versions 3 i 5 produeixen UUID deterministes generats mitjançant l'hashing d'un identificador d'espai de noms i un nom; i els UUID de la versió 4 es generen mitjançant un nombre aleatori o pseudoaleatori.

UUID nul modifica

L'UUID "nil", un cas especial, és l'UUID 00000000-0000-0000-0000-000000000000 ; és a dir, tots els bits posats a zero.

Versió 1 (data, hora i adreça MAC) modifica

La versió 1 concatena l'adreça MAC de 48 bits del "node" (és a dir, l'ordinador que genera l'UUID), amb una marca de temps de 60 bits, sent el nombre d'intervals de 100 nanosegons des de la mitjanit del 15 d'octubre de 1582 Temps universal coordinat (UTC).), la data en què es va adoptar per primera vegada el calendari gregorià. {{RFC|4122}} estableix que el valor del temps passa al voltant del 3400 dC, :3depenent de l'algorisme utilitzat, la qual cosa implica que la marca de temps de 60 bits és una quantitat signada. No obstant això, alguns programes, com ara la biblioteca libuuid, tracta la marca de temps com a sense signar, posant el temps de transferència l'any 5236 dC.[14] El temps de transició tal com es defineix a la Rec. X.667 és l'any 3603 dC.[15] :v

Una seqüència de rellotge "uniquificant" de 13 o 14 bits amplia la marca de temps per gestionar els casos en què el rellotge del processador no avança prou ràpid, o on hi ha diversos processadors i generadors d'UUID per node. Quan els UUID es generen més ràpid del que podria avançar el rellotge del sistema, els bits inferiors dels camps de marca de temps es poden generar incrementant-los cada vegada que es genera un UUID, per simular una marca de temps d'alta resolució. Amb cada UUID de la versió 1 corresponent a un únic punt de l'espai (el node) i del temps (intervals i seqüència de rellotge), la possibilitat que dos UUID de la versió 1 generats correctament siguin sense voler iguals és pràcticament nul·la. Atès que la seqüència de temps i rellotge total de 74 bits, es poden generar 274 (1,8 ×1022 1022 o ) UUID de la versió 1 per ID de node, a una velocitat mitjana màxima de 163 mil milions per segon per ID de node.

A diferència d'altres versions d'UUID, els UUID de la versió 1 i -2 basats en adreces MAC de targetes de xarxa depenen per la seva singularitat en part d'un identificador emès per una autoritat de registre central, és a dir, l'identificador únic de l'organització (OUI) part de l'adreça MAC, que l'IEEE emet als fabricants d'equips de xarxa.[16] La singularitat dels UUID de les versions 1 i 2 basades en adreces MAC de targetes de xarxa també depèn de que els fabricants de targetes de xarxa assignin correctament adreces MAC úniques a les seves targetes, que com altres processos de fabricació estan subjectes a errors. A més, alguns sistemes operatius permeten a l'usuari final personalitzar l'adreça MAC, sobretot OpenWRT.[17]

L'ús de l'adreça MAC de la targeta de xarxa del node per a l'ID del node significa que es pot fer un seguiment d'un UUID de la versió 1 fins a l'ordinador que el va crear. De vegades, els documents es poden rastrejar fins als ordinadors on es van crear o editar mitjançant UUID incrustats en ells mitjançant un programari de processament de textos. Aquest forat de privadesa es va utilitzar per localitzar el creador del virus Melissa .[18]

El {{RFC|4122}} permet que l'adreça MAC d'un UUID de versió 1 (o 2) es substitueixi per un ID de node aleatori de 48 bits, ja sigui perquè el node no té una adreça MAC o perquè no és desitjable exposar-la. En aquest cas, la RFC requereix que el bit menys significatiu del primer octet de l'ID de node s'hagi d'establir a 1.[12] Això correspon al bit de multidifusió a les adreces MAC i la seva configuració serveix per diferenciar els UUID on l'ID del node es genera aleatòriament a partir dels UUID basats en les adreces MAC de les targetes de xarxa, que normalment tenen adreces MAC unicast.

Versió 2 (data, hora i adreça MAC, versió de seguretat DCE) modifica

{{RFC|4122}} reserva la versió 2 per als UUID de "seguretat DCE"; però no ofereix cap detall. Per aquest motiu, moltes implementacions d'UUID ometen la versió 2. Tanmateix, l'especificació dels UUID de la versió 2 la proporciona l'especificació de serveis d'autenticació i seguretat DCE 1.1.[4]

Els UUID de la versió 2 són similars a la versió 1, excepte que els 8 bits menys significatius de la seqüència de rellotge se substitueixen per un nombre de "domini local" i els 32 bits menys significatius de la marca de temps es substitueixen per un identificador d'enter significatiu dins del límit especificat. domini local. Als sistemes POSIX, els números de domini local 0 i 1 són per als identificadors d'usuari (UID) i els identificadors de grup (GID) respectivament, i altres números de domini local estan definits pel lloc.[4] En sistemes que no són POSIX, tots els números de domini locals es defineixen pel lloc.

La possibilitat d'incloure un domini/identificador de 40 bits a l'UUID ve amb una compensació. D'una banda, 40 bits permeten aproximadament 1 bilions de valors de domini/identificador per ID de node. D'altra banda, amb el valor del rellotge truncat als 28 bits més significatius, en comparació amb els 60 bits de la versió 1, el rellotge d'un UUID de la versió 2 "marcarà" només una vegada cada 429,49 segons, una mica més de 7 minuts, ja que oposat a cada 100 nanosegons per a la versió 1. I amb una seqüència de rellotge de només 6 bits, en comparació amb els 14 bits de la versió 1, només es poden generar 64 UUID únics per node/domini/identificador per cada tic de rellotge de 7 minuts, en comparació amb els 16.384 valors de la seqüència de rellotge de la versió 1.[19] Per tant, la versió 2 pot no ser adequada per als casos en què es requereixen UUID, per node/domini/identificador, a una velocitat superior a un cada set minuts.

Versions 3 i 5 (basades en noms de l'espai de noms) modifica

Els UUID de la versió 3 i la versió 5 es generen mitjançant un hash d'un identificador i un nom d'espai de noms. La versió 3 utilitza MD5 com a algorisme de resum, i la versió 5 utilitza SHA-1 .

L'identificador de l'espai de noms és en si mateix un UUID. L'especificació proporciona UUID per representar els espais de noms per a URL, noms de domini totalment qualificats, identificadors d'objectes i noms distingits X.500 ; però qualsevol UUID desitjat es pot utilitzar com a designador d'espai de noms.

Per determinar l'UUID de la versió 3 corresponent a un espai de noms i un nom determinats, l'UUID de l'espai de noms es transforma en una cadena de bytes, concatenats amb el nom d'entrada i, a continuació, triturats amb MD5, donant 128 bits. Aleshores, 6 o 7 bits se substitueixen per valors fixos, la versió de 4 bits (per exemple, 0011 ₂ per a la versió 3) i la "variant" UUID de 2 o 3 bits (per exemple, 10 ₂ que indica un UUID {{RFC|4122}}, o 110 ₂). indicant un GUID de Microsoft heretat). Com que 6 o 7 bits estan així predeterminats, només 121 o 122 bits contribueixen a la singularitat de l'UUID.

Els UUID de la versió 5 són similars, però s'utilitza SHA-1 en lloc d'MD5. Com que SHA-1 genera resums de 160 bits, el resum es trunca a 128 bits abans de substituir la versió i els bits variants.

Els UUID de la versió 3 i la versió 5 tenen la propietat que el mateix espai de noms i el mateix nom s'assignaran al mateix UUID. Tanmateix, ni l'espai de noms ni el nom es poden determinar a partir de l'UUID, fins i tot si s'especifica un d'ells, excepte mitjançant la cerca de força bruta. {{RFC|4122}} recomana la versió 5 (SHA-1) sobre la versió 3 (MD5) i adverteix contra l'ús d'UUID de qualsevol versió com a credencials de seguretat.

Versió 4 (aleatòria) modifica

Es genera aleatòriament un UUID de la versió 4. Com en altres UUID, s'utilitzen 4 bits per indicar la versió 4 i 2 o 3 bits per indicar la variant (10 ₂ o 110 ₂ per a les variants 1 i 2 respectivament). Així, per a la variant 1 (és a dir, la majoria dels UUID) un UUID aleatori de versió-4 tindrà 6 bits de variant i versió predeterminats, deixant 122 bits per a la part generada aleatòriament, per a un total de 2 122, o 5,3 ×1036 (5,3undecillion) possibles UUID de la variant-1 de la versió 4. Hi ha la meitat de possibles UUID de la versió 4 variant-2 (GUID heretats) perquè hi ha un bit aleatori menys disponible, 3 bits es consumeixen per a la variant.

Col·lisions modifica

La col·lisió es produeix quan el mateix UUID es genera més d'una vegada i s'assigna a diferents referents. En el cas dels UUID estàndard de la versió 1 i la versió 2 que utilitzen adreces MAC úniques de targetes de xarxa, és poc probable que es produeixin col·lisions, amb una possibilitat creixen només quan una implementació difereix dels estàndards, ja sigui inadvertidament o intencionadament.

En contrast amb els UUID de la versió 1 i la versió 2 generats amb adreces MAC, amb els UUID de la versió 1 i -2 que utilitzen identificadors de nodes generats aleatòriament, els UUID de versió 3 i la versió 5 basats en hash i UUID de versió 4 aleatòria, les col·lisions poden ocórrer fins i tot sense problemes d'implementació, encara que amb una probabilitat tan petita que normalment es pot ignorar. Aquesta probabilitat es pot calcular precisament a partir de l'anàlisi del problema de l'aniversari.[20]

Per exemple, el nombre d'UUID de la versió-4 aleatòria que s'han de generar per tenir una probabilitat del 50% d'almenys una col·lisió és 2,71 quintil·ló, calculat de la següent manera: [21]

 

Aquest nombre equival a generar 1 mil milions d'UUID per segon durant uns 85 anys. Un fitxer que contingués tants UUID, a 16 bytes per UUID, seria uns 45exabytes.

El nombre més petit d'UUID de la versió 4 que s'han de generar perquè la probabilitat de trobar una col·lisió sigui p s'aproxima mitjançant la fórmula:

 

Per tant, la probabilitat de trobar un duplicat dins de 103 bilió d'UUID de la versió 4 és un entre mil milions.

Usos modifica

Sistemes de fitxers modifica

Els usos significatius inclouen eines d'espai d'usuari del sistema de fitxers ext2 / ext3 / ext4 (e2fsprogs utilitza libuuid proporcionat per util-linux), LVM, particions xifrades LUKS, GNOME, KDE i macOS,[22] la majoria de les quals es deriven de la implementació original de Theodore Ts . 'o .[14]

Un dels usos dels UUID a Solaris (utilitzant la implementació de l'Open Software Foundation) és la identificació d'una instància del sistema operatiu en execució amb la finalitat d'associar les dades d'abocament d'error amb l'esdeveniment de gestió d'errors en el cas del pànic del nucli.[23]

L'etiqueta de la partició i l'UUID de la partició s'emmagatzemen al superbloc. Tots dos formen part del sistema de fitxers i no de la partició. Per exemple, ext2–4 contenen un UUID, mentre que NTFS o FAT32 no.

El superbloc és una part del sistema de fitxers, per tant està totalment contingut dins de la partició, per tant, si feu un dd if=/dev/sda1 of=/dev/sdb1, tant sda1 com sdb1 tindran la mateixa etiqueta i UUID.

En components COM modifica

Hi ha diversos tipus de GUID utilitzats al Component Object Model (COM) de Microsoft:

  • IID – interface identifier; (The ones that are registered on a system are stored in the Windows Registry at [HKEY_CLASSES_ROOT\Interface])[24]
  • CLSID – class identifier; (Stored at [HKEY_CLASSES_ROOT\CLSID])
  • LIBID – type library identifier; (Stored at [HKEY_CLASSES_ROOT\TypeLib])[25]
  • CATID – category identifier; (its presence on a class identifies it as belonging to certain class categories, listed at [HKEY_CLASSES_ROOT\Component Categories])[26]

Com a claus de base de dades modifica

Els UUID s'utilitzen habitualment com a clau única a les taules de bases de dades. La funció ElNEWID a la versió 4 de Microsoft SQL Server Transact-SQL retorna els UUID de la versió 4 aleatòria estàndard, mentre que el NEWSEQUENTIALID la funció retorna identificadors de 128 bits similars als UUID que es comprometen a ascendir en seqüència fins al següent reinici del sistema.[27] La funció SYS_GUID a la base de dades Oracle no retorna un GUID estàndard, malgrat el nom. En canvi, retorna un valor RAW de 16 bytes de 128 bits basat en un identificador d'amfitrió i un identificador de procés o fil, una mica similar a un GUID.[28] En el cas de PostgreSQL conté un tipus de dades UUID[29] i pot generar la majoria de versions d'UUID mitjançant l'ús de funcions dels mòduls.[30][31] MySQL proporciona una funció UUID, que genera UUID estàndard de la versió 1.[32]

La naturalesa aleatòria dels UUID estàndard de les versions 3, 4 i 5 i l'ordenació dels camps dins de les versions estàndard 1 i 2 poden crear problemes amb la localitat o el rendiment de la base de dades quan els UUID s'utilitzen com a claus primàries. Per exemple, l'any 2002 Jimmy Nilsson va informar d'una millora significativa en el rendiment amb Microsoft SQL Server quan els UUID de la versió 4 que s'utilitzaven com a claus es van modificar per incloure un sufix no aleatori basat en l'hora del sistema. Aquest enfocament anomenat "COMB" (combined time-GUID) va fer que els UUID no fossin estàndard i fossin significativament més propensos a ser duplicats, com va reconèixer Nilsson, però Nilsson només requeria la singularitat dins de l'aplicació.[33] En reordenar i codificar els UUID de les versions 1 i 2 de manera que la marca de temps sigui primer, es pot evitar la pèrdua de rendiment d'inserció.[34]

Alguns frameworks web, com ara Laravel, tenen suport per a UUID "timestamp first" que es poden emmagatzemar de manera eficient en una columna de base de dades indexada. Això fa que un UUID COMB utilitza el format de la versió 4, però on els primers 48 bits formen una marca de temps dissenyada com a UUIDv1.[35][36] Els formats més especificats basats en la idea UUID COMB inclouen:

  • "ULID", que elimina els 4 bits utilitzats per indicar la versió 4 i utilitza per defecte una codificació base32.[37]
  • Versions UUID 6 a 8, una proposta formal de tres formats UUID COMB.[38]

Referències modifica

  1. «Universally Unique Identifiers (UUID)». H2. [Consulta: 21 març 2021].
  2. ITU-T Recommendation X.667: Generation and registration of Universally Unique Identifiers (UUIDs) and their use as ASN.1 Object Identifier components. Standard. October 2012.
  3. «CDE 1.1: Remote Procedure Call». The Open Group.
  4. 4,0 4,1 4,2 «DCE 1.1: Authentication and Security Services». The Open Group.
  5. «ITU-T Study Group 17 - Object Identifiers (OID) and Registration Authorities Recommendations». ITU.int. [Consulta: 20 desembre 2016].
  6. «Registry Keys and Entries for a Type 1 Online Store». Microsoft Developer Network. Microsoft.
  7. Steele, Nick. «Breaking Down UUIDs».
  8. «UUID Versions Explained».
  9. Leach, Paul. «UUIDs and GUIDs».
  10. «Guid.ToByteArray Method».
  11. «uuid.c».
  12. 12,0 12,1 Leach, P.; Mealling, M.; Salz, R. «A Universally Unique IDentifier (UUID) URN Namespace». Internet Engineering Task Force, 2005 [Consulta: 17 gener 2017].
  13. «Globally Unique Identifiers». Microsoft Developer Network. Microsoft.
  14. 14,0 14,1 «ext2/e2fsprogs.git - Ext2/3/4 filesystem userspace utilities». Kernel.org. [Consulta: 9 gener 2017].[Enllaç no actiu]
  15. «Recommendation ITU-T X.667». www.itu.int, octubre 2012. [Consulta: 19 desembre 2020].
  16. «Registration Authority». IEEE Standards Association.
  17. «MAC Address Setup». OpenWRT, 15-09-2021.
  18. Reiter, Luke. «Tracking Melissa's Alter Egos». ZDNet, 02-04-1999. [Consulta: 16 gener 2017].
  19. Kuchling, A. M. «What's New in Python 2.5». Python.org. [Consulta: 23 gener 2016].
  20. Jesus, Paulo. «ID Generation in Mobile Environments». Repositorium.Sdum.Uminho.pt.
  21. Mathis, Frank H. SIAM Review, 33, 2, juny 1991, pàg. 265–270. DOI: 10.1137/1033051. ISSN: 0036-1445. JSTOR: 2031144. OCLC: 37699182.
  22. gen_uuid.c in Apple's Libc-391, corresponding to Mac OS X 10.4
  23. «Crashdump Restructuring in Solaris». Blogs.Oracle.com. Oracle. [Consulta: 9 gener 2017].
  24. «Interface Pointers and Interfaces». Windows Dev Center - Desktop app technologies. Microsoft. [Consulta: 15 desembre 2015].
  25. «Registering a Type Library». Microsoft Developer Network. Microsoft. [Consulta: 15 desembre 2015].
  26. «Categorizing by Component Capabilities». Windows Dev Center - Desktop app technologies. Microsoft. [Consulta: 15 desembre 2015].
  27. «NEWSEQUENTIALID (Transact-SQL)». Microsoft Developer Network. Microsoft, 08-08-2015. [Consulta: 14 gener 2017].
  28. «Oracle Database SQL Reference». Oracle.
  29. «Section 8.12 UUID Type». PostgreSQL 9.4.10 Documentation. PostgreSQL Global Development Group, 13-02-2020.
  30. «uuid-ossp». PostgreSQL: Documentation: 9.6. PostgreSQL Global Development Group, 12-08-2021.
  31. «pgcrypto». PostgreSQL: Documentation: 9.6. PostgreSQL Global Development Group, 12-08-2021.
  32. «Section 13.20 Miscellaneous Functions». A: MySQL 5.7 Reference Manual. Oracle Corporation. 
  33. Nilsson, Jimmy. InformIT. InformIT, 2002-03-08 [Consulta: 20 juny 2012]. 
  34. «Storing UUID Values in MySQL». Percona, 19-12-2014. Arxivat de l'original el 2020-11-29. [Consulta: 10 febrer 2021].
  35. «Helpers - Laravel - The PHP Framework For Web Artisans». Laravel.com.
  36. Cabrera, Italo Baeza. «Laravel: The mysterious "Ordered UUID"» (en anglès). Medium, 31-01-2020.
  37. «Universally Unique Lexicographically Sortable Identifier». GitHub. ULID, 10-05-2021.
  38. Peabody, Brad; Davis, Kyzer R. (en anglès), 7 octubre 2021. 

Enllaços externs modifica