[PATCH] mail: encode long unicode lines in emails properly (issue5687)
Igor Ippolitov
iippolitov at gmail.com
Mon Sep 25 15:39:53 UTC 2017
I gave it a thought and seems you are right. The function can be written
down in a better (and shorter) way^
>def mimetextqp(body, subtype, charset):
> '''Return MIME message.
> Quoted-printable transfer encoding will be used if necessary.
> '''
> cs = email.charset.Charset(charset)
> msg = email.Message.Message()
> msg.set_type('text/'+subtype)
>
> for line in body.splitlines():
> if len(line) > 950:
> cs.body_encoding = email.charset.QP
> break
>
> msg.set_payload(body,cs)
>
> return msg
All tests are passed successfully with this change.
Should I submit this as a separate patch?
2017-09-25 18:13 GMT+03:00 Yuya Nishihara <yuya at tcha.org>:
> On Mon, 25 Sep 2017 16:50:33 +0300, Igor Ippolitov wrote:
> > There is a nice small research from Django which states that QP is
> > preferred for UTF8 texts: https://code.djangoproject.com/ticket/22561
> > Base64 is preferred for binary data.
>
> Okay, then we might want to use QP no matter if there is a long line.
>
> > Concerning the "if enc: ... else:" part, I thought you don't have to
> encode
> > long lines on your own. But this is still an issue.
>
> Yeah, there is still a long lines issue, but we've enforce the QP encoding
> in that case. My question is why can't we rely on the email module to
> encode
> the payload according to the specified charset?
>
> if long:
> # don't: body = quopri.encodestring(body)
> cs.body_encoding = QP
> else:
> # use the default body_encoding: None, QP or BASE64
> msg.set_payload(body, cs)
>
> > So this part should be as it is.
> > 'set_charset' call sets correct headers for a letter (not only
> > 'Content-Transfer-Encoding')
> > This call will change payload if no CTE header is set. So for preencoded
> > payload it is called before payload is set. If it is called after - the
> > payload will be double encoded (like it is now for long unicode lines).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170925/0c4853c5/attachment-0002.html>
More information about the Mercurial-devel
mailing list