Marc Horowitz <[EMAIL PROTECTED]> writes: > "Richard M. Stallman" <[EMAIL PROTECTED]> writes: > >>> I received a piece of email which passed through an older MTA. This >>> MTA inserted a ! and a newline after every 1000 characters of a very >>> long line of base64-encoded data, which used to be common behavior. >>> When Gnus tried to display this email, it failed, because the ! >>> characters were not recognized as valid base64 encoding. >> >>> Maybe I misunderstood what you were asking for. I thought you >>> were asking us to make additional base64-decode-region signal >>> errors in cases where currently it does not. But now it looks >>> like you are asking for it to accept input that now gives >>> an error. > > I'm sorry I was confusing. To quote my earlier email: > > I believe the best fix is for base64-decode-region to take an optional > argument which specifies how liberal it should be about it's input, > defaulting to the current behavior, and for Gnus to use this argument. > > Defaulting to the current behavior should certainly not mean > signalling errors in new cases. You are correct that I'm asking for a > behavior variant which would result in more input being accepted. If > this variant became the default, I would not object, but I would > certainly understand if you did not want to change the default > behavior. > >>> Could you give a self-contained description of the change that you are >>> requesting in the behavior of this function? > > For the purposes of reading mail, it is valuable to ignore all > characters not part of the base64 character set when decoding. So, my > minimum proposal would be for base64-decode-region to ignore all > unknown characters, instead of signalling errors in this case. > > It would be more generally useful to provide three forms of the > base64-decode-region function, either by having three functions, or > one with an optional argument: > > Form 1: all characters not part of the base64 character set would > be ignored. > > Form 2: any character not part of the base64 character set would > cause an error to be signalled. > > Form 3: any character not part of the union of the base64 > character set and the whitespace characters would cause an error > to be signalled. > > Form 3 is the current observed behavior. I believe there is a need > for Form 1, to make mail reading work more smoothly. Form 2 mainly > exists for completeness.
Why can't you just pre-parse the data parsed to the base64 decoder? I believe that's the correct behaviour. A base64 decoder should decode base64, not "base64 but also it does this extra trick if you wave your hand in the air" Nic _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
