Tabela do alfabeto Base64

Os 64 caracteres

O Base64 lê a entrada de 3 em 3 bytes (24 bits) e divide cada grupo em quatro números de 6 bits. Cada número, de 0 a 63, é um índice nesta tabela. A ordem é fixada pela RFC 4648: maiúsculas de 0 a 25, minúsculas de 26 a 51, dígitos de 52 a 61 e, por fim, + e /. A última coluna é o código ASCII do caractere, que é o que de fato é armazenado ou transmitido.

Vale a pena decorar duas faixas. Todo caractere de A a P (0 a 15) começa com os bits 00, e todo caractere de w a / (48 a 63) começa com 11. Isso basta para decodificar um caractere de cabeça quando você confere um prefixo à mão. Um exemplo completo da divisão em bits está em como o Base64 funciona.

A ordem do alfabeto não é a ordem ASCII. No ASCII, + e / vêm primeiro, depois os dígitos, depois as maiúsculas e por último as minúsculas. Por isso, ordenar strings Base64 não ordena os bytes por trás delas: +A== (o byte F8) fica antes de AA== (o byte 00). Se você precisa de valores codificados que se ordenem como os bytes brutos, use o base32hex da RFC 4648 ou hex simples.

O alfabeto URL-safe

+ e / têm significado especial em URLs. + é decodificado como espaço em query strings e dados de formulário, e / separa os segmentos do caminho. O Base64URL, definido na seção 5 da RFC 4648, mantém os índices de 0 a 61 e troca os dois últimos:

Todo o resto, inclusive a disposição dos bits, é idêntico, então converter de um para o outro é uma troca de caracteres mais a inclusão ou remoção do preenchimento. JWTs, muitos tokens de API e identificadores seguros para nomes de arquivo usam Base64URL, geralmente sem =. O codificador Base64URL gera esse formato diretamente. A comparação completa está em Base64 vs Base64URL.

O caractere de preenchimento

= (ASCII 0x3D) não faz parte do alfabeto de 64 caracteres e nunca codifica dados. Ele só completa o último grupo de 4 caracteres quando o tamanho da entrada não é múltiplo de 3:

• Sobra 1 byte: 2 caracteres de dados mais ==.
• Sobram 2 bytes: 3 caracteres de dados mais =.
• Não sobra nenhum byte: sem preenchimento.

Assim, uma string com preenchimento sempre tem comprimento múltiplo de 4, e você nunca vê ===. Sem preenchimento, o comprimento dividido por 4 deixa resto 0, 2 ou 3, nunca 1. O guia de preenchimento explica quando o = pode ser omitido e como restaurá-lo.

Quais caracteres aparecem onde

Alguns padrões decorrem diretamente da disposição dos bits. Eles foram conferidos por força bruta em todos os valores de byte relevantes.

Antes de == só aparecem A, Q, g ou w. Quando sobra um byte, o segundo caractere carrega 2 bits de dados seguidos de 4 bits zero, então o índice dele é 0, 16, 32 ou 48. Antes de um único =, o terceiro caractere termina com 2 bits zero, então é um destes 16: A E I M Q U Y c g k o s w 0 4 8. Qualquer outro caractere nessa posição indica uma codificação não canônica, que decodificadores rígidos rejeitam.

Bytes aleatórios usam os 64 caracteres por igual. Cada grupo de 6 bits de dados aleatórios tem distribuição uniforme, então dados criptografados, chaves e arquivos compactados produzem uma distribuição de caracteres plana. Uma distribuição desigual é sinal de que os dados são texto ou têm estrutura.

Texto ASCII nunca começa um grupo com g a z minúsculos, dígitos, + ou /. O primeiro caractere de cada grupo de 4 guarda os 6 bits mais altos de um byte. No ASCII de 7 bits o bit mais alto é 0, então esse caractere fica sempre entre A e f (índice 0 a 31). Em SGVsbG8gd29ybGQh (Hello world!), os grupos começam com S, b, d e b.

No Base64 de texto ASCII, + e / são raros. Para bytes abaixo de 0x80, + só pode aparecer como quarto caractere de um grupo, quando o terceiro byte é > ou ~. / só aparece ali quando esse byte é ? ou o caractere de controle DEL. É por isso que Hi?> vira SGk/Pg== e <b> vira PGI+.

Sequências de A são bytes zero, sequências de / são 0xFF. AAAA são três bytes 00, //// são três bytes FF. Trechos longos de A são típicos de formatos binários esparsos, de texto UTF-16 (Hello é SABlAGwAbABvAA==) e dos campos de tamanho no início das chaves SSH. Mais padrões reconhecíveis estão em prefixos Base64 comuns.

Outros alfabetos Base64

Vários sistemas mantiveram a ideia de 64 caracteres para 6 bits, mas escolheram caracteres diferentes:

• IMAP troca / por , porque / é um separador de hierarquia comum em nomes de caixas de correio. Uma pasta chamada Entwürfe é armazenada como Entw&APw-rfe.
• bcrypt passa . e / para o início e mantém as letras antes dos dígitos. Os salts e hashes dele são Base64 nesse alfabeto, sem preenchimento, e é por isso que um decodificador padrão devolve os bytes errados.
• crypt(3) usa ./0-9A-Za-z, que é a ordem ASCII. Ele também empacota os bits a partir do lado menos significativo, então mesmo com o alfabeto traduzido um decodificador padrão não reproduz os bytes do hash.
• uuencode e xxencode são anteriores ao MIME. As ferramentas uuencode e xxencode leem e escrevem os dois formatos.

Para codificações com alfabetos de outros tamanhos, como Base32, Base58 e Base85, veja Base64 vs hex, Base32, Base58 e Base85. As definições dos termos usados aqui estão no glossário.

Perguntas frequentes