Codificador Git Base85

Git guarda los cambios de archivos binarios dentro de diffs unificados con un dialecto Base85 propio, no Adobe Ascii85 ni Base64 simple. Cada línea de datos empieza con una letra de prefijo de longitud—de A a Z para uno a veintiséis bytes decodificados, de a a z para veintisiete a cincuenta y dos—seguida de cinco caracteres del alfabeto por cada cuatro bytes de carga. Quienes inspeccionan secciones GIT binary patch, depuran fallos de apply o construyen herramientas compatibles necesitan un conversor que use exactamente ese alfabeto y esa forma de línea.

Codificar texto o hex en líneas Git Base85

En cada bloque escribe un prefijo de longitud (A significa un byte, B dos, hasta Z para veintiséis, luego a para veintisiete hasta z para cincuenta y dos) y expande cada grupo de cuatro bytes en cinco caracteres del alfabeto de ochenta y cinco símbolos de Git: dígitos, letras mayúsculas y minúsculas, y el conjunto de puntuación que omite comillas, comas, puntos, barras y contrabarras para que los parches sigan siendo amigables para correo y shell.

Un grupo final corto se rellena con ceros para la aritmética y luego se trunca al número correcto de bloques de cinco caracteres, de modo que el decodificador recupera el conteo exacto de bytes solo con el prefijo. Fije format en hex cuando la carga sea binaria en bruto: text debe ser una cadena hexadecimal de longitud par (se permiten espacios y guiones bajos), y esos bytes se codifican sin capa UTF-8. La entrada vacía es válida y produce un resultado vacío con cero bytes y cero líneas.

El camino es aritmética pura—sin red, sin sal aleatoria, sin reloj—así que entradas idénticas siempre producen cuerpos Base85 idénticos para goldens de integración continua.

Decodificar líneas con prefijo de longitud y rechazar entrada inválida

Fije mode en decode y coloque una o más líneas Git Base85 en text. Las líneas en blanco se ignoran para que pueda pegar un fragmento copiado de un parche mayor. Tras el prefijo, el resto debe ser exactamente cinco veces el número de grupos de cuatro bytes necesarios para el conteo declarado—demasiados o demasiados pocos símbolos es un error, no un truncado silencioso.

Cada carácter codificado debe pertenecer al alfabeto de Git; un símbolo tomado de Adobe Ascii85 (por ejemplo un menor-que suelto o un z de corrida de ceros que Git no usa) falla de inmediato para que nunca aplique por error un dialecto ajeno como cuerpo de parche binario. Una decodificación correcta concatena todas las líneas en orden en un único búfer de bytes.

Con format hex el resultado es una cadena hex en minúsculas de los bytes recuperados, la opción práctica cuando la carga es un literal comprimido con zlib de un GIT binary patch real y no texto legible.

En qué se diferencia Git Base85 de Ascii85

A menudo se busca un codificador Base85 tras ver datos binarios en un git diff y se acaba en herramientas Adobe Ascii85 con otro alfabeto, envolturas opcionales less-than-tilde y un atajo z para ceros. El dialecto de Git es deliberadamente distinto: ochenta y cinco símbolos fijos que empiezan en el dígito cero, prefijos de longitud por línea obligatorios, sin delimitadores Adobe y sin token z de compresión.

Esta página atiende esa intención de búsqueda específica de Git—codificador git base85, parche binario base85, decodificar git base85—y no compite con una página Ascii85 general. Otro flujo pega solo las líneas de datos de un GIT binary patch (omitendo la cabecera literal N si ya conoce el tamaño) y recupera bytes para inspección. Mantenga cargas modestas—es un ítem parse de nivel A, no un servidor de packfiles—y fije las cadenas result en goldens porque el algoritmo es totalmente determinista entre aislados e idiomas que implementan la misma tabla.