Bits de remplissage Base64 : pourquoi Zg== et Zh== donnent f

Certains bits du dernier caractère ne portent aucune donnée

RFC 4648 §3.5 impose aux encodeurs conformes des bits de remplissage à zéro. Pour un octet d’entrée, seuls les deux bits supérieurs du deuxième caractère Base64 portent des données ; les quatre autres sont du remplissage. g a l’indice 32, 100000 ; h l’indice 33, 100001. L’octet de f est 01100110, et les bits de données coïncident. Zg== est canonique ; Zh== contient des bits de remplissage non nuls. Les caractères = finaux sont distincts des bits supprimés.

RFC 4648 §3.5, §4: Canonical Encoding / Base64

Vérifier le décodage et le réencodage

Le décodage tolérant de WHATWG Infra supprime quatre bits finaux d’un groupe restant de 12 bits, ou deux d’un groupe de 18. HTML atob utilise cet algorithme. Moyoutil restitue les octets avec atob puis les interprète comme texte UTF-8. Dans les exemples exécutés, Zg== et Zh== donnent f ; Zm8= et Zm9= donnent fo. Le réencodage produit Zg== et Zm8=. Le code ci-dessous réencode directement les octets, sans convertir des données binaires arbitraires en texte UTF-8.

for (const input of ['Zg==', 'Zh==', 'Zm8=', 'Zm9=']) {
  const bytes = atob(input);
  const canonical = btoa(bytes);
  console.log(input, bytes, canonical, input === canonical);
}
// Zg== f Zg== true
// Zh== f Zg== false
// Zm8= fo Zm8= true
// Zm9= fo Zm8= false

Des octets égaux et des chaînes originales égales sont deux conditions différentes. Définissez l’égalité requise pour la clé de cache ou la comparaison. Si le protocole destinataire exige une entrée canonique, validez ses règles. Nous ne conseillons pas de modifier une chaîne signée avant sa vérification. Cette comparaison concerne seulement Base64 standard avec remplissage, pas tous les protocoles.

WHATWG Infra: Forgiving base64 decode

WHATWG HTML: atob

Questions fréquemment posées