Encodeur et décodeur Base32

Base32 transforme un texte UTF-8 quelconque en une chaîne compacte composée uniquement des lettres A à Z et des chiffres deux à sept, avec un remplissage facultatif en signes égal pour que chaque bloc s'aligne sur une limite de huit caractères. Contrairement à Base64, cet alphabet évite le plus, la barre oblique et les autres signes de ponctuation qui cassent les URL, les arguments de shell ou les systèmes de fichiers insensibles à la casse ; c'est pourquoi les graines secrètes, les clés TOTP et de nombreux jetons de protocole circulent encore en Base32. Cette capacité implémente l'alphabet de la section six de la RFC 4648 de bout en bout : le mode encode lit votre chaîne en octets UTF-8 et produit un résultat Base32 rempli ; le mode decode accepte un Base32 à casse mixte, supprime les espaces, valide chaque caractère et renvoie le texte UTF-8 d'origine.

Comment le Base32 de la RFC 4648 condense les bits en A-Z et 2-7

La section six de la RFC 4648 définit un alphabet de trente-deux symboles : les vingt-six lettres latines majuscules suivies des six chiffres deux à sept. L'encodage part d'octets bruts. Pour du texte, cette capacité convertit d'abord votre chaîne en UTF-8 afin que les caractères multi-octets restent portables entre langues et plateformes.

Ces octets sont ensuite lus comme un flux de bits continu. Chaque groupe de cinq bits sélectionne un index de l'alphabet, produisant un caractère Base32. Cinq octets d'entrée fournissent quarante bits, qui se divisent proprement en huit caractères Base32 ; les restes plus courts laissent un dernier quintet partiel, complété par des zéros à droite puis par un remplissage en signes égal pour que la longueur totale soit toujours un multiple de huit.

Le décodage inverse la correspondance : chaque caractère hors remplissage apporte cinq bits, les octets complets sont émis dès que huit bits s'accumulent, et le remplissage final est contrôlé pour vérifier sa position légale. Les espaces sont ignorés, ce qui permet de coller des jetons sur plusieurs lignes depuis un courriel. Les minuscules sont converties en majuscules avant la recherche.

Ce rejet strict est volontaire : un remplacement silencieux masquerait des erreurs de transcription dans les secrets d'authentification et les formats filaires.

Ce que vous envoyez et ce que vous recevez

Envoyez un champ chaîne obligatoire nommé text et un champ mode facultatif valant encode ou decode. Lorsque mode est omis, encode est la valeur par défaut, donc une charge utile minimale reste utile. Le mode encode traite text comme du contenu UTF-8 brut et renvoie une chaîne result dans l'alphabet RFC 4648 avec remplissage.

Le mode decode traite text comme du Base32, normalise la casse et les espaces, valide l'alphabet et renvoie la chaîne UTF-8 récupérée dans result. Dans les deux sens, la réponse renvoie mode, le text d'origine, result, un champ length pour la chaîne de sortie principale, les libellés alphabet et charset, un indicateur padding et une courte chaîne de référence standard afin que les clients puissent vérifier le profil appliqué. Les échecs de validation ne consomment pas de solde prépayé.

Les vérifications classiques consistent à encoder Hello en JBSWY3DP, la seule lettre f en MY avec six signes égal de remplissage, puis à décoder un bloc rempli connu pour retrouver foobar. Utilisez le formulaire gratuit du navigateur pour des contrôles rapides et des démonstrations en classe, puis appelez le même contrat depuis vos scripts lorsqu'il vous faut du matériel secret en masse ou des jeux de tests de non-régression.

Où l'encodage Base32 apparaît dans le travail réel

Les secrets de mots de passe à usage unique basés sur le temps, définis par la RFC 6238 et utilisés par les applications d'authentification, voyagent presque toujours en Base32 afin que les utilisateurs puissent les saisir sans confondre autant le zéro avec la lettre O ou le un avec la lettre I qu'avec Base64. Les QR de provisionnement et les codes de secours exigent donc un encodage fiable à la génération des clés et un décodage strict à leur importation.

Le DNS et certains systèmes de configuration réseau préfèrent des alphabets de type Base32 pour les étiquettes opaques qui doivent survivre au pliage de casse. Les liens profonds mobiles et les jetons hors ligne courts choisissent souvent Base32 car l'ensemble de symboles devient insensible à la casse après normalisation et évite les caractères réservés des URL. Les services d'assistance collent des secrets multilignes issus de tickets et ont besoin d'une tolérance aux espaces sans accepter de symboles invalides qui produiraient une mauvaise clé.

Les auteurs de cours sur les schémas d'encodage veulent une page dédiée à Base32 plutôt qu'un enterrement sous une landing générique Base64, car l'intention de recherche et les règles d'alphabet diffèrent. Si vous avez besoin de Base64 avec alphabet sûr pour URL, d'encodage-pourcent pour les URL ou de conversion d'entiers multi-bases, traitez-les comme des intentions de recherche et des landings distinctes plutôt que de surcharger cette page d'encodeur Base32.