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

[Weijun Wang]

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
>