Base64 regroupe les octets en blocs de 24 bits et publie quatre symboles de six bits. Le dernier bloc peut ne contenir que 8 ou 16 bits. Le remplissage marque les octets absents et les bits faibles inutilisés du dernier symbole réel doivent être nuls. RFC 4648 exige cette règle pour une forme canonique. Sinon, plusieurs chaînes peuvent décoder vers les mêmes octets et fausser comparaisons ou entrées de signature.
Un ou deux octets façonnent la fin
Un octet restant fournit huit bits : deux symboles Base64, quatre bits faibles inutilisés dans le second et deux signes égal en forme remplie. Deux octets fournissent seize bits : trois symboles, deux bits inutilisés et un signe égal. Trois octets utilisent quatre symboles sans remplissage. Un profil sans remplissage retire seulement les signes égal, pas la règle des bits nuls.
AA== est canonique ; AB== ne l’est pas
Un logiciel permissif peut accepter les deux comme un octet nul en abandonnant les bits faibles non nuls de B. Le RFC 4648 canonique exige ces quatre bits à zéro, donc A est le seul second symbole valide. Base64Lens signale NON_CANONICAL_BITS pour AB== et AB sans remplissage. L’écriture ambiguë est refusée avant affichage.
Les erreurs strictes révèlent les écarts
Espaces, signes égal internes, plus de deux caractères de remplissage, longueur remplie hors quatuors et longueur sans remplissage congrue à un modulo quatre sont des échecs distincts. Base64Lens ne retire pas les retours ni ne répare le remplissage, car cela relève de MIME ou d’un autre format. Alignez les réglages sur la spécification productrice puis comparez avec la bibliothèque destinataire sur des cas vérifiés sans secret.