Escolha a quantidade de UUID e o formato das letras. Envie o formulário para gerar os valores no servidor e copie a lista para seus dados de teste.
Escolha quantos identificadores você precisa (de 1 a 100) e se as letras saem em minúsculas ou maiúsculas; o formulário gera os valores no servidor e devolve a lista, um por linha. Cada valor é um UUID versão 4 de 128 bits na forma canônica 8-4-4-4-12, pronto para colar em um fixture, em dados de seed ou em uma chave de banco de dados.
A versão 4 é construída com bits aleatórios: não carrega data e hora, endereço MAC nem hash de nome, então o valor não revela qual máquina o criou nem quando. É isso que faz dele um identificador opaco — e também o motivo de não servir para ordenar registros por data de criação.
Um UUID são 128 bits escritos como 32 dígitos hexadecimais em cinco grupos separados por hifens. Na versão 4, 122 desses bits são aleatórios: o nibble que abre o terceiro grupo fica fixo em 4 para identificar a versão, e os dois bits mais significativos do quarto grupo ficam em 10 para seguir a variante do RFC 4122.
Esses seis bits fixos explicam por que um v4 legítimo não é apenas 32 caracteres hexadecimais sorteados: validadores rígidos e bibliotecas que conferem a versão rejeitam valores gerados por hash ou contador sem esses bits.
Com 122 bits aleatórios existem cerca de 5,3 × 10^36 valores possíveis; a chance de repetir um valor é desprezível em qualquer volume realista. A página ainda confere os valores do lote e regenera os repetidos, então um lote de 100 identificadores nunca traz duplicados.
A colisão que importa na prática é a dos seus próprios dados: se você comparar strings com caixa diferente dependendo da collation do banco, pode acabar com duas linhas para o mesmo valor. Guarde o UUID em uma única forma (minúsculas, por exemplo) ou em uma coluna binária.
Um v4 é uma boa chave primária quando a ordem não importa: 16 bytes de entropia impossíveis de adivinhar. Se o banco sofre com a baixa localidade do índice (inserções espalhadas pela árvore), avalie UUID v7 ou ULID, que trazem um carimbo de tempo ordenável; no armazenamento, CHAR(36) é legível e BINARY(16) economiza espaço.
Não use como segredo: o valor é gerado no servidor e volta para a página, então trate-o como identificador público. Para tokens de sessão ou chaves, gere o segredo no seu próprio backend com um gerador criptográfico e guarde apenas o hash.
É aleatório: a versão 4 não codifica carimbo de tempo, endereço MAC nem nome, ao contrário da versão 1. Ele traz 122 bits aleatórios e seis bits fixos que indicam a versão e a variante.
Sim. O RFC 4122 trata UUIDs sem diferenciar maiúsculas de minúsculas: 0BC4… e 0bc4… são o mesmo valor. Escolha um formato para o banco e para as comparações, principalmente se a coluna usar collation binária.
De 1 a 100 por envio. Se você alterar o formulário com um valor fora da faixa, o servidor corrige: 0, números negativos ou texto não numérico viram 1, e qualquer valor acima de 100 é limitado a 100.
Cada requisição gera a lista no servidor, inclusive a primeira carga, que mostra um UUID por padrão. Não há cache nem valores pré-gerados: recarregar a página produz identificadores diferentes.
Sim, é um uso comum: não se repete e não revela nada da sua infraestrutura. Se a ordem de inserção no índice importa, prefira UUID v7 ou ULID; se o espaço importa, guarde os 16 bytes em BINARY(16) em vez de uma string de 36 caracteres.
Não é o indicado. O valor é gerado no servidor e exibido na página, então trate-o como público e use-o como identificador. Para tokens e chaves, gere a entropia no seu backend e armazene apenas o hash.