Pourquoi utilisons-nous Base64?

Votre première erreur est de penser que le codage ASCII et de l'encodage Base64 sont interchangeables. Ils ne le sont pas. Ils sont utilisés à des fins différentes.

• Lors de l'encodage de texte en ASCII, vous commencez avec une chaîne de texte et de le convertir en une séquence d'octets.
• Lors de l'encodage des données en Base64, vous commencer avec une séquence d'octets et la convertir en une chaîne de texte.

De comprendre pourquoi Base64 est nécessaire, en premier lieu, nous avons besoin d'un peu de l'histoire de l'informatique.

---

Ordinateurs de communiquer en binaire - 0s et 1s - mais les gens veulent généralement pour communiquer avec les plus riches de données de formulaires tels que du texte ou des images. Afin de transférer des données entre ordinateurs, il doit d'abord être codées en 0 et de 1, envoyé, puis décodé à nouveau. De prendre le texte comme un exemple - il y a beaucoup de différentes manières de réaliser ce codage. Il serait beaucoup plus simple si nous pouvions tous être d'accord sur un codage unique, mais malheureusement, ce n'est pas le cas.

À l'origine d'un grand nombre de différents codages ont été créés (par exemple,Le code Baudot) qui a utilisé un nombre de bits par caractère jusqu'à ce que finalement ASCII est devenu un standard avec 7 bits par caractère. Cependant, la plupart des ordinateurs de stocker des données binaires en octets composé de 8 bits chacun, donc ASCII est impropre à la tranferring ce type de données. Certains systèmes même effacer le bit le plus significatif. En outre, la différence en fin de ligne encodages à travers des systèmes de dire que le caractère ASCII 10 et 13 ont également été modifiés.

Pour résoudre ces problèmes Base64 le codage a été introduit. Ceci vous permet d'encoder aribtrary octets octets qui sont connus pour être sûr d'envoyer sans obtenir endommagé (ASCII des caractères alphanumériques et un couple de symboles). L'inconvénient est que l'encodage du message à l'aide Base64 augmente sa longueur - tous les 3 octets de données sont codées à 4 caractères ASCII.

Pour envoyer du texte de manière fiable, vous pouvez première codent pour des octets à l'aide d'un codage de texte de votre choix (par exemple UTF-8) et puis après Base64 encode le binaire résultant des données dans une chaîne de texte qui est sûr d'envoyer codé en ASCII. Le récepteur devra inverser ce processus pour récupérer le message d'origine. Bien sûr, cela nécessite que le récepteur sait qui les codages ont été utilisés, et cette information doit être envoyée séparément.

Historiquement, il a été utilisé pour encoder des données binaires dans les messages où le serveur de messagerie est susceptible de modifier la ligne de terminaisons. Un exemple plus modern est l'utilisation de l'encodage Base64 pour incorporer les données d'image directement dans le code source HTML. Ici, il est nécessaire d'encoder les données pour éviter les caractères comme '<' et '>' être interprétées comme des balises.

---

Ici est un exemple:

Je souhaite envoyer un message texte avec deux lignes

Bonjour 
monde! 

Si je l'envoyer au format ASCII (ou UTF-8), il ressemblera à ceci:

72 101 108 108 111 10 119 111 114 108 100 33

L'octet 10 est corrompu dans certains systèmes, on peut donc en base 64 encoder ces octets comme une chaîne Base64:

SGVsbG8sCndvcmxkIQ==

Qui lorsqu'ils sont encodés à l'aide de l'ASCII ressemble à ceci:

83 71 86 115 98 71 56 115 67 110 100 118 99 109 120 107 73 61 61

Tous les octets sont connus ici en sécurité octets, donc il y a très peu de chance que tout système corrompu ce message. Je peux envoyer ceci à la place de mon message d'origine et de laisser le récepteur inverser le processus pour récupérer le message d'origine.

Pourquoi ne pas chercher à le RFC définit actuellement en Base64?

Base de l'encodage des données est utilisé dans
de nombreuses situations pour stocker ou transférer

de données dans des environnements qui, peut-être pour
des raisons d'héritage, sont limités à
US-ASCII [1] les données.La Base de l'encodage peut
également être utilisé dans de nouvelles applications
qui n'ont pas hérité des restrictions,
tout simplement parce qu'il rend possible
pour manipuler des objets avec du texte
les éditeurs.

