UUID generator

A necessidade de identificadores únicos em sistemas distribuídos existia muito antes do UUID ter esse nome. Nos anos 1980, a Apollo Computer, empresa que produzia workstations Unix de alto desempenho antes da era do PC, enfrentava um problema real: como identificar recursos em uma rede de máquinas independentes sem um servidor central de controle? A solução emergiu como UUIDs dentro do padrão DCE (Distributed Computing Environment) da Open Software Foundation. Mais tarde, a Microsoft adotou uma variante chamada GUID (Globally Unique Identifier) no COM e no registro do Windows — GUID e UUID são tecnicamente a mesma coisa com nomes diferentes. O RFC 4122, publicado em 2005, formalizou o padrão que a maioria das linguagens e bancos de dados implementa hoje.

Existem sete versões de UUID, cada uma projetada para um propósito diferente. A v1 usa o timestamp atual em intervalos de 100 nanossegundos desde 15 de outubro de 1582 — escolha curiosa: a data da adoção do calendário gregoriano — combinado com o endereço MAC da interface de rede. Funciona e é monotonicamente crescente, mas vaza informações sobre a máquina e o momento exato de geração. A v3 e a v5 são determinísticas: dado o mesmo namespace e o mesmo nome, produzem sempre o mesmo UUID — v3 usa MD5, v5 usa SHA-1 (prefira v5 para código novo). São úteis para criar IDs estáveis a partir de conteúdo, como URLs canônicas. A v4 é a mais popular: 122 bits de aleatoriedade pura — a probabilidade de colisão ao gerar um bilhão de UUIDs por segundo durante cem anos é menor que um em um bilhão. A v7, publicada no RFC 9562 em 2024, é a evolução mais importante: combina os 48 primeiros bits como timestamp Unix em milissegundos com bits aleatórios nos restantes. O resultado é um UUID ordenável por tempo, ideal como chave primária em bancos de dados — diferente da v4, inserções com v7 não fragmentam índices B-tree.

A escolha da versão certa depende do contexto. Para chaves primárias em bancos de dados com alto volume de inserções, v7 é a resposta certa em 2024: é lexicograficamente ordenável, reduz fragmentação de índice e mantém aleatoriedade suficiente para evitar colisões. Para identificadores aleatórios sem requisito de ordenação — tokens de sessão, IDs de pedidos, identificadores de eventos — v4 é a escolha clássica e amplamente suportada. Para criação de IDs estáveis a partir de conteúdo — uma URL canônica, um nome de arquivo, um recurso identificado por string — use v5. Evite v1 em sistemas novos: a inclusão do endereço MAC viola privacidade e pode criar colisões em ambientes virtuais onde o MAC é gerado sinteticamente. Esta ferramenta usa `crypto.getRandomValues` do navegador para garantir aleatoriedade criptograficamente segura nos modos v4 e v7.

The need for unique identifiers in distributed systems predated the UUID name itself. In the 1980s, Apollo Computer — the company that built high-performance Unix workstations before the PC era — faced a real problem: how to identify resources across a network of independent machines without a central control server. The solution emerged as UUIDs inside the DCE (Distributed Computing Environment) standard from the Open Software Foundation. Microsoft later adopted a variant called GUID (Globally Unique Identifier) in COM and the Windows registry — GUID and UUID are technically the same thing with different names. RFC 4122, published in 2005, formalized the standard that most languages and databases implement today.

There are seven UUID versions, each designed for a different purpose. Version 1 uses the current timestamp in 100-nanosecond intervals since October 15, 1582 — an oddly specific choice: the date of the Gregorian calendar adoption — combined with the MAC address of the network interface. It works and is monotonically increasing, but it leaks information about the machine and the exact time of generation. Versions 3 and 5 are deterministic: given the same namespace and name, they always produce the same UUID — v3 uses MD5 and v5 uses SHA-1 (prefer v5 for new code). They are useful for creating stable IDs from content, like canonical URLs. Version 4 is the most popular: 122 bits of pure randomness — the probability of collision when generating one billion UUIDs per second for one hundred years is less than one in a billion. Version 7, published in RFC 9562 in 2024, is the most significant evolution: it combines the first 48 bits as a Unix millisecond timestamp with random bits in the remaining positions. The result is a time-sortable UUID, ideal as a database primary key — unlike v4, v7 insertions do not fragment B-tree indexes.

