7

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?

Community
  • 1
  • 1
Hemant
  • 19,486
  • 24
  • 91
  • 127
  • @Ignacio: That question is not very good at explaining *why*, though. – BastiBen Dec 01 '10 at 08:44
  • I thought some duplication was allowed (http://blog.stackoverflow.com/2010/11/dr-strangedupe-or-how-i-learned-to-stop-worrying-and-love-duplication/) as long as enough information was put in the question and it was asked with different perspective. – Hemant Dec 01 '10 at 09:13

3 Answers3

7

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.

Angus
  • 1,350
  • 10
  • 15
  • 1
    As mentioned in question, you can calculated the number of padding character just by the size of real encoded data. You can append therefore append it if you want before processing it. There is no need to actually transmit them over the wire! – Hemant Dec 01 '10 at 08:48
  • 3
    The cost of transmitting them over the wire is very small (at most 2 bytes per message). I guess the designers thought that making it simpler (by making the encoded message a sequence of 4-byte blocks, rather than having a variable-length block at the end) was more important than making it slightly more efficient. If you were concerned about bandwidth you wouldn't design a system to use base64 anyway. – Angus Dec 01 '10 at 08:56
  • Hmmm... I do tend to agree with simplicity part! Its just that I assumed there would be a technical *need* of padding... – Hemant Dec 01 '10 at 09:05
  • @Hemant if padding is not mandatory, you take away the *possibility* for basic error detection – Rowland Shaw Dec 01 '10 at 09:36
1

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.

Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
0

Base64 is old and comes from days where there were limits on available RAM and CPU. Also writing software was more complex (today's SDKs and toolkits are much more user-friendly compared to the 80s or 90s) and Base64 had to run on many different system architectures.

That said, the developer could assume that the "real" data, after decoding the Base64 data, would be approximately n bytes long; which in turn allowed him/her to do better memory management.

Today it doesn't really matter anymore, but back in the day where resources were limited, this was a good thing.

Update: Never thought I'd get a downvote after 5 years, but now I can see the problem with my answer. I guess we all get older. ;) Dear visitors, enjoy this answer with a grain of salt.

BastiBen
  • 19,679
  • 11
  • 56
  • 86
  • Calculating the decoded data size (first column) is *very* easy using read encoded data (third column): `firstColumn = thirdColumn * 3 / 4` (Assume `firstColumn` and `thirdColumn` integer variables. Seems like simple integer arithmetic that can be done on *any* platform)! – Hemant Dec 01 '10 at 08:55