Validar UUID

Um UUID são 128 bits, escritos normalmente como 32 dígitos hexadecimais em cinco grupos separados por hífen. De uma string assim dá para conferir três coisas: se a forma está correta, qual versão o décimo terceiro caractere declara e qual variante os primeiros bits do quarto grupo indicam.

O que não dá para conferir é se o identificador chegou a ser atribuído alguma vez. Não há registro nem dígito verificador — um UUID não carrega informação sobre ser real. Quem precisa saber se existe um registro tem que perguntar ao próprio banco; esta página responde a pergunta anterior, a de se vale a pena perguntar.

O número da versão é o primeiro caractere do terceiro grupo, ou seja o décimo terceiro dígito hexadecimal. Um `4` ali significa aleatório, um `1` baseado em tempo, um `7` ordenável no tempo conforme a RFC 9562, e o `3` e o `5` correspondem às variantes baseadas em nome com MD5 e com SHA-1.

Isso se lê a olho assim que se sabe onde olhar, e é a forma mais rápida de confirmar uma suspeita. Quem vir um identificador que naquela posição não tem nenhum dos números conhecidos está diante de um UUID anterior à numeração de versões, ou de algo que só parece um.

O primeiro caractere do quarto grupo tem que ser `8`, `9`, `a` ou `b`. Esses quatro dígitos compartilham os bits iniciais `10`, que são a variante reservada pela especificação; qualquer outro valor pertence a esquemas antigos ou reservados.

Na prática: um identificador com a versão correta mas com um `c` ou um `f` nessa posição não foi gerado por uma biblioteca conforme. A causa habitual são os geradores caseiros que encadeiam 32 dígitos aleatórios e ignoram as duas posições fixas — uma falha que pode viver anos sem que ninguém perceba.

A especificação exige minúsculas na geração e tolerância com maiúsculas na leitura. Na prática aparecem as duas: o .NET e muitas ferramentas do Windows escrevem tradicionalmente em maiúsculas, a maior parte do resto em minúsculas.

A isso se somam dois invólucros frequentes: as chaves, da notação do registro do Windows, e um `urn:uuid:` na frente, do espaço de nomes URN. Os dois são reconhecidos aqui e ignorados. Quem for comparar por conta própria precisa normalizar antes, senão dois identificadores idênticos falham a comparação por causa da forma de escrever.

A forma sem hífen é armazenamento corriqueiro e perfeitamente normal numa coluna: são os mesmos 128 bits, e os hífens sempre foram só apresentação. Vários bancos guardam assim, e o MySQL costuma guardar em dezesseis bytes binários, que é a forma mais compacta e a menos legível.

A consequência é que a mesma chave pode aparecer de três jeitos em três lugares do mesmo sistema, e uma junção entre eles falha sem erro nenhum: ela simplesmente não encontra linha. Se uma consulta devolve vazio onde deveria devolver um registro, comparar as formas antes de comparar os dados costuma resolver em um minuto.

Um UUID versão 1 contém o instante de criação com precisão de 100 nanossegundos e, no último grupo, tradicionalmente o endereço MAC da placa de rede. As duas coisas são reconstruíveis por quem tem o identificador.

Não é teórico: 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; as bibliotecas modernas, além disso, colocam um nó aleatório em vez do endereço real.

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 — e isso resolve o problema pelo qual muitos times evitavam UUID como chave primária.

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

As versões 3 e 5 não são aleatórias: elas são o hash de um nome dentro de um espaço de nomes, com MD5 na 3 e SHA-1 na 5. O mesmo nome no mesmo espaço produz sempre o mesmo identificador, em qualquer máquina e a qualquer momento.

É a propriedade certa quando o identificador precisa ser derivado e não sorteado — o mesmo recurso importado duas vezes recebendo a mesma chave, por exemplo. E é a propriedade errada quando o nome de entrada é adivinhável, porque então o identificador também é: um UUID versão 5 derivado de um e-mail pode ser recalculado por qualquer pessoa que conheça o e-mail.

Um identificador só de zeros é o UUID nil, previsto expressamente na especificação e formalmente válido embora não carregue versão nem variante. Ele significa «nenhum» e aparece onde um campo não pode ser nulo mas precisa estar vazio.

Desde a RFC 9562 existe o contrário dele, o UUID max, só de `f`. Os dois passam na conferência daqui e são identificados como o que são. Quem encontrar um UUID nil em dados de produção deveria desconfiar: quase nunca é um marcador colocado de propósito, e sim um gerador que falhou em silêncio.

As falhas mais comuns são triviais: 31 dígitos em vez de 32 porque um se perdeu na cópia, um espaço no fim vindo de uma célula de planilha, ou uma string cortada por um campo de banco com um caractere a menos do que devia.

Nesses casos aqui é dito o que falhou, em vez de um simples «inválido». Esse é o valor real: quem recebe um identificador dentro de uma mensagem de erro quer saber se perdeu um caractere ou se o outro lado enviou algo que nunca foi um UUID.

Não há diferença técnica. GUID é o nome que a Microsoft deu ao mesmo identificador de 128 bits, e os dois termos são intercambiáveis; o que muda é o ecossistema em que cada palavra é usada e, com ele, a forma de escrever que você vai encontrar.

Na prática isso significa que um GUID vindo de uma ferramenta do Windows costuma chegar em maiúsculas e entre chaves, e passa nesta conferência exatamente como qualquer outro UUID. Se algum sistema seu recusa um valor por ser «GUID e não UUID», o que ele está recusando é a forma de escrever, e a correção é normalizar antes de comparar.

Um UUID não é dado pessoal por si só, mas costuma ser a chave que leva a um: um identificador de usuário, uma chave de sessão, um número de protocolo de um sistema de atendimento. Como a conferência acontece na página, nada disso é compartilhado conosco.

Com os identificadores versão 1 soma-se o fato de eles carregarem informação dentro: o instante e, possivelmente, o MAC da máquina que os criou. Mandar justamente esses valores por um formulário alheio seria a pior ideia — e é a razão pela qual aqui a análise é feita onde o identificador já está.