Decodificar do formato Base64

Visão geral

Base64 é uma metamorfose reversível, e esta ferramenta é a metade de volta da viagem: ela pega o texto imprimível que um codificador produziu e o transforma de volta no dado original. Cole uma cadeia de caracteres, escolha as configurações que combinam com a origem dela, e o resultado decodificado estará pronto para ler ou copiar. Quando a carga é um binário, como uma imagem ou um arquivo compactado, o texto Base64 dela mora num arquivo simples: o formulário de arquivo desta página recebe esse arquivo e devolve o binário original como download. O codificador correspondente mora no site irmão, a um clique de distância.

Opções avançadas

• Conjunto de caracteres: O Base64 move bytes, não letras, então o resultado decodificado só se lê corretamente se você souber em qual conjunto de caracteres ele estava guardado antes da codificação. Escolha o que combina com a sua origem: UTF-8 para texto moderno, Windows-1252 ou uma variante ISO-8859 para documentos mais antigos, ou AUTO-DETECÇÃO para deixar a ferramenta decidir (ela mostra em que parou logo ao lado da lista, e assume UTF-8 quando não consegue distinguir). Se a saída parecer um alfabeto embaralhado, este é o primeiro ajuste a fazer. Arquivos ficam isentos: dados binários são decodificados como estão, sem nenhuma conversão aplicada.
• Decodificar cada linha separadamente: Por padrão, a entrada inteira é uma única carga contínua: quebras de linha e espaços são removidos antes da decodificação, então uma cadeia de caracteres quebrada em várias linhas, copiada direto de um e-mail, funciona mesmo, e os caracteres seguros para URL - e _ são aceitos no lugar de + e /. Marque esta caixa quando a entrada for uma lista de itens independentes: cada linha é decodificada sozinha, e os resultados voltam um por linha. O formulário de arquivo oferece a mesma opção.
• Modo ao vivo: Ative isso e a decodificação acontece no seu navegador enquanto você digita, reexecutando a cada tecla, sem enviar nada para os nossos servidores. Ele respeita a opção linha a linha e funciona apenas com UTF-8, então a lista de conjuntos de caracteres fica travada enquanto ele está ativo, e o botão de decodificar fica desativado até você desativá-lo.

Seguro e protegido

Tudo roda sobre uma conexão HTTPS criptografada, e nada do que você envia é guardado: os arquivos enviados são apagados no momento em que são processados, e o resultado disponível para download desaparece logo depois da sua primeira tentativa de download ou de 15 minutos de inatividade, o que acontecer primeiro. O conteúdo do que você envia nunca é armazenado; o único processamento além da conversão é uma varredura de segurança dos arquivos enviados, que existe para bloquear conteúdo malicioso ou inadequado. Com o modo ao vivo ativo, o seu texto nunca sai do navegador. Todos os detalhes estão na nossa política de privacidade, com link no rodapé abaixo.

Completamente gratuito

Tudo nesta página é gratuito - a lista completa de conjuntos de caracteres, o envio de arquivos e o modo ao vivo inclusos. Sem conta, sem software para instalar, sem pagamento: para uma tarefa tão pequena, é assim que deve ser.

Base64 explicado

Algum dado simplesmente não consegue viajar por um canal só de texto: uma foto, um arquivo compactado, um hash, um pedaço de binário que faria uma conexão de e-mail de 7 bits engasgar. O Base64 é o tradutor para momentos assim. Ele reescreve qualquer sequência de bytes como texto simples e imprimível, para que o dado possa ficar no corpo de um e-mail, num documento JSON, num arquivo XML ou numa URL e chegue exatamente como saiu. A tradução é totalmente reversível: cada byte volta, na mesma ordem, sem nada perdido pelo caminho.

O formato inteiro cabe numa única frase: três bytes entram, quatro caracteres saem. O preço é um resultado cerca de um terço maior que o original. A recompensa é uma cadeia de caracteres que parece texto, se comporta como texto e sobrevive a canais que destruiriam bytes crus. E vale fixar cedo o que o Base64 não é: não é criptografia, e não é compressão. É uma metamorfose reversível, e esse é o trabalho inteiro.

