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

Weijun Wang weijun.wang at oracle.com
Fri Jan 18 00:22:19 UTC 2013

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.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