A verdade sobre o que vem depois do sistema hexadecimal
O hexadecimal usa base 16, com os dígitos 0-9 e A-F. Quando alguém pergunta depois do hexa vem o quê, a resposta curta é: depende de quantos dígitos você precisa representar. A base 36 (alfanumérica) usa 0-9 e A-Z, totalizando 36 símbolos. Existe uma tabela padrão chamada algarismos base-36 que funciona assim. O problema prático aparece quando você precisa ir além. Base 62 adiciona maiúsculas e minúsculas: 0-9, A-Z, a-z. Base 85 aparece em codificações como ASCII85 e Base85 do PDF. Base 91 e base 94 usam conjuntos de caracteres imprimíveis completos. Não existe um padrão unificado para bases acima de 64 — cada sistema define o seu próprio alfabeto.
👉 Clique no botão abaixo para saber mais sobre o assunto!
depois do hexa vem o quê na prática
Eu precisava converter identificadores grandes em strings curtas para um sistema de URLs encurtadas. O hexadecimal gerava strings com 8-10 caracteres para IDs de até 32 bits. Migrei para base 36 e reduzi para 5-6 caracteres. Depois migrei para base 62 e consegui 4-5 caracteres. A economia foi real, mas trouxe um problema que ninguém avisa: a collation do banco de dados. Quando você usa letras maiúsculas e minúsculas misturadas, a ordenação natural do MySQL e do PostgreSQL separa maiúsculas de minúsculas por padrão. Isso quebra índices lexicais se você fizer queries do tipo WHERE id > 'abc'. A solução que eu usei foi converter tudo para minúsculas antes de armazenar e usar COLLATE utf8mb4_general_ci de forma explícita nas queries. Também desisti de ordernar por ID alfanumérico e passei a usar um campo numérico separado para isso.
Outro detalhe que pega todo mundo: a conversão de e para base não é trivial quando o número é grande. Funções prontas de biblioteca geralmente usam divisão sucessiva, que é O(n²) para strings longas. Eu implementei uma versão com divisão em blocos usando BigInt e reduzi o tempo de conversão de IDs de 64 bits de cerca de 0,3 milissegundos para 0,02 milissegundos por operação. Não parece muito, mas em um lote de 50 mil conversões por minuto faz diferença. Se você só precisa de IDs curtos e legíveis, base 36 é suficiente e mais simples. Se precisa de máxima compressão, base 62 é o equilíbrio entre praticidade e tamanho. Acima disso, comece a usar Base85 ou Base91, mas prepare-se para lidar com caracteres especiais que podem quebrar URLs, formulários ou sistemas de log se não filtrarem entrada corretamente. E se estiver trabalhando com números extremamente grandes, considere usar encoding binário com compactação em vez de mudar de base — costuma ser mais eficiente em espaço e velocidade do que qualquer base maior que 256.
