Ces trois noms décrivent des schémas binaires-texte associés, mais ils répondent à des contraintes différentes. Base64 et Base64URL utilisent des groupes de six bits. La norme Base32 utilise des groupes de cinq bits et un alphabet plus petit. Le bon choix est celui que votre application de transport, de stockage et de réception peut préserver exactement.
Comparez les alphabets avant les longueurs
Le Base64 standard utilise des lettres majuscules et minuscules, des chiffres, le signe plus (+) et la barre oblique (/). Base64URL remplace ces deux derniers caractères par un tiret (-) et un trait de soulignement (_). Les deux variantes sont sensibles à la casse. Le Base32 défini par la RFC utilise les majuscules A–Z et les chiffres 2–7. Un décodeur peut accepter les minuscules par commodité, mais le protocole doit préciser si cela est autorisé et définir sa sortie canonique.
Un canal insensible à la casse peut détruire une valeur Base64 tout en préservant une valeur Base32 correctement spécifiée. Un jeton URL a des contraintes différentes d'un code lu à voix haute sur un téléphone. Ne choisissez pas uniquement en fonction de la brièveté d’un échantillon.
Comprendre le compromis de taille
En ignorant le groupe partiel final, Base64 a besoin d'environ 1,33 caractères par octet et Base32 en a besoin de 1,6. La norme remplie Base32 émet des groupes de huit caractères pour cinq octets. Pour un octet contenant la lettre f, les vecteurs communs sont Zg== dans Base64 et MY====== dans Base32. Les petites entrées exagèrent la surcharge de remplissage, alors comparez les longueurs de charge utile réalistes.
Payload bytes: 66 (ASCII f)
Base64: Zg==
Base64URL: Zg== (or Zg when the protocol omits padding)
RFC Base32: MY======Ne mélangez pas les variantes Base32
Crockford Base32 est conçu autour d'identifiants lisibles par l'homme et utilise un alphabet et des règles d'ambiguïté différents de la RFC Base32. Base32hex diffère également. Une valeur produite par une variante ne peut pas être transmise aveuglément à un autre décodeur. Nommez la variante, l'alphabet, la politique de remplissage et tout comportement de somme de contrôle dans votre documentation.
Le codage ne fournit pas non plus d’authentification. Une valeur mal saisie peut toujours être syntaxiquement valide et décodée en différents octets. Si les utilisateurs transcrivent un code, envisagez une somme de contrôle ou une étape de vérification définie par le protocole plutôt que de supposer que l'alphabet détecte chaque erreur.
Rédigez le contrat complet
Spécifiez l'ordre des octets d'entrée le cas échéant, le comportement d'entrée vide, la préservation des zéros non significatifs, la longueur maximale, l'acceptation des espaces et la gestion des caractères non valides. Incluez des vecteurs de test avec des octets de grande valeur et des groupes partiels. Utilisez l'encodeur et le décodeur choisis indépendamment contre ces vecteurs, pas seulement les uns contre les autres ; les bogues correspondants peuvent autrement sembler passer un aller-retour. Les formes standards et les vecteurs de référence sont en RFC 4648.