Dans le passé, les différentes applications
ont eu des exigences différentes et
ainsi parfois la mise en œuvre de la base de
les codages légèrement différentes
façons. Aujourd'hui, les spécifications du protocole
parfois, l'utilisation de la base de codages dans les
général, et "base64" en particulier,
sans une description précise ou
de référence. Multipurpose Internet Mail
Extensions (MIME) [4] est souvent utilisé
comme une référence pour les base64 sans
considérant les conséquences pour
l'habillage de ligne ou de non-alphabet
des personnages. Le but de cette
la spécification est d'établir des
alphabet de codage et de la
des considérations. Ce sera, nous l'espérons
réduire l'ambiguïté dans les autres
documents, conduisant à une meilleure
l'interopérabilité.

Base64 a été initialement conçu comme un moyen de permettre à des données binaires à être attachés aux e-mails en tant que partie de la Multipurpose Internet Mail Extensions.

C'est plus que les médias valide le codage de la chaîne, donc nous voulons nous assurer que les données sont acceptables par une manipulation de l'application (et ne pas contenir une séquence binaire représentant en fin de vie par exemple)

Imaginez que vous souhaitez envoyer des données binaires dans un e-mail avec le codage UTF-8 -- L'e-mail peut ne pas s'afficher correctement si le flux de uns et de zéros crée un séquence qui n'est pas valide Unicode en UTF-8.

Le même type de chose qui se passe dans l'Url lorsque l'on veut coder des caractères non valides pour une URL dans l'URL elle-même:

http://www.foo.com/hello mon ami -> http://www.foo.com/hello%20my%20friend

C'est parce que nous voulons envoyer à un espace sur un système qui pense l'espace est puant.

Tout ce que nous faisons est de s'assurer qu'il existe une 1-de-1 mappage entre un bon, acceptable et non préjudiciable de la séquence de bits à un autre littérale de la séquence de bits, et que la manipulation de l'application ne fait pas la distinction l'encodage.

