On 20 March 2013 08:26, Simone Tripodi <simonetrip...@apache.org> wrote: > priceless!!! > >> At present it treats an embedded PAD as the end of input (as per >> Codec) but maybe it would be better to only allow 1 or 2 PADs at the >> end? > > IMHO having such behaviour is acceptable, but if it doesn't cost you > too much, having the behaviour described in Wikipedia[1] is a 'nice to > have':
As far as I know, it already behaves as per the article, except I have just noticed that RFC2045 requires invalid characters to be ignored. That should be trivial to fix now that the code has been re-organised. The article does not describe how to handle embedded PADs > +-----------------------------------------------------------+ > Decoding Base64 with padding > When decoding Base64 text, 4 characters are typically converted back > to 3 bytes. The only exceptions are when padding characters exist. A > single '=' indicates that the 4 characters will decode to only 2 > bytes, while 2 '='s indicates that the 4 characters will decode to > only a single byte. This example illustrates: > Encoded text ends with: YW55IGNhcm5hbCBwbGVhcw== Block with 2 '='s > decodes to 1 character: any carnal pleas > Encoded text ends with: YW55IGNhcm5hbCBwbGVhc3U= Block with 1 '=' > decodes to 2 characters: any carnal pleasu > Encoded text ends with: YW55IGNhcm5hbCBwbGVhc3Vy Block with 0 '='s > decodes to 3 characters: any carnal pleasur > +-----------------------------------------------------------+ > > Thanks! > -Simo > > [1] http://en.wikipedia.org/wiki/Base64 > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org