Codificador e decodificador Base64

Base64 existe porque grande parte da infraestrutura construída em torno de texto — e-mail, JSON, XML, URLs — não consegue transportar de forma confiável bytes binários arbitrários, que poderiam conter caracteres de controle, bytes nulos, ou sequências de bytes que terminam uma string prematuramente ou quebram um analisador diretamente. Base64 mapeia cada três bytes de dados binários arbitrários para quatro caracteres extraídos de um conjunto fixo de 64 que qualquer sistema baseado em texto lida com segurança — letras, dígitos e dois símbolos — então o resultado codificado pode ser incorporado em JSON, enviado como anexo de e-mail, ou incluído em um documento sem que nada adiante o interprete erroneamente como algo diferente de texto simples.

O acréscimo dessa segurança é fixo e inevitável: quatro caracteres de saída para cada três bytes de entrada, uma expansão de aproximadamente 33%, não importa quais sejam os dados subjacentes. Esse é o preço pago por uma passagem segura garantida através de canais somente de texto, não um defeito específico de nenhuma implementação particular.

A função `btoa` embutida do navegador, à qual muitas implementações rápidas de Base64 recorrem diretamente, lança um erro no momento em que encontra qualquer caractere acima do ponto de código U+00FF — o que inclui essencialmente todos os emojis, chinês, japonês, coreano, cirílico, grego e árabe, além de bastante caracteres latinos acentuados usados em francês, alemão, português e outros idiomas. Este não é um caso extremo obscuro que afeta entradas raras; afeta uma fração muito grande de texto do mundo real, e é a razão pela qual tantas ferramentas Base64 feitas à mão funcionam perfeitamente em testes com entrada em inglês simples e depois falham na primeira vez que um usuário cola algo com um emoji ou um nome não latino.

A correção é codificar o texto como bytes UTF-8 primeiro, depois codificar em Base64 esses bytes — que é o que fazem os codificadores construídos corretamente e o que faz esta ferramenta — em vez de tentar inserir pontos de código Unicode diretamente em uma codificação projetada para sequências de bytes abaixo de 256.

O conjunto de caracteres do Base64 padrão inclui `+` e `/`, ambos com significado em uma URL — `+` às vezes é interpretado como um espaço, e `/` é um separador de caminho — então uma string Base64 padrão colada diretamente em uma string de consulta ou nome de arquivo pode ser corrompida ou truncada silenciosamente ao passar por qualquer coisa que analise essa URL. Base64URL substitui esses dois caracteres por `-` e `_`, nenhum dos quais carrega significado especial em uma URL, e tipicamente também remove os caracteres de preenchimento `=` finais, que existem puramente para sinalizar comprimento e são desnecessários uma vez que o decodificador já sabe esperá-los.

JSON Web Tokens usam Base64URL exatamente por essa razão: um JWT é projetado para viajar dentro de um cabeçalho HTTP Authorization e às vezes uma URL, e os caracteres reservados do Base64 padrão tornariam isso pouco confiável.

Vale a pena dizer isso com clareza porque a suposição aparece com frequência: Base64 fornece zero confidencialidade. Não há nenhuma chave secreta envolvida em nenhum ponto do processo, então qualquer um que obtenha uma string Base64 pode decodificá-la de volta aos dados originais instantaneamente usando nada mais que uma chamada de biblioteca padrão ou uma ferramenta exatamente como esta. Codificar uma senha ou uma chave de API em Base64 antes de armazená-la ou transmiti-la não fornece nenhuma proteção — apenas oculta o valor de uma olhada casual, o que é uma propriedade muito distinta de segurança real.