Por que 64, e por que esses caracteres

Um byte guarda 8 bits, mas os antigos canais de texto, o e-mail acima de tudo, só transportavam ASCII de 7 bits com segurança. O truque é escolher um alfabeto de caracteres imprimíveis que sobreviva a qualquer viagem dessas, e dimensioná-lo para que a matemática feche certinha. Com 64 caracteres, cada caractere codificado carrega exatamente 6 bits, e 24 é divisível tanto por 8 (o byte) quanto por 6 (o caractere): três bytes de entrada viram quatro caracteres de saída, sem resto. O nome é apenas a base daquela matemática de caracteres, como a base 10 dos nossos dígitos.

O alfabeto padrão são os 62 caracteres alfanuméricos, de A a Z, de a a z e de 0 a 9, com + e / como os dois últimos. A especificação acrescenta um 65.º caractere, =, que nem faz parte do alfabeto: ele só aparece no final, como preenchimento. A escolha foi deliberada. O conjunto inteiro é imprimível; é comum a todos os sistemas de texto; e a especificação MIME observa que ele é grafado de forma idêntica em todas as versões do ISO 646, incluindo a US-ASCII, e em todas as versões do EBCDIC. Essa última propriedade é o que mantém o dado intacto enquanto ele atravessa a antiga engrenagem da internet, não limpa para 8 bits.

A codificação, passo a passo

O codificador é uma linha de montagem de quatro etapas. Ele lê a entrada três bytes por vez e funde cada trio numa única cadeia de 24 bits. Essa cadeia é cortada em quatro pedaços de 6 bits. Cada pedaço é um número de 0 a 63, e cada número é procurado na tabela acima. Quatro números entram, quatro caracteres saem.

Veja isso acontecer com a palavra foo, que chega com os valores de byte 102, 111 e 111 (hexadecimal 66, 6F, 6F). Colocados um atrás do outro, os 24 bits são 01100110 01101111 01101111. Cortados em grupos de seis, isso dá 011001, 100110, 111101 e 101111, que são 25, 38, 61 e 47. A tabela diz que esses são Z, m, 9 e v, então foo codifica para Zm9v, e qualquer decodificador Base64 do mundo vai devolvê-la aos três bytes originais.

O resto da entrada é processado do mesmo jeito, trio após trio, até não sobrar nada. Só o grupo final, quando guarda menos de três bytes, precisa de uma manobra especial.

Preenchimento: o = no final

A entrada é sempre um número inteiro de bytes, mas três nem sempre a divide certinho. Quando sobram um ou dois bytes na cauda, o codificador ainda precisa fechar um grupo completo de quatro caracteres. Ele enche os bits faltantes com zeros, faz as buscas como de costume e substitui os caracteres que os bits de preenchimento teriam produzido por sinais =. São exatamente três finais possíveis:

Então fo, dois bytes, vira Zm8=, e o solitário f vira Zg==, enquanto foo não precisa de preenchimento nenhum. O decodificador sabe exatamente o que fazer com os preenchimentos: cada = significa mais oito bits de zero para descartar. Os sinais de preenchimento ficam sempre só no final, e há no máximo dois deles. A especificação MIME até usa isso como um recurso: como = não pode aparecer em outro lugar, uma carga com preenchimento anuncia o próprio fim, e o receptor pode ver que o dado não foi cortado em trânsito. E para o caso mais pequeno: a entrada vazia codifica para a saída vazia. Até o nada faz uma ida e volta perfeita.

A decodificação: a linha de montagem ao contrário

Decodificar é a mesma máquina rodando ao contrário, e é igualmente mecânica. Pegue quatro caracteres, procure os de verdade (um preenchimento substitui seis zeros), escreva os 24 bits e devolva os primeiros 16 bits se houver um preenchimento, ou os 24 todos se não houver nenhum. Quatro caracteres entram, três bytes saem; dois bytes saem com um preenchimento; um byte sai com dois. Os bits de zero que o codificador acrescentou são a única coisa descartada, e todo o resto dos bits é exatamente o que entrou. É isso que reversível realmente significa aqui: o formato em si é sem perdas, e as únicas coisas que podem machucar o seu dado são um canal que corrompe a cadeia de caracteres, ou um decodificador que desiste em silêncio.

