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

[Mark Sheppard]

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