para ambas as variantes 1 e 2, cinco “versões” são definidas nas normas, e cada versão pode ser mais apropriada do que as outras em casos específicos de uso. A versão é indicada pelo M na representação de texto.

Versão-1 UUIDs são gerados a partir de um tempo e um nó ID (geralmente o endereço MAC); versão-2 UUIDs são gerados a partir de um identificador( geralmente um grupo ou ID de usuário), tempo, e um nó ID; versões 3 e 5 produzem UUIDs determinísticos gerados por amarrar um identificador de espaço de nomes e nome; e a versão-4 UUIDs são geradas usando um número aleatório ou pseudo-aleatório.

Nil UUIDEdit

The” nil “UUID, a special case, is the UUID 00000000-0000-0000-0000-000000000000; that is, all bits set to zero.

Versão 1 (data-horário e o endereço MAC)Editar

Versão 1 concatena os 48 bits de endereço MAC do “nó” (isto é, o computador gerar o UUID), com 60 bits carimbo de data / hora, sendo o número de intervalos de 100 nanossegundos desde a meia-noite de 15 de outubro de 1582, Horário de Universal Coordenado (UTC), a data em que o calendário Gregoriano foi adotado pela primeira vez. RFC 4122 afirma que o valor do tempo rola por volta de 3400 AD,:3 dependendo do algoritmo usado, o que implica que o timestamp de 60 bits é uma quantidade assinada. No entanto, alguns softwares, como a libuuid library, tratam o timestamp como não assinado, colocando o tempo de rollover em 5236 AD. O tempo de capotagem definido pela ITU-T Rec. X. 667 é 3603 D. C.: v

uma sequência de clock “uniquificante” de 13 ou 14 bits estende o timestamp, a fim de lidar com casos em que o clock do processador não avança rápido o suficiente, ou onde existem múltiplos processadores e geradores UUID por nó. Quando UUIDs são gerados mais rápido do que o relógio do sistema poderia avançar, os bits mais baixos dos campos de timestamp podem ser gerados incrementando-o cada vez que um UUID está sendo gerado, para simular um timestamp de alta resolução. Com cada UUID de Versão 1 correspondente a um único ponto no espaço (o nó) e tempo (intervalos e sequência de clock), a chance de dois UUIDs de Versão-1 corretamente gerados sendo involuntariamente o mesmo é praticamente nula. Desde a sequência de tempo e clock total 74 bits, 274 (1.8×1022, ou 18 sextillion) versão-1 UUIDs pode ser gerado por nó ID, a uma taxa média máxima de 163 bilhões por segundo por nó ID.

em contraste com outras versões UUID, os UUIDs das versões 1 e -2 baseados em endereços MAC a partir de cartões de rede dependem, em parte, da sua singularidade num identificador emitido por uma autoridade central de Registo, nomeadamente a parte do identificador único organizacionalmente (OUI) do endereço MAC, que é emitido pelo IEEE aos fabricantes de equipamento de rede. A singularidade dos UUIDs da versão-1 e da versão-2 baseados em endereços MAC de cartão de rede também depende dos fabricantes de cartões de rede atribuir corretamente endereços MAC únicos para seus cartões, que, como outros processos de fabricação está sujeito a erro.

O uso do endereço MAC do nó do cartão de rede para o ID do nó significa que um UUID versão-1 pode ser rastreado de volta para o computador que o criou. Documentos às vezes podem ser rastreados até os computadores onde eles foram criados ou editados através de UUIDs incorporados a eles por software de processamento de texto. Este buraco de Privacidade foi usado para localizar o criador do vírus Melissa.

RFC 4122 permite que o endereço MAC em um UUID de Versão-1 (ou 2) seja substituído por um ID de nó aleatório de 48 bits, seja porque o nó não tem um endereço MAC, ou porque não é desejável expô-lo. Nesse caso, o RFC requer que o bit menos significativo do primeiro octeto do ID do nó seja definido como 1. Isto corresponde ao bit multicast em endereços MAC, e a configuração serve para diferenciar UUIDs onde o ID do nó é gerado aleatoriamente a partir de UUIDs baseados em endereços MAC de placas de rede, que tipicamente têm endereços unicast MAC.

Version 2 (date-time and MAC address,DCE security version) Edit

