Possible Duplicate:
Why does base64 encoding requires padding if the input length is not divisible by 3?
Quoting Wikipedia:
...these padding characters must then be discarded when decoding but still allow the calculation of the effective length of the unencoded text, when its input binary length would not be a multiple of 3 bytes. ...
But the calculation of length raw data can easily be done even if strip the padding character.
| 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
.
.
.
So given the real encoded size (third column) you can always correctly guess what padded size would be:
PaddedSize = 4 * Ceil (RealSize / 4)
So in theory, there was no need of padding. Algorithm would have handled it. Considering that Base64 encoding is a popular industry standard, it is used in many applications and devices. These would have benefited from reduced encoded size. So question is, why padding is used in Base64 encoding?
It makes the encoded message an integer multiple of 4 characters. This might make writing a decoder slightly easier. You can load and process characters in blocks of 4 and convert them to 3 output characters, and the padding makes it easy to do this without going off the end of the string.
As you note, the end-padding is at most 2 bytes in length regardless of the length of the message, so it's not a really significant saving - more of a micro-optimization. If your application is both the producer and consumer of the encoding, you could strip out the padding, but it's not really worth the hassle.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With