Thanks. Most files end with a new line and having to trim() it before
decoding would drive me crazy. Also, the old BASE64Decoder ignores it,
so it would be nice to be compatible.
-Max
On 01/18/2013 01:03 AM, Xueming Shen wrote:
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.w...@oracle.com
To: core-libs-dev@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
