O que é o Base64?
O Base64 reescreve bytes usando sessenta e quatro caracteres legíveis para que os dados sobrevivam a um canal construído para texto: o corpo de um email, uma string JSON, um atributo XML, um URL. Cada três bytes tornam-se quatro caracteres, e daí vem o nome — o alfabeto tem sessenta e quatro símbolos e cada um transporta exatamente seis bits.
É uma codificação de transporte, não uma medida de segurança nem um passo de compressão. A saída é cerca de um terço maior do que a entrada, e quem tiver a cadeia consegue revertê-la diretamente. Se quiser saber se os dados foram alterados, isso é um hash (Gerador de hash); se quiser que fiquem secretos, isso é encriptação. O Base64 não faz nenhuma das duas coisas.
O único número a reter: três bytes de entrada tornam-se quatro caracteres de saída. Tudo o resto nesta página decorre daí. Quatro caracteres transportam vinte e quatro bits, e vinte e quatro bits são exatamente três bytes, por isso nenhum dado se perde ou é inventado — exceto no fim, onde a entrada pode não preencher o último grupo de três.
Os cinco alfabetos que esta página pode usar
As duas primeiras linhas são normas e as últimas três são convenções que se desenvolveram em torno do Unix. As cinco usam os mesmos seis bits por caracter e diferem apenas nos sessenta e quatro caracteres que fazem o transporte, por isso os mesmos bytes tornam-se cinco cadeias diferentes. Nada dentro de uma cadeia diz qual alfabeto a produziu, e é por isso que o seletor de alfabeto assume o padrão e que a caixa segura para URL é um atalho para a segunda linha.
Como a página escolhe um candidato: o seletor é o predefinido para as duas direções. Ao descodificar, o painel da direita também lê a própria cadeia — - e _ só podem vir do alfabeto seguro para URL, + ou / só podem vir do padrão, e um / ou um . perto do início aponta para os dois alfabetos Unix. Todos os alfabetos capazes de ler a entrada atual são listados aí, com a razão de cada um ser, ou não ser, um candidato.
Quebra de linha: 76 e 64 caracteres
O MIME pediu um Base64 que caiba num email sem que nenhuma linha cresça de forma pouco razoável, e fixou-se em 76 caracteres por linha separadas por CRLF. Os ficheiros PEM, que envolvem certificados e chaves, usam 64. As quebras de linha não fazem parte dos dados: um descodificador remove-as e volta a juntar as linhas antes de fazer seja o que for, por isso uma cadeia com quebras e outra sem descodificam exatamente nos mesmos bytes. Cada linha, exceto a última, contém um número inteiro de grupos de quatro caracteres, e é isso que torna seguro voltar a juntá-las.
Esta página deixa a saída numa só linha, a menos que escolha uma largura, e o descodificador aceita entrada com ou sem quebras de linha. As quebras que esta página escreve são simples line feeds, que é o que uma caixa de texto consegue conter; os corpos de email MIME tradicionalmente usam um carriage return antes de cada line feed, e todos os descodificadores em uso aceitam os dois.
Preenchimento, e porque pode ser removido
Quando a entrada não é um múltiplo de três bytes, o último grupo de quatro caracteres fica incompleto, e um ou dois caracteres = completam-no. Não transportam dado nenhum: apenas indicam quantos dos quatro caracteres são reais. Um descodificador consegue calcular isso a partir do comprimento, e é por isso que o Base64 seguro para URL deixa tradicionalmente o preenchimento de fora — um = é incómodo num URL ou num nome de ficheiro, e alguns sistemas o codificam em percentagem.
A caixa de seleção na linha de opções mantém o preenchimento quando o alfabeto seguro para URL está selecionado. Nada mais muda; os caracteres que transportam dados são idênticos nos dois casos.
Mal-entendidos comuns
- « O Base64 esconde os dados. » Não esconde. É uma substituição sem chave, e o ponto todo é que qualquer leitor a consegue desfazer. Envolver uma palavra-passe ou um token em Base64 não muda nada sobre quem a consegue ler.
- « O Base64 comprime. » É o contrário: cada três bytes de entrada tornam-se quatro caracteres de saída, por isso o texto fica um terço maior do que os dados que transporta.
- « As quebras de linha fazem parte do valor. » São apresentação. Acrescentá-las ou removê-las nunca muda os bytes que saem.
- « Segura para URL é uma codificação diferente. » É a mesma codificação com dois caracteres trocados:
+ passa a - e / passa a _, por isso a cadeia pode ficar num caminho de URL ou num valor de query sem escape. - « Uma cadeia que se descodifica tem de ser Base64 válido. » Qualquer cadeia de caracteres do alfabeto é Base64 válido, porque toda a combinação de valores de seis bits é uma sequência válida de bytes. Uma cadeia só se revela errada no passo seguinte, quando esses bytes são verificados contra o formato que deveriam ter.
- « O preenchimento diz qual alfabeto foi usado. » Não diz, e na maioria dos casos os caracteres também não: o alfabeto padrão e o seguro para URL concordam em sessenta e dois dos seus sessenta e quatro símbolos, por isso uma cadeia curta costuma ler-se do mesmo modo nos dois.
Dúvidas frequentes
Porque é que uma cadeia Base64 às vezes termina com um = e outras vezes com dois? Um significa que o último grupo transporta três caracteres reais, ou seja, dois bytes de entrada; dois significa que transporta dois, ou seja, um byte de entrada. Nenhum = significa que o comprimento da entrada era múltiplo de três.
O Base64 consegue representar ficheiros binários arbitrários? Sim, e essa é a sua utilização principal. Esta página trata a entrada como texto UTF-8; a ferramenta dedicada Ficheiro para Base64 lê bytes brutos quando quer codificar algo que não é texto.
Que alfabeto devo usar numa API? O que o destinatário documentar. Se disser seguro para URL, use esse; se não disser nada e o valor viajar dentro de um URL, o seguro para URL sem preenchimento é a escolha segura.
A saída distingue maiúsculas? Totalmente. a e A são valores diferentes, e é por isso que o Base64 aguenta muito pior um carácter escrito mal do que o Base32 ou o Crockford Base32.
