Converting to quoted printable encoding

[Nicholas Cole]

My naive attempt to convert a MIMEText message part to quoted
printable (having read the documentation) looked something like this:

E = email.mime.text.MIMEText("This is some text")
email.encoders.encode_quopri(E)
print E.as_string()

But it yields a message with two Content-Transfer-Encoding headers.

I'm assuming that this is not a bug - but what is "The Right Way"(TM)
to change the encoding of text?

Best, N
_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Oleg Broytmann-2]

On Wed, Sep 24, 2008 at 08:25:37PM +0100, Nicholas Cole wrote:
> but what is "The Right Way"(TM)
> to change the encoding of text?

   Why not to allow email to choose the best suited encoding? Wel, you may
change the idea of "best" by setting encoders for your charset; this is how
I do it:

Charset.add_charset("koi8-r", Charset.BASE64)

   If you want quted-printable for both headers and body, call

Charset.add_charset("koi8-r", Charset.QP, Charset.QP)

Oleg.
--
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Nicholas Cole]

On Wed, Sep 24, 2008 at 8:37 PM, Oleg Broytmann <phd@...> wrote:
> On Wed, Sep 24, 2008 at 08:25:37PM +0100, Nicholas Cole wrote:
>> but what is "The Right Way"(TM)
>> to change the encoding of text?
>
>   Why not to allow email to choose the best suited encoding? Wel, you may
> change the idea of "best" by setting encoders for your charset; this is how

Because the RFC I am trying to follow specifies a particular encoding. ;-)
_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Nicholas Cole]

On Wed, Sep 24, 2008 at 8:25 PM, Nicholas Cole <nicholas.cole@...> wrote:

> My naive attempt to convert a MIMEText message part to quoted
> printable (having read the documentation) looked something like this:
>
> E = email.mime.text.MIMEText("This is some text")
> email.encoders.encode_quopri(E)
> print E.as_string()
>
> But it yields a message with two Content-Transfer-Encoding headers.
>
> I'm assuming that this is not a bug - but what is "The Right Way"(TM)
> to change the encoding of text?

I can't see that this isn't a bug - in that encode_quopri is (as the
documentation says) adding a header, but not replacing the one that
was there already.

But I am confused.  Doing this results in a truly mangled message,
suggesting that encode_quopri is not as aware of existing encoding as
I thought:

E = email.mime.text.MIMEText("This is some text")
email.encoders.encode_quopri(E)
email.encoders.encode_quopri(E)

So, it looks like I'm going to be better off using the quopri module directly...

Best,

N
_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Mark Sapiro-3]

Nicholas Cole wrote:

>On Wed, Sep 24, 2008 at 8:25 PM, Nicholas Cole <nicholas.cole@...> wrote:
>> My naive attempt to convert a MIMEText message part to quoted
>> printable (having read the documentation) looked something like this:
>>
>> E = email.mime.text.MIMEText("This is some text")
>> email.encoders.encode_quopri(E)
>> print E.as_string()
>>
>> But it yields a message with two Content-Transfer-Encoding headers.


We do

E = email.mime.text.MIMEText("This is some text")
del E.['content-transfer_encoding']
email.encoders.encode_quopri(E)

>> I'm assuming that this is not a bug - but what is "The Right Way"(TM)
>> to change the encoding of text?
>
>I can't see that this isn't a bug - in that encode_quopri is (as the
>documentation says) adding a header, but not replacing the one that
>was there already.
>
>But I am confused.  Doing this results in a truly mangled message,
>suggesting that encode_quopri is not as aware of existing encoding as
>I thought:
>
>E = email.mime.text.MIMEText("This is some text")
>email.encoders.encode_quopri(E)
>email.encoders.encode_quopri(E)

Yes, doubly encoding the payload will result in a payload that has to
be doubly decoded.

I suppose the ideal solution to all of this is that the encoder should
first look at the existing Content-Transfer_Encoding header if any to
see if the payload is already encoded, and if no header, encode and
add the header; if existing header with target encoding, do nothing,
and if existing header with other encoding, decode, encode and replace
the header. However it doesn't work that way.


>So, it looks like I'm going to be better off using the quopri module directly...


Consider this

email.Charset.add_charset('us-ascii', body_enc=email.Charset.QP)
E = email.mime.text.MIMEText("This is some text")
print E.as_string()


--
Mark Sapiro <mark@...>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sep 25, 2008, at 4:30 PM, Mark Sapiro wrote:

> I suppose the ideal solution to all of this is that the encoder should
> first look at the existing Content-Transfer_Encoding header if any to
> see if the payload is already encoded, and if no header, encode and
> add the header; if existing header with target encoding, do nothing,
> and if existing header with other encoding, decode, encode and replace
> the header. However it doesn't work that way.

I think there are lots of opportunities for cleaning up the email  
package API.  I still believe there are fundamental semantic problems  
in the 3.0 version of the package, mostly due to the bytes/unicode  
split.  I really wish I had had time to complete that work, but alas  
we never got around to it at Pycon.

I'd like to jump start the discussion on a next version of the email  
package, one that plays better with Python 3.0 (but would still be  
Python 2.6 and possibly 2.5 compatible).

We should probably begin by enumerating all the things we think are  
wrong with the current email package.  Perhaps we could use the wiki  
on python.org for that.  Thoughts?

If you agree, I'll try to set some things up over there.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSN1L5XEjvBPtnXfVAQJCqAP/cSm6DfgxkZ0TaoMWdFW8/8WfcYqRAH1F
NxvaklfRoy++Hz67HaoMExkWMfAJhg19QYv3WYnH/nofWUtWgB2r5IXXvg4Np3uJ
bdmURV9bkzKhRbRTjzCoVPV6A/4Ftps1sSWC6NS48pDZSPqpyT3D8DtlulFy4bnz
YjzdAeAJG10=
=Sl+Y
-----END PGP SIGNATURE-----
_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com