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

Xueming Shen xueming.shen at oracle.com
Thu Jan 17 17:13:21 UTC 2013

JDK-8006530 (including the request of explicitly documenting the no \n at end behavior)

-Sherman

On 1/17/13 9: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.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

More information about the core-libs-dev mailing list