[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: unreadable message
From: |
Adam Sjøgren |
Subject: |
Re: unreadable message |
Date: |
Sat, 08 Nov 2008 13:24:53 +0100 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux) |
On Sat, 08 Nov 2008 16:05:02 +1000, Alexey wrote:
>> What, exactly, seems to be the problem?
> Once the post command (C-c C-c) typed, it may produce garbage.
base64 encoding is part of the MIME specification¹. It can hardly be
classsified as "garbage".
> People, who receive the mail, cannot read it. For instance, a friend
> of mine, who is an ordinary windows user, tried to read it on
> different machines but with no luck. Frequently, when that happens, I
> cannot read it either.
Which programmes did he try? I find it quite hard to believe that any
modern mail-programme does not decode Content-Transfer-Encoding: base64
automatically.
> While you managed to decode that bit, which was actually readable in
> my outgoing mail box but unreadable at my friend's machine, there is
> no guarantee it's always possible to do that easily.
Well, base64 encoding is in the MIME standard, so all mail programmes
that understand MIME _ought_ to be able to decode it.
> Usually, what you get after decoding is a set of numbers with
> backslashes in front of them, which are the unicode character codes,
> as I understand it.
How did you come to this understanding?
> I don't think that manually running base64 decoding is an acceptable
> alternative for a decent MUA.
Of course not. A decent MUA automatically does base64 decoding when
encountering a base64-encode email. Just as it automatically decodes
quoted-printable and handles charsets.
> Unfortunately, the bug is of occasional nature, which means not every
> text causes that to happen. It seems that Gnus/Emacs functions dealing
> with unicode may have this bug.
I am not sure this is a bug in Gnus - from what you have presented so
far, it sounds like lack of MIME support in your friends' programmes.
Gnus chooses the encoding based on what the most efficient encoding is -
this may be why you think it the behaviour is occational, it depends on
t he content:
,----[ C-h v mm-content-transfer-encoding-defaults RET ]
| `mm-content-transfer-encoding-defaults' is a variable declared in Lisp.
| -- loaded from "mm-encode"
|
| Value: (("text/x-patch" 8bit) ("text/.*" qp-or-base64) ("message/rfc822"
8bit) ("application/emacs-lisp" qp-or-base64) ("application/x-emacs-lisp"
qp-or-base64) ("application/x-patch" qp-or-base64) (".*" base64))
|
| Documentation:
| Alist of regexps that match MIME types and their encodings.
| If the encoding is `qp-or-base64', then either quoted-printable
| or base64 will be used, depending on what is more efficient.
|
| `qp-or-base64' has another effect. It will fold long lines so that
| MIME parts may not be broken by MTA. So do `quoted-printable' and
| `base64'.
|
| Note: It affects body encoding only when a part is a raw forwarded
| message (which will be made by `gnus-summary-mail-forward' with the
| arg 2 for example) or is neither the text/* type nor the message/*
| type. Even though in those cases, you can use the `encoding' MML tag
| to specify encoding of non-ASCII MIME parts.
`----
You can change the value of this variable if you don't want Gnus to
choose between quoted-printable and base64 automatically.
Best regards,
Adam
¹ <http://tools.ietf.org/html/rfc2045>
--
"you will enjoy the video." Adam Sjøgren
asjo@koldfront.dk
- Re: unreadable message, Alexey Pustyntsev, 2008/11/08
- Re: unreadable message,
Adam Sjøgren <=
- Re: unreadable message, poppyer, 2008/11/08
- Re: unreadable message, Alexey Pustyntsev, 2008/11/08
- Re: unreadable message, Adam Sjøgren, 2008/11/17
- Re: unreadable message, Alexey Pustyntsev, 2008/11/18
- Re: unreadable message, Alexey Pustyntsev, 2008/11/20
- Re: unreadable message, Adam Sjøgren, 2008/11/21