É por isso que o padrão é rigoroso sobre uma coisa: caracteres que não estão no alfabeto. O RFC 4648 diz que um decodificador deve rejeitar uma carga que contenha qualquer caractere fora dos 64, a menos que a especificação ao redor permita isso explicitamente. A razão é prática, não pedante. Um decodificador que engole caracteres estranhos em silêncio pode ser enganado: os caracteres contrabandeados viram um canal lateral escondido, e esse truque já foi usado para esconder dados de filtros e para cutucar as falhas de decodificadores. A famosa exceção é o próprio MIME, que antecede o padrão e diz o oposto: ignore todos os caracteres fora do alfabeto, e é assim que as quebras de linha passam num anexo de e-mail. Quando você mesmo valida a entrada, a regra moderna é a certa: se a sua cadeia de caracteres traz um @, um espaço ou qualquer outra coisa que não está na tabela, não é Base64 limpo.

Quebras de linha e a regra dos 76 caracteres

Você vai encontrar Base64 quebrado em linhas com frequência, e o hábito vem do e-mail. A antiga engrenagem do SMTP tinha limites de tamanho de linha, então o MIME quebra a carga a cada 76 caracteres por linha, com uma quebra CRLF, e o formato PEM, mais antigo, o que carrega certificados e chaves, quebra a cada 64. A regra do RFC 4648 para código novo é o oposto: não adicione quebras de linha nenhuma, a menos que o formato que você está implementando diga para adicionar. Na prática, o decodificador não se importa. Uma quebra de linha é só um caractere fora do alfabeto, então uma carga quebrada pelo MIME, um bloco PEM e uma longa cadeia de caracteres sem quebras todas decodificam para os mesmos bytes. Se você cola Base64 de algum lugar, remova as quebras de linha primeiro e pronto.

A quebra em linhas tem um pequeno custo, e ele aparece na conta de tamanho. Sem quebras de linha, o Base64 é exatamente quatro terços do original, cerca de 33 por cento maior. Quebrado a cada 76 caracteres, com quebras CRLF, ele fica cerca de 37 por cento maior, que é por isso que um arquivo que deveria ter 100 KB chega muitas vezes como uns 137 KB de texto. A conta sempre fecha.

Base64URL: o gêmeo seguro para URLs

O alfabeto padrão tem dois caracteres que não combinam com URLs. Um + numa cadeia de consulta é lido tradicionalmente como um espaço, e / é um separador de caminho, então uma cadeia Base64 crua numa URL precisa de codificação por porcentagem para os dois, além dos preenchimentos =. A seção 5 do RFC 4648 define o conserto: o alfabeto seguro para URL e nome de arquivo, onde + vira - e / vira _. Os preenchimentos geralmente somem também, porque um preenchimento faltante pode ser calculado pelo comprimento. O RFC diz sem rodeios que isso não deve ser chamado de Base64 puro: é uma codificação diferente, geralmente escrita como base64url.

Na prática, os dois ficam a uma troca de distância, na direção perigosa. Mande uma cadeia base64url para um decodificador padrão e dá errado, porque - e _ não estão no alfabeto padrão: um decodificador tolerante os descarta e devolve uma cadeia de bytes mais curta e errada, ou, quando o resto é curto demais para ficar sozinho, um erro, enquanto um rigoroso rejeita a carga inteira. A dança certa é trocar - de volta para + e _ de volta para /, completar os preenchimentos faltantes e só então decodificar. É o dialeto que você encontra em JSON Web Tokens (JWT), nas cadeias de estado do OAuth e nos IDs de um certo site de vídeos bem grande.

Um guia rápido de campo

Antes de recorrer a uma ferramenta, você consegue ler boa parte da cadeia de caracteres você mesmo. Alguns testes dizem se uma carga é Base64 de alguma forma, e o que ela esconde:

