Gerador e decodificador de ULID

O que é um ULID?

Um ULID é um identificador de 26 caracteres que carrega a hora em que foi criado. Os 10 primeiros caracteres são uma contagem de 48 bits de milissegundos desde 1970; os 16 restantes são 80 bits de aleatoriedade. As duas metades são escritas no base32 de Crockford, um alfabeto com os dez dígitos e vinte e duas letras que deixa de fora I, L, O e U justamente porque são as que se leem errado.

A ideia de pôr o relógio na frente é que ordenar o texto ordena por data. Um UUID versão 4 é puro acaso, então uma tabela indexada por ele espalha as escritas pelo índice inteiro; identificadores que crescem com o tempo mantêm as linhas novas juntas. É o mesmo raciocínio por trás do UUID versão 7, que a RFC 9562 padronizou em 2024 e que é a melhor escolha quando dá para usar: o ULID veio antes, não é padrão do IETF e vale conhecer principalmente porque muito software já o emite.

O formato também cabe onde um UUID não cabe. São 26 caracteres contra 36, sem hifens, indiferente a maiúsculas, e aguenta muito melhor do que o hexadecimal ser ditado ou copiado à mão de uma tela.

Como usar

1. Escolha quantos precisa e copie. Até cem de uma vez, tirados da fonte criptográfica de aleatoriedade do seu navegador. Copie um só ou o lote inteiro como linhas.
2. Deixe a caixa de ordem marcada, a menos que saiba que quer desligá-la. Ela faz os identificadores criados no mesmo milissegundo subirem em vez de serem sorteados separadamente, que é o que garante que um lote fique na ordem em que foi criado.
3. Cole qualquer ULID na segunda caixa para lê-lo de volta. Você vê o instante da criação no seu próprio fuso, a metade aleatória, a forma canônica e os mesmos bits escritos em hexadecimal.

Três coisas que as outras ferramentas de ULID erram

A primeira é que um lote de ULIDs quase nunca está ordenado. Vinte e seis caracteres em base32 só ficam em ordem se os valores por trás crescerem, e dois identificadores criados no mesmo milissegundo dividem o carimbo de tempo, então a ordem é decidida pela metade aleatória. Dois sorteios independentes são igualmente prováveis nos dois sentidos, ou seja, é cara ou coroa por construção e não uma falha ocasional — e é isso que a medição mostra. Com 20.000 chamadas dentro de um mesmo milissegundo, a taxa de ordem errada deu 49,9, 49,6 e 50,2 por cento para três fluxos de aleatoriedade diferentes, e 49,6 e 50,1 por cento em duas rodadas contra a implementação de referência de JavaScript em tempo real. A fábrica monotônica dela zera todas. Como a ordenação é a razão inteira para preferir este formato, aqui ela vem ligada por padrão e é uma caixa de seleção, não uma suposição.

A segunda é o estouro. Vinte e seis caracteres base32 guardam 130 bits e um ULID tem 128, então o primeiro caractere só pode ir de 0 a 7: o maior ULID possível é 7ZZZZZZZZZZZZZZZZZZZZZZZZZ. A especificação diz que qualquer tentativa de decodificar um maior deve ser rejeitada por todas as implementações, exatamente para evitar bugs de estouro. Testando os trinta e dois primeiros caracteres possíveis contra a implementação de referência, o validador dela devolve verdadeiro para todos enquanto o próprio decodificador lança erro em vinte e quatro: três quartos das cadeias que ela chama de válidas não são ULIDs. Aqui esse caso tem veredicto próprio em vez de passar batido.

A terceira é a transcrição. Crockford desenhou este alfabeto para que as letras excluídas pudessem ser recuperadas na leitura: I e L são decodificados como 1, O como 0, e maiúsculas não importam. A implementação de referência rejeita as três e traz à parte uma função de reparo que você precisa chamar, então um ULID copiado de um print falha sem motivo algum. Esta ferramenta resolve e avisa que resolveu, o que não é a mesma coisa que resolver em silêncio.

Limites honestos

O carimbo de tempo vale o que valer o relógio da máquina que gerou o identificador. Um ULID diz quando aquela máquina achava que era; num aparelho com a hora errada, ou que voltou atrás por um segundo bissexto ou uma correção de NTP, o valor é falso e o formato não registra nada disso. A ordenação é uma conveniência, não uma auditoria.

A metade aleatória não é uma assinatura. Qualquer um pode gerar um identificador com o carimbo de tempo que quiser: o formato não tem segredo nem soma de verificação, então um ULID não prova nada sobre quem o criou ou quando. Trate-o como um nome, nunca como prova.

A conversão de ULID para UUID que toda ferramenta oferece é exata, mas o resultado não é um UUID. São os mesmos 128 bits escritos em hexadecimal, e um UUID reserva quatro bits para o número de versão e dois para a variante, dos quais a metade aleatória de um ULID não sabe nada. Cerca de um em cada sessenta e quatro cai por acaso em valores que passariam por um UUID versão 4; o resto são cadeias hexadecimais com cara de UUID que nenhum analisador conforme vai aceitar. Esta página mostra o hexadecimal e diz em qual caso o seu está.

Por fim, a ordem monotônica é por gerador, não global. Dois servidores gerando no mesmo milissegundo vão se intercalar conforme caírem as metades aleatórias, e nada os coordena. Dentro de uma aba, um processo ou um pool de conexões a ordem se mantém; entre máquinas, não.

Por que é grátis?

Tudo acontece no seu navegador. Os bits aleatórios vêm da sua própria fonte criptográfica, o relógio é o seu, e nenhum identificador é enviado a lugar nenhum — o que aqui importa mais do que o normal, já que um identificador que um servidor já viu não é bem seu para usar como credencial.

Não há cadastro, nem limite, nem marca d’água, porque não há custo de servidor a recuperar.