« Base64 » : différence entre les versions
Page créée avec « Beaucoup de mécanisme de communications autorisent les échanges de caractères mais pas de données binaires. Une liaison série E71 (7 bits avec paraité paire et 1 bit de stop) le permet, par exemple, que du transfert de caractères ASCII de base. Si on désire transférer un fichier binaire (une clé de chiffrage, image bitmap, un fichier exécutable...) on ne peut pas le transférer octets par octets car on va perdre l'octet de poids fort. On utilise... » |
mAucun résumé des modifications |
||
| (Une version intermédiaire par le même utilisateur non affichée) | |||
| Ligne 1 : | Ligne 1 : | ||
Beaucoup de mécanisme de communications autorisent les échanges de caractères mais pas de données binaires. Une liaison série | Beaucoup de mécanisme de communications autorisent les échanges de caractères mais pas de données binaires. Une liaison série 1E71 (1 bit de start, 7 bits, parité paire et 1 bit de stop) le permet, par exemple, que du transfert de caractères [[ASCII]] de base. | ||
Si on désire transférer un fichier binaire (une clé de chiffrage, image bitmap, un fichier exécutable...) on ne peut pas le transférer octets par octets car on va perdre l'octet de poids fort. | Si on désire transférer un fichier binaire (une clé de chiffrage, image bitmap, un fichier exécutable...) on ne peut pas le transférer octets par octets car on va perdre l'octet de poids fort. | ||
| Ligne 6 : | Ligne 6 : | ||
On se limite donc a un "alphabet" de 64 caractères soit:<syntaxhighlight lang="text"> | On se limite donc a un "alphabet" de 64 caractères soit:<syntaxhighlight lang="text"> | ||
HEXA: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F | |||
</syntaxhighlight> | BASE64: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f | ||
HEXA: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F | |||
BASE64: g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 + / | |||
</syntaxhighlight>La [https://datatracker.ietf.org/doc/html/rfc4648 <abbr>RFC</abbr> 4648] décrit ce format. | |||
64 caractères encodent 6 bits et on cherche à encoder des symboles de 8 bits. | Tous ces caractères sont imprimables sans aucune ambiguité. | ||
64 caractères encodent 6 bits et on cherche à encoder des symboles de 8 bits. Le PPCM de 6 et 8 est 24. | |||
On va donc coder 3 octets de 8 bits en 4 symboles sur 6 bits. | |||
[[Fichier:Code-base64.png|sans_cadre|682x682px]] | |||
Les trois octets AE 00 55 sont traduit en Base64 en <code>"ryBY"</code>. On évite donc que les caractères AE et 00 qui provoqueraient une erreur en ASCII. | |||
Puisque les données d'entrée doivent être constituées d'un nombre entier d'octets, seuls trois cas sont possibles en fin de séquence : | |||
* il reste exactement 3 octets à coder (24 bits), alors on obtient directement 4 caractères sans traitement complémentaire. | |||
* il reste seulement 2 octets (16 bits) à coder, alors on ajoute à droite 2 bits à zéros pour former 3 caractères de l'alphabet (3×6 = 16+2 = 18 bits) suivis d'un quatrième caractère « <code>=</code> » en complément ; | |||
* il reste un seul octet (8 bits) à coder, alors on ajoute à droite 4 bits à zéro pour former 2 caractères de l'alphabet (2×6 = 8+4 = 12 bits) suivis de deux caractères « <code>=</code> » en complément | |||
Si notre fichier se termine par un "U" par exemple et qu'il faille deux octets pour arriver à une taille multiple de 3. | |||
[[Fichier:Base64-padding1.png|sans_cadre|680x680px]] | |||
Le code base 64 sera "VQ==" | |||
Si on termine par "UU" | |||
Dernière version du 12 mars 2026 à 15:52
Beaucoup de mécanisme de communications autorisent les échanges de caractères mais pas de données binaires. Une liaison série 1E71 (1 bit de start, 7 bits, parité paire et 1 bit de stop) le permet, par exemple, que du transfert de caractères ASCII de base.
Si on désire transférer un fichier binaire (une clé de chiffrage, image bitmap, un fichier exécutable...) on ne peut pas le transférer octets par octets car on va perdre l'octet de poids fort.
On utilise alors une méthode qui permet de coder des données 8bit pour qu'elles passent sur une liaison textuelle. On ne peut pas utiliser tout le spectre ASCII car certains codes sont "non imprimables". Se sont, en particulier, les caractère dont le code est < 32.
On se limite donc a un "alphabet" de 64 caractères soit:
HEXA: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F
BASE64: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e f
HEXA: 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F
BASE64: g h i j k l m n o p q r s t u v w x y z 0 1 2 3 4 5 6 7 8 9 + /
La RFC 4648 décrit ce format.
Tous ces caractères sont imprimables sans aucune ambiguité.
64 caractères encodent 6 bits et on cherche à encoder des symboles de 8 bits. Le PPCM de 6 et 8 est 24.
On va donc coder 3 octets de 8 bits en 4 symboles sur 6 bits.
Les trois octets AE 00 55 sont traduit en Base64 en "ryBY". On évite donc que les caractères AE et 00 qui provoqueraient une erreur en ASCII.
Puisque les données d'entrée doivent être constituées d'un nombre entier d'octets, seuls trois cas sont possibles en fin de séquence :
- il reste exactement 3 octets à coder (24 bits), alors on obtient directement 4 caractères sans traitement complémentaire.
- il reste seulement 2 octets (16 bits) à coder, alors on ajoute à droite 2 bits à zéros pour former 3 caractères de l'alphabet (3×6 = 16+2 = 18 bits) suivis d'un quatrième caractère «
=» en complément ; - il reste un seul octet (8 bits) à coder, alors on ajoute à droite 4 bits à zéro pour former 2 caractères de l'alphabet (2×6 = 8+4 = 12 bits) suivis de deux caractères «
=» en complément
Si notre fichier se termine par un "U" par exemple et qu'il faille deux octets pour arriver à une taille multiple de 3.
Le code base 64 sera "VQ=="
Si on termine par "UU"