• Olhe para os caracteres. O Base64 padrão usa apenas de A a Z, de a a z, de 0 a 9, + e /; o gêmeo seguro para URLs usa - e _ no lugar desses dois. Qualquer outro símbolo, ou um espaço solto, significa que não é Base64 limpo.
• Verifique os preenchimentos. Os sinais =, se existirem, ficam só no final, e há no máximo dois. Um preenchimento no meio da cadeia de caracteres é um sinal de alerta.
• Conte o comprimento. Com preenchimentos, o comprimento é sempre um múltiplo de 4. Sem preenchimentos, dividir o comprimento por 4 deixa resto 0, 2 ou 3. Um resto de 1 é impossível, porque um único caractere só carrega 6 bits e um byte precisa de 8.
• Estime o tamanho. Cada grupo de 4 caracteres guarda 3 bytes, menos um byte por sinal =. Então Zm9vYmFy, oito caracteres sem preenchimentos, são 6 bytes, e Zm9vYg==, oito caracteres com dois preenchimentos, são 4.

Um último truque de campo, e o mais útil. O codificador precisa zerar os bits de preenchimento, mas um decodificador tolerante não os confere. A carga Zg== decodifica para o único byte f, e a Zh== também: os bits baixos do último caractere são preenchimento nos dois casos, então ambos formam o mesmo byte. O padrão chama a versão com bits de zero de forma canônica, e ela permite que decodificadores rigorosos rejeitem a outra. Duas cadeias de caracteres, uma carga. Se dois sistemas discordam sobre um valor Base64, os bits de preenchimento são um bom lugar para começar a procurar.

O que o Base64 não é

• Não é criptografia. Não há chave nem segredo; qualquer um devolve uma cadeia Base64 em bytes num segundo. O RFC até menciona incidentes reais em que pessoas relataram trocas de protocolo que incluíam uma senha "codificada", convencidas de que a codificação a escondia. Se o dado é sensível, proteja-o com criptografia de verdade antes de codificá-lo, não depois.
• Não é compressão. Vai na direção oposta: o resultado é cerca de 33 por cento maior que a entrada, e ainda maior quando as quebras de linha entram. O Base64 compra segurança de texto para você, e cobra por isso em tamanho.
• Não é um conjunto de caracteres. O Base64 move bytes, não letras. Ele não sabe nem se importa se aqueles bytes são texto UTF-8, uma codificação antiga de um byte, ou um JPEG. A pergunta "qual conjunto de caracteres é este?" vive antes da codificação e depois da decodificação, nunca dentro dela.
• Não é uma codificação única. O nome cobre uma família: o alfabeto padrão, o gêmeo seguro para URLs, cargas quebradas a cada 76 ou 64 caracteres, variantes que pulam os preenchimentos e um punhado de exóticos (o IMAP, por exemplo, usa uma vírgula no lugar do / do alfabeto ao codificar nomes de caixas postais internacionais). Quando dois sistemas discordam sobre uma carga, a diferença de dialeto é geralmente a culpada.

A letra miúda

As fontes primárias são curtas e legíveis. O RFC 4648, As codificações de dados Base16, Base32 e Base64 (2006), é o padrão atual: os dois alfabetos, as regras de preenchimento e quebra de linha, as regras de rigor, e um conjunto de vetores de teste oficiais, como foo virando Zm9v, contra os quais as implementações se conferem. Atrás dele está o RFC 2045, a especificação MIME de 1996, de onde vêm a regra da linha de 76 caracteres e a tolerância de ignorar caracteres estranhos, e o RFC 1421, a especificação descontinuada de Privacy Enhanced Mail que começou a família com linhas de 64 caracteres. Uma tentativa de unificação anterior, o RFC 3548, foi substituída pelo RFC 4648.

Essa é a história inteira: 64 caracteres, três bytes entram e quatro caracteres saem, = para fechar a cauda, e uma ida e volta perfeita. Toda ferramenta, biblioteca e conversor online que você encontrar é apenas uma porta de entrada para isso. Quando você conseguir olhar para uma cadeia Base64 e ver os bytes parados atrás dela, nada no formato vai te surpreender de novo. E quando você estiver pronto para escrever o decodificador você mesmo, os artigos de linguagens de programação logo abaixo desta seção entregam os mesmos 64 caracteres como código que funciona: um guia completo por linguagem.