Gerador de ULID

O que o Gerador de ULIDs faz

A página ULID Generator permite-lhe seleccionar o formato ULID, definir um número de identificadores entre 1 e 100, e obter instantaneamente uma lista de strings de 26 caracteres, únicas e ordenáveis cronologicamente. Cada ULID é gerado localmente no seu browser usando crypto.getRandomValues() — nunca é enviado para qualquer servidor. Os estados da interface incluem “Ready.”, “Generated.” e “Copied all!” (quando a lista inteira é copiada para a área de transferência). Clicar num ULID individual copia apenas esse identificador.

O que distingue esta página das restantes

Ao contrário dos outros formatos disponíveis na mesma ferramenta (UUID v4, UUID v7, NanoID, etc.), o ULID produz identificadores mais curtos (26 caracteres contra 36 do UUID) e utiliza exclusivamente o alfabeto base32 de Crockford. Esse alfabeto (0‑9, A‑Z excepto I, L, O, U) torna os ULIDs insensíveis a maiúsculas/minúsculas e sem hífenes. São também ordenáveis lexicograficamente pela data de criação, porque os primeiros 10 caracteres codificam um carimbo temporal com precisão de milissegundo (48 bits). Os restantes 16 caracteres (80 bits) são aleatórios, perfazendo os 128 bits totais subjacentes.

Esta página não apresenta opções para “maiúsculas” ou “hífenes” — isso deve‑se ao próprio formato: o ULID é inerentemente insensível a maiúsculas (aceita tanto maiúsculas como minúsculas sem alterar o valor) e não contém hífenes. A ausência destas opções simplifica a interface e evita confusão sobre como o identificador é representado.

Estrutura interna de um ULID

Um ULID é composto por duas partes justapostas:

A codificação usa o alfabeto base32 de Crockford: 0123456789ABCDEFGHJKMNPQRSTVWXYZ. As letras I, L, O, U são omitidas por serem visualmente ambíguas (I/l, O/0, U/V). Como o alfabeto é mapeado de forma biunívoca para os 32 valores possíveis, os caracteres maiúsculos e minúsculos são equivalentes — ABCDEFGHJKMNPQRSTVWXYZ vs. abcdefghjkmnpqrstvwxyz. Na prática, a maioria das implementações gera ULIDs em maiúsculas, mas o sistema de leitura aceita ambas.

O timestamp de 48 bits permite representar cerca de 9 000 anos desde a época, o que é suficiente para a generalidade das aplicações. A componente aleatória de 80 bits dá origem a 2⁸⁰ ≈ 1,2 × 10²⁴ valores possíveis, garantindo uma probabilidade de colisão extremamente baixa, mesmo com milhões de gerações por segundo, desde que os timestamps sejam distintos. Quando vários ULIDs são criados no mesmo milissegundo, a ordenação entre eles é aleatória — não há garantia de sequencialidade temporal nesse intervalo.

Comparação com UUID v4 e UUID v7

A principal vantagem do ULID sobre o UUID v4 é o comprimento menor e a possibilidade de ordenação temporal. Sobre o UUID v7, que também é ordenável, o ULID ganha na ausência de hífenes e na insensibilidade a maiúsculas, o que facilita a transcrição manual e a utilização em URLs sem necessidade de encoding percentual. Além disso, o alfabeto base32 é mais denso que o hexadecimal (32 símbolos por caractere contra 16), o que explica os 26 caracteres para 128 bits, contra os 32 caracteres hexadecimais necessários para representar a mesma quantidade de informação.

Ordenação temporal e comportamento de colisões

Os primeiros 10 caracteres de um ULID codificam o timestamp em milissegundos. A ordenação lexicográfica destes caracteres corresponde à ordenação cronológica, porque o sistema base32 produz sequências que preservam a ordem numérica quando comparadas caractere a caractere. Por exemplo, um ULID gerado às 14:30:00.123 será sempre menor (lexicograficamente) do que outro gerado às 14:30:00.124, independentemente da parte aleatória. Isto é uma propriedade crucial para bases de dados que usam índices do tipo B‑tree: as inserções de novos registos tendem a ocorrer no final do índice, reduzindo a fragmentação e melhorando o desempenho das escritas em comparação com UUID v4 completamente aleatórios.

