为什么Python的MIMEMultipart会用新行生成附件文件名？

Question

我正在发送一封带有附件的电子邮件，该附件的文件名很长。为什么它会被新行破坏，系统的哪个部分应该知道这些新行应该被删除？在

from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
from email.mime.application import MIMEApplication
from email.utils import formatdate

msg = MIMEMultipart()
msg['Subject'] = 'subject'
msg['To'] = 'a@example.com'
msg['From'] = 'b@example.com'
msg['Date'] = formatdate(localtime=True)
msg.attach(MIMEText('abc'))

attachment_name = 'abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyz.txt'
part = MIMEApplication("sometext", Name=attachment_name)
part['Content-Disposition'] = 'attachment; filename="%s"' % attachment_name
msg.attach(part)

print msg.as_string()

给我：

^{pr2}$

Answer 1

正如Leon的回答所解释的，Python正在实现RFCs中定义的折叠算法。在

在Python2中，可以使用email.generator.Generator实例来控制最大头长度；from the docs：

For more flexibility, instantiate a Generator instance and use its flatten() method directly. For example:

from cStringIO import StringIO
from email.generator import Generator
fp = StringIO()
g = Generator(fp, mangle_from_=False, maxheaderlen=60)
g.flatten(msg)
text = fp.getvalue()

（将maxheaderlen设置为零将防止在几乎所有情况下折叠长标题行）。在

在python3.5中，maxheaderlen参数在email.message.Message.as_string的signature中公开，因此

print(msg.as_string(maxheaderlen=256))

是可能的。maxheaderlen默认为零，因此除非提供值，否则不会包装头行。在

在Python3.6中，maxheaderlen在email.message.EmailMessage.as_string的signature中公开（注意这是一个不同的类）。maxheaderlen现在默认为None：除非指定值，否则头行换行为78个字符。在

Answer 2

长头字段的处理在section 2.2.3 of RFC 2822 "Internet Message Format"中定义。该部分在过时的RFC 5322中保持不变。在

2.2.3. Long Header Fields

Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field:

Subject: This is a test

can be represented as:

Subject: This
 is a test

Note: Though structured field bodies are defined in such a way that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere.

The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation.