Ferramentas de desenvolvedor · Codificador e decodificador Base64
Base64 vs hex vs base32: comparando três maneiras de escrever bytes como texto
· Fundo
base64 codificação
Hex, base32 e Base64 resolvem o mesmo problema com diferentes compensações em tamanho, legibilidade e segurança. Esta postagem os compara em densidade, distinção entre maiúsculas e minúsculas, segurança URL e erro humano.
A chave API que foi digitada incorretamente por causa de l, 1, I e O - uma falha concreta de legibilidade que hex não teria
Três maneiras comuns de representar bytes como texto são hexadecimal, base32 e base64. Todos eles resolvem o mesmo problema (expressando bytes arbitrários em ASCII imprimível), mas com diferentes compensações em tamanho, legibilidade e resiliência a erros. Hex tem 2 caracteres por byte (F3 A2 B1 ...), então 16 bytes se torna 32 caracteres. Base32 tem 1.6 caracteres por byte (aproximadamente 5 caracteres por 3 bytes), então 16 bytes se torna 26 caracteres.
Base64 tem 1.33 caracteres por byte (exatamente 4 caracteres por 3 bytes), então 16 bytes se torna 24 caracteres ou menos. Se o tamanho do arquivo for importante, o base64 é o mais compacto. Se a transcrição humana for importante, hexadecimal e base32 são mais seguros. A diferença de legibilidade é crítica quando um valor é digitado, copiado ou falado. Hex usa 0-9 e a-f (não diferencia maiúsculas de minúsculas na maioria dos contextos). Um canal de transcrição muda a decisão porque uma representação otimizada para máquinas pode ser estranha para as pessoas. Base64 diferencia maiúsculas de minúsculas e usa dois símbolos de pontuação; hex usa um vocabulário visual menor. A implementação aqui testa strings exatas, não uma taxa de erro humano, portanto, nenhuma probabilidade inventada é anexada.
Densidade: 2×, 1.6× e 1.33× — quantos caracteres cada codificação precisa por byte e por quê
Base32 usa A-Z e 2-7, evitando 0, 1, O e I que são facilmente confundidos no papel. Base64 usa A-Z, a-z, 0-9, + e /, incluindo letras maiúsculas e minúsculas, tornando-o sensível a maiúsculas e minúsculas e misturando dígitos que parecem semelhantes (0 versus O, 1 versus I versus l minúsculo). Uma chave API em hexadecimal pode ser f3a2b1e4; os mesmos bytes em base64 podem ser 86KrvE== (com preenchimento) ou em base32 6VEV7FI= (com preenchimento).
Se um usuário precisar digitar o valor manualmente, hexadecimal ou base32 é mais seguro que base64. Caracteres reservados em URLs são importantes. Hex e base32 são seguros para URLs; ambos usam apenas caracteres alfanuméricos (hex também usa 0-9, base32 também usa 2-7). Base64 usa sinal de mais e barra que são reservados para URL (o sinal de mais representa um espaço nos dados codificados em formulário, a barra é um separador de caminho). A densidade Base64 segue diretamente de seis bits úteis por símbolo de saída e preenchimento para blocos de quatro caracteres. Hex carrega quatro bits por símbolo, perfazendo dois caracteres por byte. Base32 é discutido como contexto de comparação apenas porque este repositório não fornece seu alfabeto nem um codificador para verificar as saídas.
Densidade da largura de bits — Base64 exata e aritmética hexadecimal, com Base32 tratada como contexto de comparação
Uma string base64 em um parâmetro URL deve ser codificada por porcentagem (mais se torna %2B, a barra se torna %2F), adicionando 4 caracteres extras para cada ocorrência. Base64url (RFC 4648 seção 5) substitui o sinal de mais por traço e barra por sublinhado, tornando-o URL seguro sem codificação percentual. A maioria das APIs que usam base64 em URLs, na verdade, usam base64url, mas a distinção geralmente não é explícita na documentação.
Os segredos TOTP (os códigos usados pelos aplicativos autenticadores) são normalmente distribuídos como base32. Uma tela de registro TOTP mostra um segredo base32 porque é mais fácil digitar e transcrever do que os mesmos bytes em base64 ou hexadecimal. SHA resumos de hash são frequentemente exibidos em hexadecimal porque é o formato tradicional e porque hexadecimal não diferencia maiúsculas de minúsculas, tornando menos prováveis erros de digitação. A distinção entre maiúsculas e minúsculas é importante quando alguém lê um valor em voz alta ou o redigita, pois alterar a caixa de uma letra altera seu índice. ToolAcre preserva maiúsculas e minúsculas com exatidão e decodificará os diferentes bytes resultantes sem saber que um humano cometeu um erro de transcrição. A representação em si não possui soma de verificação.
Caracteres reservados e segurança URL — onde + e / morde, e como base32 e hex evitam o problema
JWTs usam base64url. As somas de verificação dos arquivos podem ser hexadecimais ou base64; ambos são comuns. A escolha é uma convenção histórica, não uma necessidade técnica. A resiliência ao erro é uma diferença sutil, mas importante. Base32 evita os dígitos 0, 1, 8 e 9 (que parecem letras), reduzindo erros de transcrição. Base64 inclui todos os dígitos, tornando 1 ambíguo (é uma letra I, l minúsculo ou o dígito 1?).
Hex é ainda mais sujeito a erros: 0 parece O, l parece 1. Uma soma de verificação que deve ser digitada ou lida em uma impressão é mais segura em base32. Uma chave API colada diretamente de um computador é segura em qualquer formato; a legibilidade importa apenas quando os olhos humanos estão envolvidos. Bytes iguais, mas codificação diferente: a sequência de 16 bytes [0xf3, 0xa2, 0xb1, ...] torna-se f3a2b1... O sinal de mais e barra do Base64 padrão precisa de tratamento com reconhecimento de canal; O modo de segurança URL os substitui por hífen e sublinhado. Hex evita esses separadores usando apenas dígitos e letras. As convenções Base32 variam, portanto, este artigo evita propriedades de segurança promissoras que o repositório não implementa ou testa.
Exemplo resolvido: o mesmo 16 bytes em todas as três codificações – comprimentos comparados e inspeção visual
em hexadecimal, 6VEV7FI=... em base32 e 86KrvE== em base64. Nenhuma dessas strings é intercambiável. Um aplicativo que recebe f3a2b1... espera hexadecimal e tentará analisá-lo como hexadecimal. O recebimento de 86KrvE== falhará se o aplicativo esperar hexadecimal. O formato de codificação faz parte do contrato dos dados: remetente e destinatário devem concordar sobre qual codificação será usada. O preenchimento é outra diferença.
Hex não usa preenchimento (4 bytes são sempre 8 caracteres hexadecimais, sem exceções). Base32 e base64 usam preenchimento igual para alinhar a saída a um múltiplo de caracteres (8 para base32, 4 para base64). O preenchimento é necessário matematicamente; garante que cada entrada de n bytes produza uma contagem de caracteres determinística. As regras de preenchimento variam: alguns aplicativos exigem preenchimento, outros permitem que ele seja omitido. A comparação trabalhada usa uma sequência de bytes fixa e calcula Base64 e hexadecimal mecanicamente. Seu comprimento Base32 pode ser discutido a partir de um agrupamento de cinco bits, mas um valor de texto Base32 exato é omitido porque nenhuma implementação revisada o gerou. A aritmética de comprimento e a verificação de saída são mantidas distintas.
Onde cada um é convencional - hashes em hexadecimal, segredos TOTP em base32, JWTs e dados: URIs em Base64
Ao colar um valor base32 ou base64 sem preenchimento, os decodificadores podem aceitá-lo ou rejeitá-lo dependendo da implementação. Chaves criptográficas e tokens mostram a diferença de codificação.
Uma chave HMAC é 32 bytes, que se torna 64 caracteres hexadecimais, 52 caracteres base32 (com preenchimento) ou 44 caracteres base64 (com preenchimento). Ao distribuir uma chave, a codificação deve ser documentada. Se a documentação disser que a chave contém 44 caracteres base64, mas você recebe 52 caracteres, algo está errado. A convenção pode orientar os leitores, mas não prova a adequação. Os resumos de hash são comumente exibidos como hexadecimal, enquanto os segmentos JWT usam Base64url. A escolha certa ainda depende das regras do canal, se as pessoas copiam o valor e se outro protocolo já corrigiu a representação.
O que isso não cobre – codificações base58, base85 e soma de verificação
A codificação base64 mais curta torna um pouco mais fácil inserir tokens em sistemas com limites de caracteres (como códigos QR ou URLs). A escolha da codificação de um valor é definida pelo ecossistema de onde ele veio. As APIs da Web geralmente usam base64url. A documentação criptográfica geralmente usa hexadecimal. Os aplicativos autenticadores usam base32. Ao construir um sistema, escolha uma codificação, documente-a claramente e siga-a.
Misturar codificações (digamos base64 ou base32) gera confusão. Ao depurar, a primeira etapa é identificar qual codificação o valor usa; a ferramenta codificador e decodificador Base64 pode ajudar, tentando decodificá-lo de várias maneiras e vendo qual delas produz uma saída sensata. Nenhuma codificação é universalmente melhor. Base64 é mais compacto para armazenamento bruto. Hex é mais familiar para criptógrafos e mais legível para pequenas sequências. As codificações Base58, Base85 e soma de verificação fazem compensações diferentes e estão ausentes do painel Base64 de ToolAcre. Os seus alfabetos, regras de ambiguidade e somas de verificação devem ser avaliados com fontes e implementações dedicadas, em vez de extrapolados a partir do comportamento testado desta ferramenta.
Conclusão: escolha a codificação para o canal e o leitor - como o codificador e decodificador Base64 cobre o caso Base64 no navegador, junto com a calculadora de hash SHA no mesmo produto
Base32 é mais resistente a erros de transcrição. A escolha depende do contexto: onde reside o valor, como é compartilhado e quais sistemas irão consumi-lo.
Compreender as vantagens e desvantagens ajuda você a escolher sabiamente ao projetar um API ou um sistema. A ferramenta codificador e decodificador Base64 demonstra a codificação base64; usá-lo junto com uma ferramenta hexadecimal ou base32 permite ver os mesmos bytes em todos os três formatos e entender suas diferenças de tamanho e legibilidade. Para o caso Base64, codifique uma amostra, observe as contagens exatas de UTF-8 bytes e caracteres de saída e teste o padrão versus pontuação segura URL. Para trabalho de resumo, use o painel SHA separado. Manter essas operações distintas evita que uma escolha de codificação seja confundida com hashing ou proteção de integridade.