emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: base64 behavior is not MIME compliant


From: Arne Jørgensen
Subject: Re: base64 behavior is not MIME compliant
Date: Wed, 06 Jul 2005 00:52:52 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/22.0.50 (gnu/linux)

Marc Horowitz <address@hidden> writes:

> "Richard M. Stallman" <address@hidden> writes:
>
>>> Is there some situation in which the current behavior of
>>> base64-decode-region causes an actual problem or confusion for users?
>
> I never would have noticed this had it not caused me a problem.
>
> 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.

MIME puts a limit on the line length at 76 characters. So in most
cases this will in it self be a broken behavior. (Base64 can probably
be used outside MIME too, of course).

>>> Is there some situation in which the current behavior provides an
>>> advantage?
>
> The only case I can think of is if a program or the user tries to
> base64 decode something which is not base64 encoded, they will receive
> an error, instead of some other, possibly confusing behavior.
> However, I believe this case is less common than non-transparent MTAs
> making small changes to base64-encded data.

I actually wrote some code for No Gnus recently that depended on
base64-decode-string to throw an error on strings that where not
base64 encoded.

Then it turned out that XEmacs' implementation of
base64-decode-region/base64-decode-string _does_ ignore illegal
characters in the base64 encoding.

The problem is that we have no other way to detect if a region/string
is base64 encoded or not. I thought about doing a decode and then
encode and compare the before and after string, but I finally found
another to recognize the data (it was a PEM encoded X509 certificate
and should therefore begin with "MII").

>>> Also, how does the current development Emacs handle these things?
>>> Your report is based on 21.4; the current sources may be different.
>
> I do not know.

I think the behavior is unchanged.

Kind regards,
-- 
Arne Jørgensen <http://arnested.dk/>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]