Git-Base85-Kodierer

Git speichert binäre Dateiänderungen in Unified Diffs mit einem eigenen Base85-Dialekt, nicht Adobe Ascii85 und nicht schlichtes Base64. Jede Datenzeile beginnt mit einem Längenpräfix-Buchstaben—A bis Z für ein bis sechsundzwanzig dekodierte Bytes, a bis z für siebenundzwanzig bis zweiundfünfzig—gefolgt von fünf Alphabetzeichen für je vier Nutzdatenbytes. Entwickler, die GIT-binary-patch-Abschnitte prüfen, Apply-Fehler debuggen oder kompatible Werkzeuge bauen, brauchen einen Konverter, der genau dieses Alphabet und diese Zeilenform spricht.

Text oder Hex in Git-Base85-Zeilen kodieren

Für jeden Block schreibt sie ein Längenpräfix (A bedeutet ein Byte, B zwei, bis Z für sechsundzwanzig, dann a für siebenundzwanzig bis z für zweiundfünfzig) und expandiert jede Vierergruppe in fünf Zeichen aus Gits fünfundachtzig-Symbol-Alphabet: Ziffern, Groß- und Kleinbuchstaben sowie den Zeichensatz, der Anführungszeichen, Kommas, Punkte, Schrägstriche und Backslashes auslässt, damit Patches mail- und shell-freundlich bleiben. Eine kurze Schlussgruppe wird für die Arithmetik mit Nullen aufgefüllt und dann auf die richtige Anzahl Fünferblöcke gekürzt, sodass der Dekodierer die exakte Bytezahl allein aus dem Präfix gewinnt.

Setzen Sie format auf hex, wenn die Nutzlast rohe Binärdaten sind: text muss eine hexadezimale Zeichenkette gerader Länge sein (Leerzeichen und Unterstriche erlaubt), und diese Bytes werden ohne UTF-8-Schicht kodiert. Leere Eingabe ist gültig und liefert ein leeres Ergebnis mit null Bytes und null Zeilen. Der Pfad ist reine Arithmetik—kein Netz, kein Zufallssalz, keine Uhr—daher erzeugen identische Eingaben stets identische Base85-Körper für Continuous-Integration-Goldens.

Zeilen mit Längenpräfix dekodieren und ungültige Eingabe ablehnen

Setzen Sie mode auf decode und legen Sie eine oder mehrere Git-Base85-Zeilen in text. Leerzeilen werden ignoriert, damit Sie ein Fragment aus einem größeren Patch einfügen können. Nach dem Präfix muss der Rest genau das Fünffache der Anzahl benötigter Vierergruppen für die deklarierte Bytezahl sein—zu wenige oder zu viele Symbole sind ein Fehler, keine stille Kürzung.

Jedes kodierte Zeichen muss im Git-Alphabet liegen; ein aus Adobe Ascii85 entlehntes Symbol (zum Beispiel ein freies Kleiner-als oder ein z-Nullenlauf, den Git nicht nutzt) scheitert sofort, damit Sie nie versehentlich einen fremden Dialekt als Binärpatch-Körper anwenden. Erfolgreiches Dekodieren verkettet alle Zeilen der Reihe nach zu einem einzigen Bytepuffer. Bei format hex ist das Ergebnis eine kleingeschriebene Hex-Zeichenkette der gewonnenen Bytes—die praktische Wahl, wenn die Nutzlast zlib-komprimierte Literaldaten aus einem echten GIT binary patch und kein lesbarer Text ist.

Viele suchen einen Base85-Kodierer, nachdem sie Binärdaten in einem git diff gesehen haben, und landen bei Adobe-Ascii85-Werkzeugen mit anderem Alphabet, optionalen less-than-tilde-Hüllen und einem z-Kürzel für Nullenläufe. Gits Dialekt ist bewusst anders: fünfundachtzig feste Symbole ab der Ziffer null, verpflichtende Längenpräfixe pro Zeile, keine Adobe-Begrenzer und kein z-Kompressionstoken. Diese Seite bedient die git-spezifische Suchabsicht—git base85 kodierer, binärpatch base85, git base85 dekodieren—und konkurriert nicht mit einer allgemeinen Ascii85-Seite.

Ein anderer Ablauf fügt nur die Datenzeilen eines GIT binary patch ein (ohne literal-N-Kopf, falls die Größe bekannt ist) und gewinnt Bytes zur Prüfung. Halten Sie Nutzlasten bescheiden—dies ist ein Parse-Element der Stufe A, kein Packfile-Server—und pinnen Sie result-Zeichenketten in Goldens, weil der Algorithmus über Isolate und Sprachen mit derselben Tabelle vollständig deterministisch ist.