Outils de développement · Encodeur et décodeur Base64
Remplissage Base64 expliqué : ce que signifient les signes = et quand ils sont requis
· Comment ça marche
base64 codage flux de travail du développeur
Le = à la fin d'une chaîne Base64 n'est pas une décoration : il enregistre le nombre d'octets du dernier groupe qui était court. Cet article explique l'arithmétique, pourquoi certaines chaînes n'en ont pas et pourquoi les décodeurs ne sont pas d'accord sur le remplissage manquant.
L'exception de « remplissage incorrect » d'un jeton qui semblait correct : un échec de décodage et un ou deux caractères manquants derrière.
Lorsqu'un décodeur Base64 signale un remplissage incorrect, la chaîne semble complète mais comporte une erreur structurelle. Les signes égal ne sont pas cosmétiques : chacun code le nombre d'octets du groupe final qui était court, permettant au décodeur de savoir exactement quand les données réelles se sont terminées. Comprendre ces signes = (et pourquoi les décodeurs stricts rejettent les chaînes sans eux) transforme une erreur mystérieuse en arithmétique prévisible. Un segment JWT peut avoir un =, aucun ou deux. Une réponse API peut se terminer proprement sans remplissage.
Il s'agit de choix intentionnels, et non de variantes de mise en œuvre. Le processus de décodage ne nécessite pas de remplissage mécanique. Le remplissage existe pour rendre la sortie sans ambiguïté : étant donné uniquement une chaîne Base64 sans métadonnées sur la longueur, le décodeur lit le remplissage et sait exactement où se terminent les données. Base64 code des groupes de trois octets en quatre caractères. Trois octets sont des bits 24, regroupés parfaitement en quatre indices 6-bit ; chacun choisit l'un des symboles 64 Base64. Lorsque l'entrée n'est pas un multiple de trois, l'encodeur fait face à des restes : un ou deux octets ne peuvent pas être divisés uniformément par trois.
Groupes de trois octets, blocs de quatre caractères — pourquoi la longueur d'entrée modulo 3 décide si zéro, un ou deux signes = apparaissent
L'encodeur complète ces groupes en déplaçant les bits vers les premiers indices, laissant les finales à zéro. Pour marquer cette intention, il ajoute des signes = : zéro pour les groupes complets, un pour les finales sur deux octets, deux pour les finales sur un octet. L'arithmétique est déterministe : connaître la longueur d'entrée en octets vous permet de calculer immédiatement le remplissage. Un octet produit deux caractères Base64 plus deux =. Deux octets produisent trois caractères plus un =. Trois octets en produisent quatre sans remplissage.
Toute entrée qui n'est pas un multiple de trois octets aura un remplissage ; tout ce qui est un multiple ne le sera pas. Ce n’est pas un choix, c’est de l’arithmétique. Une chaîne sans remplissage doit représenter trois octets. Une chaîne avec un égal doit en représenter deux. Le remplissage code la longueur d’entrée modulo trois. Examinez la transformation de trois entrées : simple a, paire ab, triple abc. ASCII a est l'octet 0x61 ; Base64 le code en 0x61 00 00, en le regroupant en groupes de six bits.
Ce que contiennent les bits de remplissage et pourquoi un décodeur strict les vérifie – les bits qui doivent être nuls et ce que signifie le codage canonique
Les indices 24, 4, 0, 0 correspondent à Y, E, A, A. Étant donné que deux groupes étaient un remplissage, l'encodeur ajoute deux signes =, produisant YQ==. Pour ab, les octets 0x61 0x62 deviennent 0x61 0x62 00. Les bits se regroupent en indices 24, 22, 8, 0, sortie YWI=. Pour abc, les octets se regroupent en indices 24, 22, 9, 35, sortie YWJj sans remplissage. Le remplissage n'est pas arbitraire : il ne correspond pas à la disposition des bits. Lorsque vous décodez une chaîne Base64, le décodeur lit chaque caractère, recherche son index de six bits et regroupe les bits en octets.
Pour YQ==, les caractères Y, E, A, A décompressent en bits. Le regroupement en octets de huit bits donne un octet, 0x61. Le décodeur supprime les bits de remplissage (zéros à droite) et rapporte un octet. Un décodeur strict vérifie que les bits de remplissage sont réellement nuls ; sinon, l'entrée n'était pas canonique, ce qui signifie que quelqu'un a codé en utilisant une disposition de bits différente et que le décodage est ambigu. Les systèmes omettant entièrement le rembourrage font des compromis délibérés. Les segments JWT utilisent Base64url sans remplissage, en s'appuyant sur le fait que les consommateurs connaissent la longueur de sortie attendue ou la déduisent.
Exemple concret : encodage manuel de "a", "ab" et "abc" - trois entrées, trois résultats de remplissage, affichés petit à petit
RFC 4648 autorise le remplissage absent mais demande aux décodeurs de l'accepter s'il est présent. Les bibliothèques de codes diffèrent : certaines restaureront le remplissage manquant et continueront ; d'autres échoueront. Lorsque vous rencontrez des jetons dont le décodage échoue, l'ajout du bon nombre de signes = corrige souvent le problème. Obligatoire = les signes sont toujours zéro, un ou deux, selon la longueur de la chaîne modulo quatre. Si la longueur d'une chaîne Base64 n'est pas un multiple de quatre, le remplissage est définitivement manquant ou corrompu.
Une longueur de 5 ne peut pas être valide en Base64 : chaque caractère complet code six bits, donc quatre caractères codent 24 bits (trois octets) et cinq codent 30 bits, ce qui n'est pas un multiple de huit et ne peut pas devenir des octets. Le décodeur doit soit rejeter cela, soit ajouter un remplissage. Si la longueur est 2 modulo 4, ajoutez deux =. Si 3 modulo 4, ajoutez un =. Si 0 modulo 4, n’en ajouter aucun. Une chaîne de longueur 3 n'a pas le = dont elle a besoin ; ajoutez-en un et il devient valide avant le décodage.
Pourquoi certains systèmes abandonnent complètement le remplissage - JWT segments et jetons sécurisés pour les URL qui omettent = et comment le restaurer à partir de la longueur
Concaténation de deux chaînes Base64 rembourrées cassées si le rembourrage est laissé en place. Deux encodages distincts joints directement produisent des caractères de remplissage parasites qui brisent l'alphabet de décodage. C'est pourquoi certains systèmes suppriment le remplissage avant la concaténation : un jeton composé de trois segments Base64url reliés par des points n'a pas de remplissage à l'intérieur des segments, ce qui rend la concaténation simple. Si vous créez une valeur Base64 à partir de pièces, vérifiez si chaque pièce est remplie et supprimez ou ajoutez un remplissage de manière cohérente avant toute opération.
L'encodeur et le décodeur Base64 applique la RFC 4648, qui nécessite un remplissage par défaut. Lorsque vous saisissez du texte et demandez une sortie base64, l'outil produit un résultat complété : la forme canonique. Si vous voyez Base64 sans remplissage et que vous souhaitez le décoder, vérifiez si votre décodeur accepte le remplissage manquant. L'outil accepte les entrées complétées et non complétées et récupère correctement les octets d'origine. Pour le débogage, compter la longueur modulo quatre vous indique si le remplissage a été supprimé, et la formule indique quel remplissage doit être présent.
Erreurs courantes : trimming = comme s'il s'agissait d'espaces, ou concaténation de deux chaînes remplies – comment chacune corrompt le décodage
Base32 et Base16 (hexadécimal) ont des règles de remplissage différentes définies dans les sections RFC 4648 6 et 7. Base32 utilise = mais le groupe final peut être composé de caractères 2, 4, 5, 7 ou 8 en fonction de la longueur d'entrée modulo cinq. L'hexadécimal ne nécessite aucun remplissage ; il mappe toujours un octet sur deux caractères sans reste. L'habillage MIME Base64 touche le remplissage : une chaîne enveloppée dans une colonne 76 a toujours un remplissage à la toute fin, quelques lignes plus tard.
Comprendre le remplissage pour Base64 consiste à comprendre la disposition des bits et la longueur d'entrée modulo trois ; une fois que vous voyez l'arithmétique, le remplissage devient une conséquence directe, pas une règle à mémoriser. Le rembourrage est dérivable, pas magique.
Ce que cela ne couvre pas : règles de remplissage en base32 et base16 et conventions de longueur de ligne MIME
Étant donné une chaîne Base64 de n'importe quelle longueur, vous pouvez restaurer la forme canonique complétée en divisant le nombre de caractères par quatre, en prenant le reste et en ajoutant le nombre correspondant de signes =. C'est pourquoi manquant = est réparable et pourquoi les décodeurs stricts peuvent être indulgents : le remplissage contient des informations (dans quelle branche des trois cas tombe votre entrée), mais ces informations peuvent être calculées à partir de la seule longueur.
L'encodeur et le décodeur Base64 affichent immédiatement la sortie complétée afin que vous puissiez comparer les octets décodés au texte original et vérifier que l'aller-retour a fonctionné. Base64 et les codages associés étendent le principe de regroupement des bits en différentes largeurs de caractères. La RFC 4648 spécifie les trois, et comprendre l’un rend les autres conceptuellement simples. L'idée clé est que l'encodage est une pure manipulation de bits : choisissez la taille de votre alphabet, regroupez vos bits en conséquence, recherchez chaque groupe dans un tableau.
À retenir : le remplissage est dérivable, donc un = manquant est réparable – comment l'encodeur et le décodeur Base64 vous montrent la forme canonique complétée de tout texte que vous encodez
Décodage inversé : rechercher chaque caractère, extraire des bits, les regrouper, écrire des octets. Ce mappage déterministe bidirectionnel est la raison pour laquelle Base64 fonctionne de manière fiable sur toutes les plateformes et toutes les langues. Les erreurs d’encodage et de décodage sont souvent dues à une mauvaise compréhension du remplissage ou à des différences alphabétiques. Si le décodage échoue avec des erreurs de remplissage, vérifiez si le décodeur attend du Base64 canonique (strictement rempli) ou accepte des variantes. S'il échoue avec des erreurs de caractères, vérifiez si l'entrée est base64url et si le décodeur attend le Base64 standard.
L'encodeur et décodeur Base64 accepte les deux alphabets et valide le remplissage de manière cohérente, de sorte que tout exemple calculé manuellement peut être vérifié instantanément. Tester l’encodage en le décodant est le moyen le plus sûr de détecter les erreurs avant qu’elles ne causent des problèmes de production.