Esses três nomes descrevem esquemas binários para texto relacionados, mas atendem a restrições diferentes. Base64 e Base64URL usam grupos de seis bits. O padrão Base32 usa grupos de cinco bits e um alfabeto menor. A escolha certa é aquela que sua aplicação de transporte, armazenamento e recebimento pode preservar exatamente.
Compare alfabetos antes de comprimentos
O padrão Base64 usa letras maiúsculas e minúsculas, dígitos, mais e barra. Base64URL substitui traço e sublinhado nos dois últimos caracteres. Ambos diferenciam maiúsculas de minúsculas. O RFC padrão Base32 usa letras maiúsculas de A a Z e dígitos de 2 a 7. Um decodificador pode aceitar letras minúsculas por conveniência, mas um protocolo deve indicar se isso é permitido e definir sua saída canônica.
Um canal que não diferencia maiúsculas de minúsculas pode destruir um valor Base64 enquanto preserva um valor Base32 especificado corretamente. Um token URL tem restrições diferentes de um código lido em voz alta por telefone. Não escolha apenas pela aparência curta de uma amostra.
Entenda a compensação de tamanho
Ignorando o grupo parcial final, Base64 precisa de cerca de 1,33 caracteres por byte e Base32 precisa de 1,6. O preenchimento padrão Base32 emite grupos de oito caracteres para cinco bytes. Para um byte contendo a letra f, os vetores comuns são Zg== em Base64 e MY====== em Base32. Entradas pequenas exageram a sobrecarga de preenchimento, portanto compare comprimentos de carga úteis realistas.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Não misture variantes Base32
Crockford Base32 foi projetado em torno de identificadores legíveis por humanos e usa um alfabeto diferente e regras de ambiguidade da RFC Base32. Base32hex também é diferente. Um valor produzido por uma variante não pode ser transmitido cegamente a outro decodificador. Nomeie a variante, o alfabeto, a política de preenchimento e qualquer comportamento de soma de verificação em sua documentação.
A codificação também não fornece autenticação. Um valor digitado incorretamente ainda pode ser sintaticamente válido e decodificado em bytes diferentes. Se os usuários transcreverem um código, considere uma soma de verificação ou etapa de verificação definida pelo protocolo, em vez de presumir que o alfabeto detecta todos os erros.
Anote o contrato completo
Especifique a ordem dos bytes de entrada quando relevante, comportamento de entrada vazia, preservação de zero à esquerda, comprimento máximo, aceitação de espaços em branco e tratamento de caracteres inválidos. Inclui vetores de teste com bytes de alto valor e grupos parciais. Use o codificador e o decodificador escolhidos independentemente desses vetores, não apenas um contra o outro; caso contrário, os bugs correspondentes podem parecer passar por uma viagem de ida e volta. Os formulários padrão e vetores de referência estão em RFC 4648.