Encodeur Git Base85

Git enregistre les changements de fichiers binaires dans des diffs unifiés avec un dialecte Base85 qui lui est propre, ni Adobe Ascii85 ni Base64 simple. Chaque ligne de données commence par une lettre de préfixe de longueur—de A à Z pour un à vingt-six octets décodés, de a à z pour vingt-sept à cinquante-deux—suivie de cinq caractères de l’alphabet pour chaque quatre octets utiles. Les développeurs qui inspectent des sections GIT binary patch, déboguent des échecs d’apply ou créent des outils compatibles ont besoin d’un convertisseur qui parle exactement cet alphabet et cette forme de ligne.

Encoder du texte ou de l’hex en lignes Git Base85

Pour chaque bloc il écrit un préfixe de longueur (A signifie un octet, B deux, jusqu’à Z pour vingt-six, puis a pour vingt-sept jusqu’à z pour cinquante-deux) et développe chaque groupe de quatre octets en cinq caractères de l’alphabet de quatre-vingt-cinq symboles de Git : chiffres, lettres majuscules et minuscules, et l’ensemble de ponctuation qui omet guillemets, virgules, points, barres et barres inverses afin que les correctifs restent adaptés au courrier et au shell.

Un groupe final court est complété de zéros pour l’arithmétique puis tronqué au nombre correct de blocs de cinq caractères, de sorte que le décodeur retrouve le nombre exact d’octets à partir du seul préfixe. Fixez format à hex lorsque la charge est binaire brute : text doit être une chaîne hexadécimale de longueur paire (espaces et tirets bas autorisés), et ces octets sont encodés sans couche UTF-8. Une entrée vide est valide et produit un résultat vide avec zéro octet et zéro ligne.

Le chemin est de l’arithmétique pure—pas de réseau, pas de sel aléatoire, pas d’horloge—ainsi des entrées identiques produisent toujours des corps Base85 identiques pour les goldens d’intégration continue.

Décoder les lignes à préfixe de longueur et rejeter l’entrée invalide

Fixez mode à decode et placez une ou plusieurs lignes Git Base85 dans text. Les lignes vides sont ignorées pour que vous puissiez coller un fragment copié d’un correctif plus large. Après le préfixe, le reste doit faire exactement cinq fois le nombre de groupes de quatre octets requis pour le décompte déclaré—trop peu ou trop de symboles est une erreur, pas une troncature silencieuse.

Chaque caractère encodé doit appartenir à l’alphabet de Git ; un symbole emprunté à Adobe Ascii85 (par exemple un inférieur à isolé ou un z de plage de zéros que Git n’utilise pas) échoue aussitôt pour que vous n’appliquiez jamais par erreur un dialecte étranger comme corps de correctif binaire. Un décodage réussi concatène toutes les lignes dans l’ordre en un seul tampon d’octets.

Avec format hex le résultat est une chaîne hex en minuscules des octets récupérés, le choix pratique lorsque la charge est un littéral compressé zlib d’un vrai GIT binary patch plutôt que du texte lisible.

Ce qui distingue Git Base85 d'Ascii85

On cherche souvent un encodeur Base85 après avoir vu des données binaires dans un git diff, puis on atterrit sur des outils Adobe Ascii85 avec un autre alphabet, des enveloppes optionnelles less-than-tilde et un raccourci z pour les zéros. Le dialecte de Git est volontairement distinct : quatre-vingt-cinq symboles fixes commençant au chiffre zéro, préfixes de longueur par ligne obligatoires, pas de délimiteurs Adobe et pas de jeton z de compression.

Cette page vise l’intention de recherche spécifique à Git—encodeur git base85, correctif binaire base85, décoder git base85—et ne concurrence pas une page Ascii85 générale. Un autre flux colle seulement les lignes de données d’un GIT binary patch (en sautant l’en-tête literal N si vous connaissez déjà la taille) et récupère les octets pour inspection. Gardez des charges modestes—c’est un élément parse de niveau A, pas un serveur de packfiles—et épinglez les chaînes result dans les goldens car l’algorithme est entièrement déterministe entre isolats et langages qui implémentent la même table.