¿Por qué el relleno se usa en la codificación Base64?

Question

Duplicar posible:
Why does base64 encoding requires padding if the input length is not divisible by 3?

Citando Wikipedia:

... estos caracteres de relleno debe entonces ser desechada cuando se decodifica pero aún permite el cálculo de la efectiva longitud del texto no codificado, cuando es longitud binaria de entrada no sería un múltiple de 3 bytes. ...

Pero el cálculo de los datos sin procesar de la longitud se puede realizar fácilmente aunque se elimine el carácter de relleno.

  |    Encoded 
      |-------------------------------------- 
Raw Size | Total Size | Real Size | Padding Size 
1   | 4   | 2   | 2 
2   | 4   | 3   | 1 
3   | 4   | 4   | 0 
4   | 8   | 6   | 2 
5   | 8   | 7   | 1 
6   | 8   | 8   | 0 
7   | 12   | 10  | 2 
8   | 12   | 11  | 1 
9   | 12   | 12  | 0 
10  | 16   | 14  | 2 
. 
. 
. 

Así que, dado el tamaño real, codificado (tercera columna) siempre se puede adivinar correctamente lo acolchado tamaño sería:

PaddedSize = 4 * Ceil (RealSize/4) 

tanto, en teoría, no había necesidad de relleno. Algoritmo lo habría manejado. Teniendo en cuenta que la codificación Base64 es un estándar popular de la industria, se usa en muchas aplicaciones y dispositivos. Estos se habrían beneficiado de un tamaño codificado reducido. Entonces la pregunta es, ¿por qué el relleno se usa en la codificación Base64?

Answer 1

Hace que el mensaje codificado sea un número entero de 4 caracteres. Esto podría hacer que escribir un decodificador sea un poco más fácil. Puede cargar y procesar caracteres en bloques de 4 y convertirlos en 3 caracteres de salida, y el relleno hace que sea fácil hacerlo sin salir del final de la cadena.

Answer 2

Como observa, el relleno final tiene un máximo de 2 bytes de longitud, independientemente de la longitud del mensaje, por lo que no es un ahorro realmente significativo, sino más bien una microoptimización. Si su aplicación es tanto el productor como el consumidor de la codificación, podría quitar el relleno, pero realmente no vale la pena.

Answer 3

Base64 es antiguo y viene de días en los que había límites en la RAM y la CPU disponibles. También el software de escritura era más complejo (los kits de herramientas y SDK de hoy son más más fáciles de usar en comparación con los 80 o 90) y Base64 tuvo que ejecutarse en muchas arquitecturas de sistema diferentes.

Dicho esto, el desarrollador podría suponer que los datos "reales", después de decodificar los datos de Base64, serían aproximadamente n bytes de longitud; lo que a su vez le permitió a él/ella hacer una mejor gestión de la memoria.

Hoy ya no importa, pero en los días en que los recursos eran limitados, esto era algo bueno.

Actualización: Nunca pensé que obtendría un voto negativo después de 5 años, pero ahora puedo ver el problema con mi respuesta. Supongo que todos envejecemos. ;) Estimados visitantes, disfruten esta respuesta con un grano de sal.