Gerador de UUID

É usado o gerador criptográfico do navegador, que tira a entropia dele do sistema operacional. Não é o `Math.random()`, cuja saída é reproduzível a partir do estado interno e que nunca deveria alimentar um identificador que alguém não pode adivinhar.

A diferença não aparece no resultado: os dois produzem strings com a aparência correta e ambas passariam em qualquer validação de forma. Ela só se percebe no dia em que alguém prevê o próximo identificador, e a essa altura ele já está em produção. Se o navegador não oferece o gerador criptográfico, aqui a página para em vez de recorrer ao fraco.

Um UUID são 128 bits, mas na versão 4 quatro deles são fixados pelo número de versão e dois pela variante. Sobram 122 aleatórios, que ainda são tantos que a probabilidade de colisão é irrelevante mesmo gerando bilhões.

Essa margem é o que permite gerar de forma distribuída sem coordenação: dois serviços que nunca se falam podem criar identificadores ao mesmo tempo sem combinar nada. É a propriedade pela qual os UUID existem, e a razão pela qual um contador autoincremental deixa de servir assim que há mais de uma máquina escrevendo.

A versão é o primeiro caractere do terceiro grupo, ou seja o décimo terceiro dígito hexadecimal: aqui é sempre um `4`. A variante é o primeiro caractere do quarto grupo e tem que ser `8`, `9`, `a` ou `b`, porque esses quatro dígitos compartilham os bits iniciais `10` que a especificação reserva para si.

Dá para conferir a olho, e é a forma mais rápida de detectar um gerador caseiro. Quem encadeia 32 dígitos hexadecimais aleatórios sem fixar essas duas posições produz identificadores que parecem UUID, formalmente não são, e funcionam por anos até alguma coisa validá-los de verdade.

Um UUID versão 1 contém o instante de criação com precisão de 100 nanossegundos e, tradicionalmente, o endereço MAC da placa de rede. As duas coisas são reconstruíveis por quem tem o identificador, então uma chave de banco visível de fora vira uma pista sobre a máquina e sobre o momento.

Não é preocupação teórica: foi por essa via que em 1999 se chegou ao autor do vírus Melissa, porque o Word escrevia o MAC nos identificadores de documento. Onde um identificador é visto de fora, a versão 4 é a escolha certa.

A versão 7 coloca na frente uma marca de tempo em milissegundos e preenche o resto com acaso, de modo que os identificadores ficam ordenados no tempo pelo próprio valor. Isso resolve o problema pelo qual muitos times evitaram usar UUID como chave primária.

O motivo é o índice. Chaves aleatórias escrevem em pontos que mudam o tempo todo dentro de uma árvore B, o que parte páginas e desperdiça o cache; em tabelas grandes isso custa desempenho de escrita mensurável. Uma chave crescente escreve sempre no fim. A contrapartida é que o instante de criação volta a ser legível.

Aqui eles são gerados em minúsculas e sem enfeite, que é o que a especificação pede na criação. Na leitura é preciso aceitar maiúsculas, e de fato o .NET e muitas ferramentas do Windows escrevem tradicionalmente assim.

Também circulam dois invólucros: as chaves, que vêm da notação do registro do Windows, e um `urn:uuid:` na frente, que vem do espaço de nomes URN. Nenhum dos dois faz parte do identificador. Quem for comparar por conta própria deveria normalizar para minúsculas e tirar os invólucros, senão dois identificadores iguais falham a comparação por causa da forma de escrever.

Um identificador versão 4 é impossível de adivinhar na prática, e daí a usá-lo como token de acesso há um passo que se dá com frequência demais: um link «privado» cuja única proteção é a URL conter um UUID.

O problema não é a entropia e sim onde a URL vai parar: no histórico, no cabeçalho de referrer do clique seguinte, no log de um proxy, na mensagem em que alguém repassa. Um token deveria expirar e poder ser revogado, e um UUID não faz nenhuma das duas coisas.

Um UUID é ótimo como chave interna e péssimo como identificador que uma pessoa precisa ler, ditar por telefone ou digitar de novo. São 36 caracteres sem nenhuma estrutura visual e sem dígito verificador, então um erro de leitura não é detectado, só resulta em «não encontrado».

A prática que funciona é ter os dois: o UUID como chave, e um código curto e legível para o atendimento — algo com poucos caracteres, sem letras que se confundam com dígitos e com um verificador. Isso não é uma limitação do UUID, é o reconhecimento de que identificador de máquina e identificador de pessoa são requisitos diferentes.

O limite de cem não tem a ver com custo: gerar um milhão levaria uma fração de segundo e não nos custaria nada, porque a conta é feita na sua máquina. Ele existe porque acima disso a saída deixa de ser algo que dá para ler e conferir, e vira um bloco que se copia no escuro.

Se você precisa de dezenas de milhares para uma massa de teste, o lugar certo é um script, onde eles nascem já dentro do processo que vai usá-los. Uma página web como intermediária nesse caso só acrescenta um copiar e colar em que dá para perder linhas sem perceber.

Existem serviços que devolvem UUID por API, e usá-los significa que mais alguém viu exatamente os identificadores que você vai gravar no seu banco. Não é catastrófico e também não é necessário: gerar é uma operação local de duas linhas.

Aqui isso acontece na sua aba, com a criptografia do navegador. Não há requisição envolvida, então funciona igual sem internet depois que a página carregou — no ônibus, atrás de um proxy corporativo ou numa máquina isolada.

Escrito da forma habitual, um UUID ocupa 36 caracteres; os mesmos 128 bits numa coluna binária ocupam dezesseis bytes. A diferença parece pequena e deixa de parecer quando ela se multiplica por dezenas de milhões de linhas e ainda aparece em cada índice que inclui essa chave.

Os bancos resolvem isso de formas diferentes: o PostgreSQL tem um tipo próprio que já guarda os dezesseis bytes, e no MySQL o caminho comum é uma coluna binária com conversão nas duas pontas. Vale decidir antes de a tabela crescer, e vale mais ainda saber qual forma está guardada quando duas partes do sistema não conseguem encontrar a mesma linha.

Um UUID recém-gerado não contém dado pessoal nenhum — são bits aleatórios. Ele vira um pseudônimo assim que é associado a uma pessoa dentro do seu sistema, e a partir daí as obrigações são as mesmas de qualquer outro identificador de usuário.

O que esta página garante é o passo anterior: os identificadores nascem no seu aparelho e não passam por nenhum serviço intermediário. É uma diferença pequena e real, sobretudo quando eles são gerados em lote para uma migração de dados de produção.