RFC 4122 reserves version 2 for “DCE security” UUIDs; but it does not provide any details. Por esta razão, muitas implementações UUID omitem a versão 2. No entanto, a especificação da versão-2 UUIDs é fornecida pela DCE 1.1 Authentication and Security Services specification.

Versão-2 UUIDs são semelhantes à versão 1, exceto que os 8 bits menos significativos da sequência de clock são substituídos por um número de “domínio local”, e os 32 bits menos significativos do timestamp são substituídos por um identificador inteiro significativo dentro do domínio local especificado. Em sistemas POSIX, os números de domínio local 0 e 1 são para ids de usuário (UIDs) e ids de grupo (GIDs) respectivamente, e outros números de domínio local são definidos pelo site. Em sistemas não-POSIX, todos os números de domínio locais são definidos pelo site.

a capacidade de incluir um domínio de 40 bits / identificador no UUID vem com um tradeoff. Por um lado, 40 bits permitem cerca de 1 trilhão de valores de domínio/identificador por ID do nó. Por outro lado, com o valor do relógio truncado para os 28 bits mais significativos, em comparação com 60 bits na versão 1, o relógio em uma versão 2 do UUID vai “tick” apenas uma vez a cada 429.49 segundos, pouco mais de 7 minutos, em oposição a cada 100 nanossegundos para a versão 1. E com uma sequência de clock de apenas 6 bits, em comparação com 14 bits na versão 1, apenas 64 UUIDs únicos por nó/domínio/identificador podem ser gerados por carrapato de clock de 7 minutos, em comparação com 16.384 valores de sequência de clock para a versão 1. Assim, a versão 2 pode não ser adequada para casos em que UUIDs são necessários, por nó/domínio/identificador, a uma taxa superior a cerca de um a cada sete segundos.

as versões 3 e 5 (namespace name-based)editam

Versão-3 e versão-5 UUIDs são gerados por hashing um identificador de namespace e nome. A versão 3 usa MD5 como o algoritmo de hashing, e a versão 5 usa SHA-1.

O identificador do espaço de nomes é em si um UUID. A especificação fornece UUIDs para representar os espaços de nomes para URLs, nomes de domínio totalmente qualificados, identificadores de objetos e nomes distintos X. 500; mas qualquer UUID desejado pode ser usado como um designador de espaços de nomes.

para determinar o UUID da versão-3 correspondente a um dado espaço de nomes e nome, o UUID do espaço de nomes é transformado em uma cadeia de bytes, concatenado com o nome de entrada, em seguida, hashed com MD5, rendendo 128 bits. Em seguida, 6 ou 7 bits são substituídos por valores fixos, a versão de 4 bits (e.g. 00112 para a versão 3), e a “variante” UUID 2 – ou 3-bit (por exemplo, 102 indicando um RFC 4122 UUIDs, ou 1102 indicando um GUID Microsoft legacy). Uma vez que 6 ou 7 bits são assim pré-determinados, apenas 121 ou 122 bits contribuem para a unicidade do UUID.

Versão-5 UUIDs são similares, mas SHA-1 é usado em vez de MD5. Uma vez que o SHA-1 gera uma digestão de 160 bits, o digest é truncado para 128 bits antes que a versão e os bits variantes sejam substituídos.

Versão-3 e versão-5 UUIDs têm a propriedade que o mesmo espaço de nomes e nome irá mapear para o mesmo UUID. No entanto, nem o espaço de nomes nem o nome podem ser determinados a partir do UUID, mesmo que um deles seja especificado, exceto por Busca por força bruta. RFC 4122 recomenda a versão 5 (SHA-1) sobre a versão 3 (MD5), e adverte contra o uso de UUIDs de qualquer versão como credenciais de segurança.

versão 4 (aleatória)editar

uma versão 4 UUID é gerada aleatoriamente. Como em outros UUIDs, 4 bits são usados para indicar a versão 4, e 2 ou 3 bits para indicar a variante (102 ou 1102 para as variantes 1 e 2, respectivamente). Assim, para a variante 1 (isto é, a maioria Uuid) aleatória versão 4 UUID terá 6 predeterminado variante e versão bits, deixando 122 bits para gerada aleatoriamente parte, para um total de 2122, ou 5,3×1036 (5.3 undecillion) possível versão 4 variant-1 UUIDs. Há metade do número possível de UUIDs da versão 4 variante – 2 (legacy GUIDs) porque há menos um bit aleatório disponível, 3 bits sendo consumidos para a variante.