Dans votre exemple, man peut être valable ASCII en première forme; mais souvent, vous aurez besoin de transmettre des valeurs qui sont binaire aléatoire (c'est à dire l'envoi d'une image dans un e-mail):

MIME-Version: 1.0

Contenu-Description: "Base64 encode de a.gif"

Content-Type: image/gif; nom="a.gif"

Content-Transfer-Encoding: Base64

Content-Disposition: attachment; filename="a.gif"

Ici, nous voyons qu'une image GIF est encodé en base64 un morceau d'un e-mail. Le client de messagerie lit les en-têtes et le décode. En raison de l'encodage, on peut être sûr que le GIF ne contiennent pas tout ce qui peut être interprété comme le protocole et nous éviter l'insertion de données SMTP ou POP peut trouver significative.

Base64 au lieu d'échapper les caractères spéciaux

Je vais vous donner un de très différent, mais l'exemple réel: j'écris du code javascript à exécuter dans un navigateur. Les balises HTML ont des valeurs d'ID, mais il y a des contraintes sur les caractères valides dans un ID.

Mais je veux que mon ID sans perte reportez-vous aux fichiers dans mon système de fichiers. Les fichiers dans la réalité peuvent avoir toutes sortes d'étranges et merveilleux de caractères à partir de points d'exclamation, les caractères accentués, tilde, même emoji! Je ne peux pas faire ceci:

<div id="/path/to/my_strangely_named_file!@().jpg">
    <img src="http://myserver.com/path/to/my_strangely_named_file!@().jpg">
    Here's a pic I took in Moscow.
</div>

Suppose que j'ai besoin d'exécuter du code comme ceci:

# ERROR
document.getElementById("/path/to/my_strangely_named_file!@().jpg");

Je pense que ce code va échouer lors de l'exécution.

Avec Base64 je peux vous référer à quelque chose de compliqué, sans se soucier de la langue qui permet à ce que les caractères spéciaux et qui ont besoin d'échappement:

document.getElementById("18GerPD8fY4iTbNpC9hHNXNHyrDMampPLA");

Contrairement à l'utilisation d'un MD5 ou une autre fonction de hachage, vous pouvez inverser l'encodage pour savoir exactement ce que les données ont été que réellement utile.

Je souhaite que je savais à propos de Base64 ans. J'aurais évité de déchirer mes cheveux avec ‘ encodeURIComponent " et str.replace(‘\n’,’\\n’)

SSH transfert de texte:

Si vous essayez de transmettre des données complexes sur ssh (par exemple, un dotfile de sorte que vous pouvez obtenir votre shell personnalisations), bonne chance de le faire sans en Base 64. C'est de cette façon que vous feriez avec base 64 (je sais que vous pouvez utiliser SCP, mais ce serait prendre plusieurs commandes qui complique les raccourcis clavier pour sshing dans un serveur):

• https://superuser.com/a/1376076/114723

Que signifie "médias qui sont
conçu pour traiter les données textuelles"?

Que ces protocoles ont été conçus pour manipuler du texte (souvent, seulement anglais texte) au lieu de données binaires (comme .png et .des images jpg).

Ils peuvent traiter avec les binaires => ils peuvent
face à quoi que ce soit.

Mais l'inverse n'est pas vrai. Un protocole conçu pour représenter le texte peut mal traiter des données binaires qui arrive à contenir:

• Les octets et 0x0D 0x0A, utilisé pour les fins de ligne, qui diffèrent par la plate-forme.
• Les autres caractères de contrôle comme 0x00 (NULL = C terminateur de chaîne), 0x03 (FIN DE TEXTE), 0x04 (FIN DE TRANSMISSION), ou 0x1A (DOS en fin de fichier), qui peut prématurément le signal de la fin des données.
• Octets au-dessus de 0x7F (si le protocole qui a été conçu pour ASCII).
• Les séquences d'octets qui sont en UTF-8 non valide.

De sorte que vous ne pouvez pas envoyer des données binaires sur un protocole basé sur du texte. Vous êtes limité à la octets qui représentent le non-espace de non-contrôle des caractères ASCII, dont il y a 94. La raison en Base 64 fut choisi que c'est plus rapide de travailler avec des puissances de deux, et de 64 est le plus grand qui fonctionne.

Une question cependant. Comment est-ce
les systèmes ne sont pas d'accord sur la commune
l'encodage de la technique comme la si commun
UTF-8?

Sur le Web, au moins, pour la plupart ils ont. Une majorité de sites à utiliser l'UTF-8.

Le problème de l'Occident est qu'il y a beaucoup de vieux logiciel qui cul-u-me-s que 1 octet = 1 caractère et ne peut pas travailler avec l'encodage UTF-8.

Le problème est, en Orient leur attachement à encodages comme GB2312 et Shift_JIS.

Et le fait que Microsoft semble avoir toujours pas obtenu d'avoir choisi le mauvais encodage UTF. Si vous souhaitez utiliser l'API Windows ou Microsoft C runtime library, vous êtes limité à UTF-16 ou des paramètres régionaux "ANSI" encodage. De ce fait douloureux pour utiliser l'UTF-8 parce que vous avez à convertir tout le temps.

Pourquoi/Comment utiliser le codage Base64?

Base64 est un du binaire à l'encodage du texte schéma d'avoir 75% d'efficacité. Il est utilisé de sorte que, typique des données binaires (images) peut être envoyé en toute sécurité sur l'héritage "pas 8-bit clean" chaînes".
Précédemment dans des réseaux de messagerie (jusqu'au début des années 1990), la plupart des e-mail des messages en texte brut dans les 7 bits de caractères US-ASCII. Donc, de nombreuses début de protocole de communication normes ont été conçues pour fonctionner sur les "7 bits" comm liens "pas 8-bit clean".
Schéma de l'efficacité est le rapport entre le nombre de bits dans l'entrée et le nombre de bits dans l'encodage de sortie.
Hexadécimal (Base16) est également l'un de binaire-codage de texte régime avec 50% d'efficacité.

De L'Encodage Base64 Étapes (Simplifié):

1. Données binaires sont disposés en continu des morceaux de 24 bits (3 octets) chacune.
2. Chaque 24 bits, le morceau est regroupé en quatre pièces de 6 bits chacun.
3. Chaque 6 bits groupe est converti en leur correspondant en Base64 des valeurs de caractère, c'est à dire de l'encodage Base64 convertit les trois octets en quatre caractères codés. Le ratio de la production octets octets d'entrée est de 4:3 (33% de frais généraux).
4. Fait intéressant, les mêmes caractères sont codés différemment en fonction de leur position dans les trois octet groupe qui est codé pour produire les quatre personnages.
5. Le récepteur devra inverser ce processus pour récupérer le message d'origine.