And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())

Xueming Shen xueming.shen at
Thu Jan 17 17:03:46 UTC 2013


Yes,  padding \n (and any non-base64 character) after base64 padding 
'=' probably should be ignored, instead of exception in mime mode. The 
implementation is not consistent now for this case. Will file a cr and 
address this,
probably after M6.


On 1/17/13 7:02 AM, Mark Sheppard wrote:
> Hi Max,
> The fact that the padding characters == and = appear before the
> newline, leads to RFC2045 section 6.8 (pg 25) and how the
> implementation interprets the processing for the pad character in the encoding.
> As per RFC2045 base64 encoding the occurrence of = indicates end of data.
> That is to say, == or = is only used in the final unit of encoding
> at the very end of the encoded data.
> This raises a couple of questions:
> So is it an error if there are data after these explicit "end of data" markers, when they occur?
> should a special case be made for line separators?
> What about ignoring any data after == or = ?
> The javadoc for Base64 Mime Encoder/Decoder alludes to the line separator and characters
> outside the base64 alphabet being ignored during decoding. This in itself can be ambiguously
> interpreted to mean anywhere in the stream, including after an end of data indicator,
> unless specific attention and interpretation is give to RFC2045.
> Consider the fact that
> Base64.getMimeDecoder().decode("AA==B") also throws an exception
> this suggests that the decoder is interpreting data after the
> end of data padding indication as an error.
> Thus, a newline after = or == is reasonable interpreted as an error, suggesting
> that the exception is reasonable.
> It can be noted that Base64.getMimeDecoder().decode("AAAA\n")
> doesn't throw an exception.
> regards
> Mark
> ----- Original Message -----
> From: at
> To: core-libs-dev at
> Sent: Thursday, January 17, 2013 11:09:49 AM GMT +00:00 GMT Britain, Ireland, Portugal
> Subject: And Decoder (was Re: No newline at the end of Base64.getMimeEncoder())
> This time on the decoder side:
>     Base64.getMimeDecoder().decode("AA==\n")
> throws an exception because the string ends with a newline. I would
> prefer it be acceptable.
> Thanks
> Max
> On 01/17/2013 05:12 PM, Weijun Wang wrote:
>> I noticed that the encoding output of Base64.getMimeEncoder() never ends
>> with a newline char. There is no right or wrong on this but it will be
>> nice to write the current behavior into the spec.
>> Thanks
>> Max

More information about the core-libs-dev mailing list