1. Introduction

L'encodage de base des données est utilisé dans de nombreuses situations pour stocker ou transmettre des données dans des environnements restreints aux données US-ASCII [1], peut-être pour des raisons historiques. L'encodage de base peut également être utilisé par de nouvelles applications sans contrainte historique, simplement parce qu'il permet de manipuler des objets avec un éditeur de texte.

Par le passé, les différentes applications avaient des exigences différentes, de sorte que l'encodage de base était parfois implémenté de manière légèrement différente. Aujourd'hui, les spécifications de protocole utilisent parfois l'encodage de base, en particulier « base64 », de manière générale sans description ni référence précise. Multipurpose Internet Mail Extensions (MIME) [4] est souvent cité comme référence pour base64 sans considérer l'impact des sauts de ligne ou des caractères hors alphabet. Le but de cette spécification est d'établir un alphabet commun et des considérations d'encodage. Cela devrait réduire l'ambiguïté dans d'autres documents, conduisant à une meilleure interopérabilité.

---

Pourquoi l'encodage de base est nécessaire

Problème central

De nombreux systèmes et protocoles historiques ne peuvent traiter que des données texte (US-ASCII) et ne peuvent pas transmettre directement des données binaires :

Scénarios problématiques :
❌ Systèmes de messagerie (SMTP) — ASCII 7 bits uniquement
❌ Paramètres d'URL — certains caractères ont une signification spéciale
❌ JSON/XML — impossible d'intégrer directement des données binaires
❌ Éditeur de texte — impossible d'éditer des fichiers binaires

Solution par l'encodage de base

Données binaires → encodage de base → données texte
(imprimables)       (conversion)       (imprimables, transmissibles)

Exemple :
Données brutes : [0x48, 0x65, 0x6C, 0x6C, 0x6F]  (binaire)
Base64 :         "SGVsbG8="                      (texte)

---

Contexte historique et problèmes d'interopérabilité

Problèmes causés par les divergences d'implémentation

Avant la normalisation de Base64, il existait des différences entre les implémentations :

Implémentation	Limite de longueur de ligne	Règle de remplissage	Alphabet
MIME	76 caractères	Requis	Standard
PEM	64 caractères	Requis	Standard
Certains encodages d'URL	Aucune limite	Optionnel	Sûr pour URL

Ces différences ont entraîné :

• ❌ Échecs d'échange de données entre systèmes
• ❌ Erreurs de décodage
• ❌ Vulnérabilités de sécurité

Valeur du RFC 4648

Cette spécification résout ces problèmes en :

1. Alphabet unifié — définit clairement les alphabets standard Base64, Base32, Base16
2. Règles claires — spécifie comment gérer les sauts de ligne, le remplissage, les caractères illégaux
3. Fournit des variantes — définit la variante Base64 sûre pour les URL
4. Interopérabilité — assure la compatibilité entre différentes implémentations

---

Scénarios applicables

Applications typiques de Base64

1. Pièces jointes e-mail (MIME)
   Content-Transfer-Encoding: base64
   
2. Data URI
   data:image/png;base64,iVBORw0KGgo...
   
3. Jeton JWT
   eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
   
4. Authentification HTTP Basic
   Authorization: Basic dXNlcjpwYXNz
   
5. Intégration de données binaires dans XML/JSON
   {"avatar": "SGVsbG8gV29ybGQ="}

Pourquoi ne pas transmettre directement le binaire ?

Raisons :
1. Limites de protocole — SMTP, en-têtes HTTP en ASCII uniquement
2. Sécurité du texte — évite les problèmes causés par les caractères de contrôle
3. Édition possible — peut être visualisé et modifié avec un éditeur de texte
4. Compatibilité — transmission plus fiable multiplateforme et intersystèmes

---

Objectifs de cette spécification

RFC 4648 vise à :

✅ Éliminer l'ambiguïté — fournit une définition d'encodage claire et non ambiguë
✅ Améliorer l'interopérabilité — assure la compatibilité entre implémentations
✅ Offrir des choix — propose des variantes d'encodage adaptées à différents scénarios
✅ Considérations de sécurité — spécifie clairement les exigences d'implémentation liées à la sécurité

---

Étapes suivantes

Les sections suivantes détaillent :

• Section 2 : conventions d'utilisation des mots-clés RFC 2119
• Section 3 : divergences d'implémentation et comportement recommandé
• Sections 4–8 : spécifications détaillées de chaque encodage de base
• Sections 9–10 : exemples et vecteurs de test
• Section 12 : considérations de sécurité

---