Herramientas de desarrollo · Codificador y decodificador Base64
Explicación del relleno Base64: qué significan los signos = y cuándo son necesarios
· Cómo funciona
base64 codificación flujo de trabajo del desarrollador
El = al final de una cadena Base64 no es decoración: registra cuántos bytes le faltaron al último grupo. Esta publicación explica la aritmética, por qué algunas cadenas no tienen ninguna y por qué los decodificadores no están de acuerdo sobre la falta de relleno.
La excepción de 'relleno incorrecto' de un token que se veía bien: una decodificación fallida y uno o dos caracteres faltantes detrás de él
Cuando un decodificador Base64 informa un relleno incorrecto, la cadena parece completa pero conlleva un error estructural. Los signos iguales no son cosméticos: cada uno codifica cuántos bytes le faltan al grupo final, lo que permite al decodificador saber exactamente cuándo terminaron los datos reales. Comprender esos signos = (y por qué los decodificadores estrictos rechazan cadenas sin ellos) transforma un error misterioso en aritmética predecible. Un segmento JWT puede tener un =, ninguno o dos. Una respuesta API podría terminar limpiamente sin relleno.
Representan elecciones intencionales, no variantes de implementación. El proceso de decodificación no requiere relleno mecánico. El relleno existe para que la salida sea inequívoca: dada solo una cadena Base64 sin metadatos sobre la longitud, el decodificador lee el relleno y sabe exactamente dónde terminan los datos. Base64 codifica grupos de tres bytes en cuatro caracteres. Tres bytes son 24 bits, que se reagrupan perfectamente en cuatro índices de 6 bits; cada uno elige uno de los 64 símbolos Base64. Cuando la entrada no es múltiplo de tres, el codificador se enfrenta a restos: uno o dos bytes no pueden dividirse uniformemente entre tres.
Grupos de tres bytes, bloques de cuatro caracteres: por qué el módulo de longitud de entrada 3 decide si aparecen cero, uno o dos signos =
El codificador rellena esos grupos cambiando los bits a los primeros índices, dejando los finales en cero. Para marcar esta intencionalidad, agrega el signo =: cero para grupos completos, uno para finales de dos bytes, dos para finales de un byte. La aritmética es determinista: conocer la longitud de entrada en bytes le permite calcular el relleno inmediatamente. Un byte produce dos caracteres Base64 más dos =. Dos bytes producen tres caracteres más uno =. Tres bytes producen cuatro sin relleno.
Cualquier entrada que no sea múltiplo de tres bytes tendrá relleno; cualquiera que sea múltiplo no lo será. Esto no es elección: es aritmética. Una cadena sin relleno debe representar tres bytes. Una cadena con uno igual debe representar dos. El relleno codifica la longitud de entrada módulo tres. Examine la transformación de tres entradas: a simple, par ab, triple abc. ASCII a es el byte 0x61; Base64 lo codifica como 0x61 00 00, reagrupándolo en grupos de seis bits.
Qué contienen los bits de relleno y por qué un decodificador estricto los verifica: los bits que deben ser cero y qué significa la codificación canónica
Los índices 24, 4, 0, 0 se asignan a Y, E, A, A. Debido a que dos grupos estaban rellenos, el codificador agrega dos signos =, lo que produce YQ==. Para ab, los bytes 0x61 0x62 se convierten en 0x61 0x62 00. Los bits se reagrupan en los índices 24, 22, 8, 0, salida YWI=. Para abc, los bytes se reagrupan en los índices 24, 22, 9, 35 y generan YWJj sin relleno. El relleno no es arbitrario: se sale del diseño de bits. Cuando decodifica una cadena Base64, el decodificador lee cada carácter, busca su índice de seis bits y empaqueta bits en bytes.
Para YQ==, los caracteres Y, E, A, A se descomprimen en bits. La reagrupación en bytes de ocho bits da un byte, 0x61. El decodificador descarta los bits de relleno (ceros finales) e informa un byte. Un decodificador estricto verifica que los bits de relleno sean realmente cero; de lo contrario, la entrada no era canónica, lo que significa que alguien codificó usando un diseño de bits diferente y la decodificación es ambigua. Los sistemas que omiten por completo el relleno hacen concesiones deliberadas. Los segmentos JWT usan Base64url sin relleno, dependiendo de que los consumidores conozcan la longitud de salida esperada o la infieran.
Ejemplo resuelto: codificación manual de 'a', 'ab' y 'abc': tres entradas, tres resultados de relleno, mostrados bit a bit
RFC 4648 permite el relleno ausente pero indica a los decodificadores que lo acepten si está presente. Las bibliotecas de códigos difieren: algunas restaurarán el relleno faltante y continuarán; otros fracasarán. Cuando encuentra tokens que no se pueden decodificar, agregar el número correcto de signos = a menudo soluciona el problema. Los signos requeridos = son siempre cero, uno o dos, dependiendo de la longitud de la cadena, módulo cuatro. Si la longitud de una cadena Base64 no es múltiplo de cuatro, definitivamente falta relleno o está dañado.
Una longitud de 5 no puede ser Base64 válida: cada carácter completo codifica seis bits, por lo que cuatro caracteres codifican 24 bits (tres bytes) y cinco codifican 30 bits, que no es múltiplo de ocho y no puede convertirse en bytes. El decodificador debe rechazar esto o agregar relleno. Si la longitud es 2 módulo 4, agregue dos =. Si 3 módulo 4, agregue uno =. Si 0 módulo 4, no agregue ninguno. Una cadena de longitud 3 carece de su = que necesita; agregue uno y será válido antes de decodificar.
Por qué algunos sistemas eliminan el relleno por completo: JWT segmentos y tokens seguros para URL que omiten = y cómo restaurarlo desde la longitud
La concatenación de dos cadenas Base64 acolchadas se rompe si el relleno se deja en su lugar. Dos codificaciones separadas unidas directamente producen caracteres de relleno perdidos que rompen el alfabeto de decodificación. Esta es la razón por la que algunos sistemas eliminan el relleno antes de concatenar: un token compuesto por tres segmentos Base64url unidos por puntos no tiene relleno dentro de los segmentos, lo que hace que la concatenación sea sencilla. Si crea un valor Base64 a partir de piezas, verifique si cada pieza está rellena y retire o agregue relleno de manera consistente antes de cualquier operación.
El codificador y decodificador Base64 aplica RFC 4648, que requiere relleno de forma predeterminada. Cuando ingresa texto y solicita salida base64, la herramienta produce un resultado acolchado: la forma canónica. Si ve Base64 sin relleno y desea decodificarlo, verifique si su decodificador acepta el relleno faltante. La herramienta acepta entradas rellenadas y no rellenadas y recupera correctamente los bytes originales. Para la depuración, contar el módulo de longitud cuatro le indica si se eliminó el relleno y la fórmula indica qué relleno debe estar presente.
Errores comunes: recortar = como si fuera un espacio en blanco o concatenar dos cadenas rellenas: cómo cada una corrompe la decodificación
Base32 y Base16 (hexadecimal) tienen diferentes reglas de relleno definidas en las secciones 6 y 7 del RFC 4648. Base32 usa = pero el grupo final puede ser 2, 4, 5, 7 o 8 caracteres dependiendo de la longitud de entrada del módulo cinco. El hexadecimal no requiere relleno; siempre asigna un byte a dos caracteres sin resto. El ajuste MIME Base64 toca el relleno: una cadena envuelta en una columna 76 todavía tiene relleno al final, solo varias líneas después.
Comprender el relleno para Base64 implica comprender el diseño de bits y la longitud de entrada módulo tres; Una vez que entiendes la aritmética, el relleno se convierte en una consecuencia directa, no en una regla para memorizar. El relleno es derivable, no mágico.
Lo que esto no cubre: reglas de relleno base32 y base16, y convenciones de longitud de línea MIME
Dada una cadena Base64 de cualquier longitud, puede restaurar la forma canónica rellena dividiendo el número de caracteres por cuatro, tomando el resto y agregando el número correspondiente de signos =. Esta es la razón por la cual falta = se puede arreglar y por qué los decodificadores estrictos pueden ser indulgentes: el relleno transporta información (en qué rama de tres casos cayó su entrada), pero esa información se puede calcular solo a partir de la longitud.
El codificador y decodificador Base64 muestra una salida rellenada inmediatamente para que pueda comparar los bytes decodificados con el texto original y verificar que el recorrido de ida y vuelta funcionó. Base64 y codificaciones relacionadas amplían el principio de reagrupar bits en diferentes anchos de caracteres. RFC 4648 especifica los tres, y comprender uno hace que los demás sean conceptualmente simples. La idea clave es que la codificación es pura manipulación de bits: elija el tamaño del alfabeto, agrupe los bits en consecuencia, busque cada grupo en una tabla.
Conclusión: el relleno se puede derivar, por lo que un = faltante se puede corregir: cómo el codificador y descodificador Base64 le muestra la forma canónica rellena de cualquier texto que codifique
La decodificación se invierte: busca cada carácter, extrae bits, los reagrupa, escribe bytes. Este mapeo bidireccional determinista es la razón por la cual Base64 funciona de manera confiable en todas las plataformas e idiomas. Los errores en la codificación y decodificación a menudo se deben a malentendidos en el relleno o diferencias alfabéticas. Si la decodificación falla con errores de relleno, verifique si el decodificador espera Base64 canónico (estrictamente acolchado) o acepta variantes. Si falla con errores de caracteres, verifique si la entrada es base64url y el decodificador espera Base64 estándar.
El codificador y decodificador Base64 acepta ambos alfabetos y valida el relleno de manera consistente, por lo que cualquier ejemplo calculado manualmente se puede verificar al instante. Probar la codificación decodificandola es la forma más segura de detectar errores antes de que causen problemas de producción.