Outils de développement · Encodeur et décodeur Base64
Pourquoi le Base64 collé ne parvient pas à décoder : retours à la ligne, nouvelles lignes et guillemets intelligents
· Pourquoi c'est important
base64 codage
Base64 se brise rarement pendant le transport ; ça casse dans le presse-papiers. Cet article répertorie les erreurs de copier-coller qui produisent des erreurs de caractères et de longueur invalides et comment les repérer rapidement.
La clé qui fonctionnait dans le terminal et échouait dans le navigateur : un caractère invisible et une recherche de deux heures
Un ingénieur a copié une clé API depuis un terminal pour la tester dans un script. La clé a bien fonctionné dans le terminal mais a échoué avec un caractère invalide lorsqu'elle a été collée dans l'outil de navigation. Deux heures plus tard, après avoir parcouru le code, la configuration et la documentation, ils ont découvert un caractère invisible. Une nouvelle ligne à la fin de la clé, ajoutée par écho ou copiée à partir d'une ligne d'invite de terminal, est devenue un caractère supplémentaire qui a cassé le décodeur Base64. La clé était correcte ; le presse-papiers ne l'était pas. Les données Base64 sont fiables lorsqu’elles sont transmises électroniquement, additionnées de contrôle et vérifiées. Il se casse presque exclusivement lors du copier-coller manuel.
Le retour à la ligne dans les terminaux, les nouvelles lignes à partir de la sortie de commande, la substitution de guillemets intelligents dans les éditeurs de texte enrichi et les caractères Unicode cachés lors du copier-coller entre différentes applications introduisent tous des erreurs qui ressemblent à Base64 est cassé lorsque le problème réel réside dans la façon dont il a été copié. Cet article répertorie les défauts les plus courants et montre comment les repérer et les corriger rapidement. L'alphabet Base64 se compose de lettres majuscules et minuscules, de chiffres, de signes plus, de barres obliques et du caractère de remplissage (signe égal). La RFC 4648 est spécifique : une chaîne Base64 standard contient uniquement ces caractères plus des espaces facultatifs si les lignes sont renvoyées à la ligne.
Retour à la ligne à partir des terminaux, des clients de messagerie et du formatage PEM : pourquoi un saut de colonne 76 est correct pour certains décodeurs et fatal pour d'autres
De nombreux outils tolèrent les écarts : ils acceptent les variantes sécurisées pour les URL utilisant des tirets et des traits de soulignement au lieu de plus et de barre oblique, ou ils ignorent les nouvelles lignes. Un décodeur strict qui suit la RFC rejette tout ce qui se trouve en dehors du jeu de caractères attendu et échoue avec une erreur de caractère non valide. Le message d'erreur nomme généralement le caractère incriminé ou indique que la chaîne ne peut pas être décodée du tout. Lors du collage en Base64 depuis un e-mail, un terminal, un historique de discussion ou un document formaté, des caractères invisibles ou des substitutions de caractères s'y glissent souvent et provoquent l'échec du décodage. Les données elles-mêmes sont correctes ; le transfert du presse-papiers l'a corrompu.
Le retour à la ligne est la source la plus courante d'échecs Base64 collés, et également la plus facile à corriger. Les outils de terminal encapsulent la sortie à 76 caractères par ligne ou parfois 80, en insérant une nouvelle ligne et en continuant sur la ligne suivante. De nombreux encodeurs, y compris certaines bibliothèques d'encodage Base64, encapsulent leur sortie selon la même limite de caractères 76 pour assurer la compatibilité avec le courrier électronique MIME. Lorsque vous copiez une chaîne Base64 enveloppée à partir d'un terminal, les nouvelles lignes apparaissent.
Nouvelles lignes de fin des outils d'écho et du presse-papiers : l'octet supplémentaire qui devient un caractère supplémentaire
Certains décodeurs acceptent et ignorent automatiquement les nouvelles lignes. D'autres les rejettent comme des caractères invalides. Le correctif consiste à supprimer toutes les nouvelles lignes et les espaces. Si une chaîne Base64 est enroulée sur plusieurs lignes dans le terminal, sélectionnez toutes les lignes, copiez-les dans un éditeur et supprimez toutes les nouvelles lignes.
Copiez la chaîne d'une seule ligne résultante et collez-la dans le décodeur. C'est la première chose à essayer lorsqu'une pâte échoue. Les nouvelles lignes de fin des utilitaires d'écho et de presse-papiers sont un autre coupable courant. La commande echo $API_KEY imprime la clé suivie d'une nouvelle ligne, qui est le comportement standard de la commande. Si vous copiez cette sortie directement, la nouvelle ligne est incluse dans la copie. Certains terminaux ajoutent une nouvelle ligne supplémentaire lorsque vous copiez, et certains gestionnaires de presse-papiers conservent ou dupliquent les nouvelles lignes. Le symptôme est le même que le retour à la ligne : un caractère supplémentaire à la fin de la chaîne qui n'appartient pas à Base64.
Guillemets intelligents, espaces insécables et caractères de largeur nulle : comment les éditeurs de texte enrichi réécrivent le texte brut
La solution est tout aussi simple : coupez les extrémités de la chaîne collée dans votre éditeur avant de tenter de décoder. Supprimez les espaces de début et de fin ainsi que tous les caractères qui ressemblent à des nouvelles lignes. Si la chaîne est suffisamment courte, vous pouvez la saisir à nouveau manuellement, mais pour les touches longues, un découpage manuel minutieux est plus rapide. Les guillemets intelligents, les espaces insécables et autres substitutions Unicode sont des pièges subtils. Les éditeurs de texte enrichi comme Word convertissent automatiquement les guillemets droits en guillemets bouclés, convertissent trois traits d'union en tiret cadratin et convertissent certaines séquences d'espaces en espaces insécables. Si quelqu'un colle une chaîne Base64 dans un document et que vous la copiez ensuite du document formaté dans un outil, ces substitutions surviennent.
Un guillemet double droit ("") devient une paire bouclée gauche et droite, dont aucun n'est valide en Base64. Un espace insécable (U+00A0) semble identique à un espace normal mais a un code de caractère différent et n'est pas reconnu comme un espace par tous les analyseurs. La solution consiste à coller d'abord dans un éditeur de texte brut, ce qui supprime tout formatage. Si vous collez à partir d'un document Word ou d'une discussion formatée, collez d'abord dans un éditeur de texte brut ou une zone de texte HTML. et vérifiez les caractères impairs. Copiez ensuite à partir de la version en texte brut à utiliser dans votre outil.
Troncature et perte de remplissage – la vérification de longueur modulo-4 qui vous indique que des caractères sont manquants
La troncature se produit lorsqu'une chaîne est coupée lors d'un copier-coller. Une chaîne Base64 très longue peut dépasser les limites du presse-papiers sur certains systèmes ou ne pas pouvoir être copiée en raison de bogues d'application. Le résultat est une chaîne plus courte et incomplète. Une chaîne Base64 doit avoir une longueur qui est un multiple de quatre après l'application du remplissage. Si une longueur n’est pas un multiple de quatre, elle est tronquée ou corrompue. Le message d'erreur indique généralement que la longueur de la chaîne n'est pas valide ou qu'un caractère est manquant. Le correctif nécessite de savoir ce qui a été copié à l'origine.
Si vous pouvez vérifier à nouveau la source, copiez-la à nouveau soigneusement. Dans le cas contraire, la troncature est irrécupérable. La perte de remplissage est un problème connexe : le remplissage Base64 avec des signes égal est parfois supprimé pour économiser quelques octets. Certaines applications omettent le remplissage et d'autres l'exigent. Si une chaîne a été initialement remplie et que le remplissage a été perdu, ajoutez-la à nouveau. Une chaîne Base64 doit avoir 0, 1 ou 2 à la fin des signes égal de telle sorte que la longueur totale soit un multiple de quatre. S'il n'en a pas et que la longueur n'est pas un multiple de quatre, le remplissage peut avoir été perdu.
Exemple concret : réparer une chaîne enveloppée et tronquée – la nettoyer étape par étape jusqu'à ce qu'elle décode
Un exemple concret montre ces réparations étape par étape. Supposons qu'une clé API copiée apparaisse comme ceci dans votre éditeur : VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0Cg==. Commencez par identifier les problèmes. Le Cg== final est impair ; Cg est en base64 pour un caractère de nouvelle ligne (hex 0A), et le == supplémentaire suggère que quelque chose a été ajouté. Supprimez le Cg== de fin et essayez simplement VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0. Ce n’est toujours pas vrai ; la longueur est de 37 caractères, et non d'un multiple de quatre. Coupez à nouveau : VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (35 caractères, toujours faux). Vérifiez la source originale. La chaîne correcte est VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0 (32 caractères) avec un remplissage approprié : VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0. Ajoutez-le : VGhpcyBpcyBub3QgcmVhbGx5IGEgc2VjcmV0=.
Test dans le décodeur. Ce décode en Ce n'est pas vraiment un secret. À chaque étape, utilisez l'encodeur et le décodeur Base64 pour tester la chaîne actuelle, résoudre le problème identifié et tester à nouveau jusqu'à ce qu'elle soit décodée. La corruption à l'intérieur des octets Base64 eux-mêmes n'est pas réparable par le décodeur. Si les octets sont réellement corrompus lors du transit, de la transmission ou du stockage, Base64 lui-même ne peut pas le détecter. La RFC spécifie les caractères valides ; tout caractère en dehors de cet ensemble est le travail de décodeur à capturer. Toute corruption d'octet, comme un 0 devenant un 1 au milieu d'un caractère Base64, produit un code de caractère entièrement différent et est indétectable par Base64 seul.
Ce que cela ne couvre pas : la corruption à l'intérieur des octets codés, que Base64 lui-même ne peut pas détecter
Des sommes de contrôle ou des signatures numériques sont utilisées pour détecter ce type de corruption, et elles doivent être calculées sur les données binaires d'origine avant l'encodage Base64. Si vous décodez une chaîne Base64 et que le résultat est erroné ou diffère de ce à quoi vous vous attendiez, la corruption s'est produite avant l'encodage ou pendant la transmission, et non pendant l'étape de copier-coller. C'est rare dans la pratique. La plupart des échecs sont des problèmes de copier-coller comme ceux ci-dessus. Une approche systématique du débogage des échecs de copier-coller Base64 consiste à tester chaque problème potentiel dans l'ordre. Tout d’abord, supprimez tous les espaces et nouvelles lignes. Supprimez ensuite les espaces de début et de fin ainsi que tous les caractères parasites.
Vérifiez ensuite la longueur modulo quatre et ajoutez du rembourrage si nécessaire. Collez chaque version dans l'encodeur et le décodeur Base64 et voyez si elle décode. Si la vérification de la longueur échoue, demandez si la chaîne a été tronquée et récupérez-la à partir de la source d'origine. Si la vérification alphabétique échoue et que vous voyez des caractères inhabituels, recherchez les guillemets intelligents ou les substitutions Unicode et remplacez-les par des équivalents ASCII. Utilisez un outil en ligne qui vous montre les caractères invalides par leur nom afin que vous puissiez les identifier et les supprimer. L'encodeur et le décodeur Base64 font cela pour chaque caractère invalide, indiquant exactement quel caractère ne figure pas dans l'alphabet.
À retenir : vérifiez la longueur et l'alphabet avant de blâmer les données - comment l'encodeur et le décodeur Base64 vous offrent un endroit local rapide pour tester chaque réparation
Utilisez ces commentaires pour corriger chaque caractère et continuez jusqu'à ce que la chaîne soit décodée. La prévention est plus facile que le débogage. Lorsque vous savez que vous aurez à nouveau besoin d'une chaîne Base64, copiez-la de manière à préserver le formatage. Ne le collez pas dans un document texte enrichi. Stockez-le dans un fichier texte brut ou dans une zone de texte désignée qui ne fait aucune substitution. Si quelqu'un vous envoie une chaîne Base64 dans un message formaté, demandez-lui de la renvoyer au format code ou en texte brut. Si vous devez copier à partir d'une source formatée, collez-la d'abord dans un éditeur de texte brut et vérifiez la chaîne avant de l'utiliser.
Testez la chaîne dans l'encodeur et le décodeur Base64 dès que vous l'avez, avant de vous y fier. En cas d'échec, vous pouvez demander une nouvelle copie pendant que la source est encore accessible. Si vous attendez que la chaîne soit ancienne ou que la source ait disparu, la correction de la troncature ou de la corruption devient impossible. L'encodeur et le décodeur Base64 vous offrent un endroit local rapide pour tester n'importe quelle chaîne avant de vous engager à l'utiliser. Testez tôt et testez souvent afin que les échecs de copier-coller soient détectés immédiatement.