Dentro do mesmo milissegundo, a ordenação entre múltiplos ULIDs é aleatória: não há garantia de que o primeiro gerado apareça antes do segundo na ordenação lexicográfica. Isto deve‑se ao facto de a parte aleatória ser independente da ordem de geração. Para aplicações que exigem ordenação estrita intra‑milissegundo, é necessário usar um contador adicional (como no ULID v2, embora esse não seja o formato tratado aqui).

A probabilidade de colisão entre dois ULIDs gerados no mesmo milissegundo depende apenas da componente aleatória de 80 bits. Pela aproximação da distribuição de aniversário, para que a probabilidade de colisão atinja 50% num único milissegundo, seria necessário gerar cerca de 2⁴⁰ ≈ 1 bilião de ULIDs — valor impraticável para a maioria das aplicações. Em condições normais de uso, o risco é desprezível.

Segurança e privacidade da geração local

Todos os ULIDs são gerados exclusivamente no navegador do utilizador, utilizando a API crypto.getRandomValues() — a fonte de aleatoriedade criptograficamente forte disponível no JavaScript moderno. Nenhuma informação é transmitida para qualquer servidor, nem os identificadores gerados são armazenados ou registados. Isto contrasta com serviços online que geram identificadores no lado do servidor, onde existe sempre o risco de exposição acidental ou monitorização.

A geração local também elimina a latência da rede: o conjunto de até 100 ULIDs fica disponível em milissegundos, sem qualquer espera. Para além disso, a falta de hífenes e a insensibilidade a maiúsculas facilitam a cópia e a colagem directa para o código ou para a base de dados, sem necessidade de pós‑processamento.

Casos de uso e público‑alvo

O gerador de ULIDs destina‑se a:

• Desenvolvedores web e móveis que precisam de identificadores mais curtos que UUIDs, seguros para URLs e ordenáveis por data de criação sem um campo separado de timestamp.
• Administradores de bases de dados a desenhar chaves primárias que melhorem o desempenho de inserções em índices B‑tree, graças à monotonicidade aproximada dos ULIDs.
• Arquitetos de sistemas distribuídos que requerem identificadores únicos entre muitos nós, mas que sejam compactos e ordenáveis.
• Designers de APIs que desejam expor IDs públicos difíceis de adivinhar (devido à componente aleatória) mas amigáveis para humanos (sem ambiguidade de maiúsculas/minúsculas, sem hífenes).

A ausência de caracteres que precisem de percent‑encoding (segundo a RFC 3986, todos os caracteres do base32 de Crockford são não‑reservados) torna os ULIDs particularmente adequados para URLs, parâmetros de query e nomes de ficheiros sem necessidade de escapes.

Perguntas frequentes (FAQ)

O que é um ULID?
ULID (Universally Unique Lexicographically Sortable Identifier) é um formato de identificador de 128 bits, representado por 26 caracteres do alfabeto base32 de Crockford. É insensível a maiúsculas/minúsculas, não contém hífenes e é ordenável cronologicamente devido aos primeiros 10 caracteres codificarem o timestamp de criação.

Quantos caracteres tem um ULID?
Exatamente 26 caracteres. Isto é 10 a menos que um UUID (36 caracteres com hífenes). A redução deve‑se à codificação base32, que é mais densa que a hexadecimal.

Posso gerar mais de 100 ULIDs de uma vez?
Não. A ferramenta aceita apenas valores entre 1 e 100 inclusive. Se precisar de mais, terá de gerar em lotes sucessivos.

Os ULIDs são sensíveis a maiúsculas/minúsculas?
Não. O formato usa o alfabeto base32 de Crockford, onde as maiúsculas e minúsculas são equivalentes. Um ULID gerado como 01ARZ3NDEKTSV4RRFFQ69G5FAV pode ser escrito como 01arz3ndektsv4rrffq69g5fav sem alterar o seu valor.

Como é que os ULIDs são ordenados?
A ordenação é lexicográfica: os 10 primeiros caracteres (timestamp) determinam a ordem cronológica. ULIDs com timestamps posteriores surgem depois na ordenação. Dentro do mesmo milissegundo, a ordem entre eles é aleatória porque depende da componente aleatória.

Os ULIDs são seguros para URLs?
Sim. Todos os caracteres do alfabeto base32 de Crockford são não‑reservados na RFC 3986, o que significa que podem ser usados directamente em URLs sem qualquer codificação percentual. Isto torna‑os ideais para identificadores em APIs REST, parâmetros de query e caminhos de ficheiros.