Base64

La RFC spécifie également un second encodage Base64, appelé « Encodage Base64 avec alphabet sécurisé pour les URL et les noms de fichiers » , destiné à représenter des informations d'identification relativement longues. Par exemple, un système de persistance de base de données pour objets Java peut utiliser l'encodage Base64 pour encoder un identifiant unique relativement long (généralement un UUID de 128 bits ) sous forme de chaîne de caractères, utilisable comme paramètre HTTP dans un formulaire HTTP ou une requête HTTP GET . De plus, de nombreuses applications doivent encoder des données binaires de manière à faciliter leur intégration dans une URL, y compris dans des champs cachés de formulaires web ; l'encodage Base64 est alors particulièrement adapté pour les afficher de façon compacte.

L'utilisation du Base64 standard dans une URL nécessite l'encodage des caractères +`\`, `\` /et `\` sous forme de séquences hexadécimales spéciales encodées en pourcentage (`\` devient `\` , `\` devient `\` et `\ ` devient ` \`), ce qui allonge la chaîne et la rend plus difficile à lire. L'utilisation d'un alphabet différent permet un encodage Base64 sans ce balisage supplémentaire. Généralement, `\`, `\` et `\` sont remplacés respectivement par `\` et `\`, de sorte que l'utilisation d'encodeurs/décodeurs d'URL n'est plus nécessaire et n'a aucun impact sur la longueur de la valeur encodée, conservant ainsi la même forme encodée pour une utilisation dans les bases de données relationnelles, les formulaires web et les identificateurs d'objets en général. YouTube est un exemple populaire d'utilisation de cette méthode . Certaines variantes autorisent ou exigent l'omission des signes de remplissage pour éviter toute confusion avec les séparateurs de champs, ou exigent que tout remplissage soit encodé en pourcentage. Certaines bibliothèques encodent ` \` comme `\`, exposant potentiellement les applications à des attaques par chemin relatif lorsqu'un nom de dossier est encodé à partir de données utilisateur.=+%2B/%2F=%3D+/-_=La RFC 3548 , intitulée « Encodages de données Base16, Base32 et Base64 » , est une note d'information (non normative) visant à unifier les spécifications des RFC 1421 et RFC 2045 relatives aux encodages Base64, aux encodages à alphabet alternatif, ainsi qu'aux encodages Base32 (rarement utilisé) et Base16. La RFC 4648 remplace la RFC 3548.

À moins qu'un encodeur ne soit écrit selon une spécification qui fait référence à la RFC 3548 et exige spécifiquement le contraire , la RFC 3548 interdit à un encodeur de générer des messages contenant des caractères en dehors de l'alphabet d'encodage ou sans remplissage, et elle déclare également qu'un décodeur doit rejeter les données contenant des caractères autres que l'alphabet d'encodage. MIME (Multipurpose Internet Mail Extensions) mentionne Base64 comme l'un des deux schémas d'encodage binaire-texte (l'autre étant quoted-printable ). L'encodage Base64 de MIME est basé sur celui de la version PEM de la RFC 1421 : il utilise le même alphabet de 64 caractères et le même mécanisme d'encodage que PEM et utilise le symbole de remplissage de sortie de la même manière, comme décrit dans la RFC 2045 .=

MIME ne spécifie pas de longueur fixe pour les lignes encodées en Base64, mais impose une longueur maximale de 76 caractères. De plus, il précise que tout caractère hors de l'ensemble standard de 64 caractères d'encodage (par exemple, les séquences CRLF) doit être ignoré par un décodeur compatible, bien que la plupart des implémentations utilisent une paire de sauts de ligne CR/LF pour délimiter les lignes encodées.

Ainsi, la longueur réelle des données binaires encodées en Base64 conformes à la norme MIME représente généralement environ 137 % de la longueur des données d'origine (4/3 × 78/76 ) . Toutefois , pour les messages très courts , la surcharge peut être bien plus importante en raison de la taille des en-têtes. En première approximation, la taille finale des données binaires encodées en Base64 est égale à 1,37 fois la taille des données d'origine, plus 814 octets (pour les en-têtes). La taille des données décodées peut être estimée par la formule suivante :Privacy-Enhanced Mail (PEM), proposé par la RFC 989 en 1987. PEM définit un schéma d'« encodage imprimable » qui utilise l'encodage Base64 pour transformer une séquence arbitraire d'octets en un format pouvant être exprimé en courtes lignes de caractères de 6 bits, comme requis par les protocoles de transfert tels que SMTP .

La version actuelle de PEM (spécifiée dans la RFC 1421 ) utilise un alphabet de 64 caractères composé de lettres romaines majuscules et minuscules ( – , – ), des chiffres ( – ) et des symboles et . Le symbole est également utilisé comme suffixe de remplissage. La spécification originale, RFC 989 , utilisait en outre le symbole pour délimiter les données encodées mais non chiffrées au sein du flux de sortie.AZaz09+/=*

Pour convertir des données en encodage PEM imprimable, le premier octet est placé dans les huit bits de poids fort d'un tampon de 24 bits , le suivant dans les huit bits de poids faible et le troisième dans les huit bits de poids faible . S'il reste moins de trois octets à encoder (ou moins au total), les bits restants du tampon sont mis à zéro. Le tampon est ensuite utilisé, six bits à la fois, du plus significatif au plus profond, comme indices dans la chaîne : «ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ », et le caractère indiqué est affiché.

Le processus est répété sur les données restantes jusqu'à ce qu'il en reste moins de quatre. S'il reste trois octets, ils sont traités normalement. S'il reste moins de trois octets (24 bits) à encoder, les données d'entrée sont complétées à droite par des bits nuls pour former un multiple entier de six bits.

Après l'encodage des données non complétées, si deux octets du tampon 24 bits sont remplis de zéros, deux =caractères sont ajoutés à la sortie ; si un seul octet du tampon 24 bits est rempli de zéros, un seul =caractère est ajouté. Ceci indique au décodeur que les bits nuls ajoutés par le remplissage doivent être exclus des données reconstruites. Cela garantit également que la longueur de la sortie encodée est un multiple de 4 octets.

Le format PEM exige que toutes les lignes encodées comportent exactement 64 caractères imprimables, à l'exception de la dernière ligne qui peut en contenir moins. Les lignes sont délimitées par des espaces selon les conventions locales (spécifiques à la plateforme).