Un codage n’est utile que si les deux extrémités sont d’accord. La plus petite représentation n'est pas nécessairement le meilleur choix lorsque le récepteur a besoin d'un alphabet familier, que la charge utile doit être saisie par une personne ou que la syntaxe environnante traite spécifiquement certains caractères. Commencez par le protocole de réception.
Hex est verbeux mais facile à inspecter
Hexadécimal écrit chaque octet sous forme de deux chiffres. La séquence d'octets FF 00 41 devient ff0041. Chaque paire a une limite d'octets visible, ce qui facilite l'inspection des signatures de fichiers, des sommes de contrôle et des paquets de protocole. Il double le nombre de caractères, mais son petit alphabet s'intègre généralement facilement dans les journaux et les outils de débogage.
Base64 équilibre taille et interopérabilité
Base64 représente trois octets avec quatre caractères. Il s'agit d'un ajustement courant pour les champs binaires dans les formats texte. La norme Base64 inclut le signe plus et la barre oblique ; Base64URL remplace ces caractères lorsqu'un protocole nécessite un alphabet différent. Les règles de remplissage et d'espacement nécessitent encore un accord. Aucune des deux formes n'indique au récepteur si les octets décodés sont du texte, une image ou du contenu compressé.
Le codage en pourcentage appartient aux composants URL
Le codage en pourcentage écrit un octet d'échappement sous la forme %HH. Il ne s’agit pas simplement d’un substitut massif à Base64. Le composant détermine quels caractères doivent être échappés et le texte doit d'abord être codé sous la forme UTF-8. Une barre oblique peut séparer les segments de chemin tandis qu'un point d'interrogation démarre une requête ; traiter l’ensemble URL comme un seul composant opaque change sa signification.
console.log(encodeURIComponent('a+b / 中文'));
// a%2Bb%20%2F%20%E4%B8%AD%E6%96%87Base85 nécessite une variante exacte
De nombreux schémas Base85 représentent quatre octets avec cinq caractères, mais leurs alphabets, délimiteurs et cas particuliers diffèrent. ASCII85 et Z85 ne peuvent pas être considérés comme interchangeables. Z85 impose également des exigences en matière de taille de bloc. Un alphabet à haute densité peut contenir des signes de ponctuation qui doivent être à nouveau échappés dans le format environnant, ce qui réduit l'avantage apparent.
Ne confondez pas ces codages d'octets avec la conversion de l'entier 255 entre les bases numériques. Un fichier peut commencer par zéro octet, tandis qu'une représentation entière peut ignorer ces zéros non significatifs. Un codec de fichier réversible doit définir la manière dont la longueur et les zéros non significatifs sont préservés.
Utilisez Hex pour l'inspection des octets, la variante Base64 spécifiée pour le transport binaire interopérable, le codage des composants URL pour les URL et un schéma spécialisé uniquement lorsque les deux parties mettent en œuvre le même contrat. Comparez la taille de bout en bout après échappement et compression. RFC 4648 définit les familles standards Base16, Base32 et Base64, y compris leurs alphabets distincts.