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