Choosing the right version depends on context. For primary keys in high-insert databases, v7 is the right answer in 2024: it is lexicographically sortable, reduces index fragmentation, and retains enough randomness to prevent collisions. For random identifiers with no ordering requirement — session tokens, order IDs, event identifiers — v4 is the classic, widely-supported choice. For generating stable IDs from content — a canonical URL, a filename, a string-identified resource — use v5. Avoid v1 in new systems: the MAC address inclusion violates privacy and can create collisions in virtual environments where the MAC is synthetically generated. This tool uses the browser's `crypto.getRandomValues` to guarantee cryptographically secure randomness in v4 and v7 modes.

La necesidad de identificadores únicos en sistemas distribuidos existía mucho antes de que el UUID tuviera ese nombre. En los años ochenta, Apollo Computer — la empresa que fabricaba estaciones de trabajo Unix de alto rendimiento antes de la era del PC — enfrentaba un problema real: cómo identificar recursos en una red de máquinas independientes sin un servidor central de control. La solución surgió como UUIDs dentro del estándar DCE (Distributed Computing Environment) de la Open Software Foundation. Microsoft adoptó más tarde una variante llamada GUID (Globally Unique Identifier) en COM y en el registro de Windows — GUID y UUID son técnicamente lo mismo con nombres distintos. El RFC 4122, publicado en 2005, formalizó el estándar que la mayoría de lenguajes y bases de datos implementa hoy.

Existen siete versiones de UUID, cada una diseñada para un propósito diferente. La versión 1 usa la marca de tiempo actual en intervalos de 100 nanosegundos desde el 15 de octubre de 1582 — una elección curiosamente específica: la fecha de adopción del calendario gregoriano — combinada con la dirección MAC de la interfaz de red. Funciona y es monótonamente creciente, pero filtra información sobre la máquina y el momento exacto de generación. Las versiones 3 y 5 son deterministas: dado el mismo espacio de nombres y nombre, siempre producen el mismo UUID — v3 usa MD5 y v5 usa SHA-1 (prefiere v5 en código nuevo). Son útiles para crear IDs estables desde contenido, como URLs canónicas. La versión 4 es la más popular: 122 bits de aleatoriedad pura — la probabilidad de colisión al generar mil millones de UUIDs por segundo durante cien años es menor a uno en mil millones. La versión 7, publicada en el RFC 9562 en 2024, es la evolución más importante: combina los primeros 48 bits como marca de tiempo Unix en milisegundos con bits aleatorios en las posiciones restantes. El resultado es un UUID ordenable por tiempo, ideal como clave primaria en bases de datos — a diferencia de v4, las inserciones con v7 no fragmentan los índices B-tree.

Elegir la versión correcta depende del contexto. Para claves primarias en bases de datos con alto volumen de inserciones, v7 es la respuesta correcta en 2024: es lexicográficamente ordenable, reduce la fragmentación de índices y conserva suficiente aleatoriedad para evitar colisiones. Para identificadores aleatorios sin requisito de orden — tokens de sesión, IDs de pedidos, identificadores de eventos — v4 es la elección clásica y ampliamente soportada. Para crear IDs estables desde contenido — una URL canónica, un nombre de archivo, un recurso identificado por cadena — usa v5. Evita v1 en sistemas nuevos: la inclusión de la dirección MAC viola la privacidad y puede generar colisiones en entornos virtuales donde la MAC se genera sintéticamente. Esta herramienta usa `crypto.getRandomValues` del navegador para garantizar aleatoriedad criptográficamente segura en los modos v4 y v7.