Hi,
The current spec and implementation of Base64 decoder [1] is standard/rfc
based, in which it interprets/decodes the ending padding character(s) correctly
if present. The ending padding character(s) is not requested (liberal), but if
present, the spec and implementation requests they MUST be encoded correctly,
any incorrect padding combination at the final unit (as listed below) is treated
as incorrect encoded base64 data and results in exception.
Patterns of possible incorrectly encoded padding final base64 unit are:
xxxx = unnecessary padding character at the end of encoded stream
xxxx xx= missing the last padding character
xxxx xx=y missing the last padding character, instead having a
non-padding char
The feedback we got so far suggests that "incorrectly encoded padding unit"
might might be frequently observed in real world use scenario, especially in the
MIME/email world, it might be desired to just accept these incorrectly encoded
ending unit and decode the rest successfully without throwing an exception.
It is also suggested it might be more appropriate to rename
Base64.getEncoder(int lineLength, byte[] sept)
to be
Base64.getMimeEncoder(int, byte[]).
The proposed changes here are to
(1) rename the factory method for the customizable "mime" encoder to
Base.getMimeEncoder(int, byte[]);
(2) change the spec/implementation for the "mime" decoder to be lenient when
handing the padding character in the final unit (mime decoder itself is
"lenient"
already. Its spec requests any non-base64 character during encoding. And our
existing decoder is liberal when there is no padding present at all)
Here is the webrev
http://cr.openjdk.java.net/~sherman/8025003/webrev/
thanks!
-Sherman
Btw, updated mime decoder stilll throws exception for pattern like "xxxx x=..."
or
"xxxx x", in which the last unit only has one valid "byte"/6-bit data.
It's not sufficient to be decoded into a valid 8-bit/byte data.
