Pourquoi base64 est-il nécessaire (pourquoi ne puis-je pas envoyer un fichier binaire par courrier électronique)?
Je lisais sur le codage Base64, et j'ai trouvé ceci sur Wikipedia:
Les schémas de codage Base64 sont couramment utilisés lorsqu'il est nécessaire de coder des données binaires qui doivent être stockées et transférées sur un support conçu pour traiter des données textuelles.
... et l'exemple donné envoie des fichiers binaires par courrier électronique.
J'essaie de comprendre pourquoi base64 est nécessaire. Étant donné que les données binaires sont un groupe d’octets, ne pourrait-on pas les traduire directement en ASCII, qui sont des données textuelles? Pourquoi base64 est-il nécessaire? Ou bien le courrier électronique a-t-il un problème avec les caractères de contrôle en ASCII?
Il y a un bon article Wikipedia à ce sujet.
Les premières itérations de NCP, telles qu'utilisées par ARPAnet, ressemblaient davantage à des flux de bits qu'à des flux d'octets, ou tentaient de négocier une taille d'octet convenable; l'octet de 8 bits n'a été normalisé que beaucoup plus tard. Plusieurs tentatives ont également été tentées pour créer des protocoles de transfert de fichiers qui fonctionneraient sur différentes machines (le courrier était initialement une fonction du protocole FTP, principalement sous forme de commandes MAIL ET MLFL , puis scindé en MTP , plus tard SMTP .). Ces machines avaient souvent des codages de caractères différents - ASCII vs EBCDIC - ou même différentes tailles en octets , octets 8 bits vs 6 bits contre ...
Par conséquent, les fonctions de transfert du courrier ont été définies à l’origine pour le transfert de messages relativement courts en texte brut; spécifiquement, "NVT-ASCII". Par exemple, RFC 772 dit:
REPRÉSENTATION ET STOCKAGE DU COURRIER
Le courrier est transféré d'un périphérique de stockage de l'hôte émetteur vers un périphérique de stockage de l'hôte destinataire. Il peut être nécessaire d'effectuer certaines transformations sur le courrier car les représentations de stockage de données dans les deux systèmes sont différentes. Par exemple, NVT-ASCII a différentes représentations de stockage de données dans différents systèmes. Les PDP-10 stockent généralement NVT-ASCII sous la forme de cinq caractères ASCII 7 bits, justifiés à gauche dans un mot de 36 bits. 360's stocke NVT-ASCII sous forme de quatre codes EBCDIC 8 bits dans un mot 32 bits. Multics stocke NVT-ASCII sous forme de quatre caractères de 9 bits dans un mot de 36 bits.
Par souci de simplicité, toutes les données doivent être représentées dans MTP en tant que NVT-ASCII. Cela signifie que les caractères doivent être convertis en représentation NVT-ASCII standard lors de la transmission de texte, que les hôtes d'envoi et de réception soient différents. L'expéditeur convertit les données de sa représentation de caractère interne en une représentation NVT-ASCII 8 bits standard (voir la spécification TELNET). Le récepteur convertit les données du formulaire standard dans son propre formulaire interne. Conformément à cette norme, la séquence doit être utilisée pour indiquer la fin d'une ligne de texte.
Même si huit bits étaient transmis sur le fil, le huitième bit était souvent jeté ou mutilé, car il n’était pas nécessaire de le conserver; en fait, certains protocoles exigeaient que le huitième bit soit mis à zéro, tel que le --- SMTP RFC cité ci-dessous. En d'autres termes, le logiciel n'était pas nettoyage en 8 bits .
Transfert de données
La connexion TCP prend en charge la transmission d'octets de 8 bits. Les données SMTP contiennent _ ASCII caractères 7 bits. Chaque caractère est transmis sous forme d'octet de 8 bits avec le bit de poids fort mis à zéro.
Cela a persisté longtemps même après que les codages de caractères ISO-8859- # à 8 bits se soient généralisés. Même si certains serveurs étaient déjà propres 8 bits, de nombreux autres ne l'étaient pas et l'envoi aveugle de données 8 bits aurait entraîné des messages mutilés.
Plus tard, "Extended SMTP" a été publié, permettant aux serveurs de messagerie de déclarer les extensions SMTP prises en charge. L'un d'entre eux était 8BITMIME , ce qui indique que le serveur de réception peut accepter des données 8 bits en toute sécurité. Les parties du message MIME peuvent avoir " Content-Transfer-Encoding : 8bit", indiquant qu'elles ne sont en aucun cas codées.
Cependant, le protocole SMTP est resté basé sur la ligne et a une limite de ligne de 998 octets, tout en utilisant une ligne . (0D 0A 2E 0D 0A) comme indicateur de "fin de message". Cela signifie que, même si la plupart des fichiers binaires peuvent être envoyés sans modification, il est toujours possible que les fichiers contenant cette séquence d'octets soient interprétés comme la fin du message transféré et le reste du fichier comme une commande SMTP, pouvant causer des dommages. De même, une "ligne" de plus de 998 octets peut être coupée par le serveur de réception.
En 2000, le "BINARYMIME" extension ESMTP a été publié sous la forme RFC 30 , permettant ainsi le transfert de données binaires brutes sur SMTP. Le message est maintenant transféré dans des fragments de longueur pré-indiquée, avec un fragment de longueur zéro utilisé comme terminateur, et les codages Base64 et similaires ne sont plus nécessaires. Malheureusement, peu de serveurs SMTP prennent en charge cette extension. Par exemple, ni Postfix ni Exim4 ne publient CHUNKING en réponse à EHLO. Pour tirer parti de BINARYMIME, il devrait être pris en charge par tous les serveurs du chemin de messages, qui peut être supérieur à un ou deux.
Voir également:
Certains systèmes et logiciels de messagerie plus anciens n'étaient pas nettoyage sur 8 bits , le 8ème bit était utilisé comme caractère de contrôle. Cela suffisait pour détruire des fichiers binaires, donc Base64 (ou d’autres schémas de codage) était nécessaire.