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

[Xueming Shen]

Hi,

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

Thanks!
-Sherman

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: weijun.wang at oracle.com
> To: core-libs-dev at openjdk.java.net
> 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