RFR 8025003: Base64 should be less strict with padding
bill.shannon at oracle.com
Fri Nov 8 22:35:03 UTC 2013
Have you had a chance to think about this? Can the MIME decoder be made
more lenient, or can I get an option to control this?
Bill Shannon wrote on 10/25/13 15:24:
> Xueming Shen wrote on 10/25/13 15:19:
>> On 10/25/13 2:19 PM, Bill Shannon wrote:
>>> If I understand this correctly, this proposes to remove the "lenient"
>>> option we've been discussing and just make it always lenient. Is that
>> Yes. Only for the mime type though.
> That's fine.
>>> Unfortunately, from what you say below, it's still not lenient enough.
>>> I'd really like a version that never, ever, for any reason, throws an
>>> exception. Yes, that means when you only get a final 6 bits of data
>>> you have to make an assumption about what was intended, probably padding
>>> it with zeros to 8 bits.
>> This is something I'm hesitated to do. I can be lenient for the padding end
>> because the
>> padding character itself is not the real "data", whether or not it's present,
>> it's missing or
>> it's incorrect/incomplete, it does not impact the integrity of the data. But to
>> feed the last
>> 6 bits with zero, is really kinda of guessing, NOT decoding.
> I understand. And if the people who write spamming software knew how to
> read a spec, we wouldn't have this problem! :-)
> Still, there's a lot of bad data out there on the internet, and people
> want the software to do the best job it can to interpret the data. It's
> better to guess at the missing 2 bits of data than to lose the last 6 bits
> of data.
More information about the core-libs-dev