RFC2322声明主题头“没有长度限制”

但是要产生长标题，你需要把它分成多行，这个过程叫做“折叠”。

在RFC 5322中，subject被定义为“非结构化”

这里有一些引用……指出我遗漏的东西)

3.6.5. Informational Fields
  The informational fields are all optional.  The "Subject:" and
  "Comments:" fields are unstructured fields as defined in section
  2.2.1, [...]

2.2.1. Unstructured Header Field Bodies
  Some field bodies in this specification are defined simply as
  "unstructured" (which is specified in section 3.2.5 as any printable
  US-ASCII characters plus white space characters) with no further
  restrictions.  These are referred to as unstructured field bodies.
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

2.2.3  [...]  An unfolded header field has no length restriction and
  therefore may be indeterminately long.

RFC2322声明主题头“没有长度限制”

但是要产生长标题，你需要把它分成多行，这个过程叫做“折叠”。

在RFC 5322中，subject被定义为“非结构化”

这里有一些引用……指出我遗漏的东西)

3.6.5. Informational Fields
  The informational fields are all optional.  The "Subject:" and
  "Comments:" fields are unstructured fields as defined in section
  2.2.1, [...]

2.2.1. Unstructured Header Field Bodies
  Some field bodies in this specification are defined simply as
  "unstructured" (which is specified in section 3.2.5 as any printable
  US-ASCII characters plus white space characters) with no further
  restrictions.  These are referred to as unstructured field bodies.
  Semantically, unstructured field bodies are simply to be treated as a
  single line of characters with no further processing (except for
  "folding" and "unfolding" as described in section 2.2.3).

2.2.3  [...]  An unfolded header field has no length restriction and
  therefore may be indeterminately long.

我不相信这里有一个正式的限制，而且我非常确定在RFC中也没有任何硬性限制，正如你所发现的那样。

我认为一般来说(不仅仅是电子邮件)主题行的一些非常常见的限制是:

80个字符 128个字符 256个字符

显然，你想要想出一些合理的东西。如果您正在编写电子邮件客户端，您可能希望使用256个字符，并且显然要彻底测试大型商业服务器，以确保它们正确地处理您的邮件。

希望这能有所帮助!

What's important is which mechanism you are using the send the email. Most modern libraries (i.e. System.Net.Mail) will hide the folding from you. You just put a very long email subject line in without (CR,LF,HTAB). If you start trying to do your own folding all bets are off. It will start reporting errors. So if you are having this issue just filter out the CR,LF,HTAB and let the library do the work for you. You can usually also set the encoding text type as a separate field. No need for iso encoding in the subject line.

请参见RFC 2822第2.1.1节开始。

有两个限制 标准名额上有多少 一行中的字符。每一行 字符不能超过998 字符，并且不应该超过 78个字符，不包括CRLF。

正如RFC后面所说，您可以通过将主题折叠到多行来绕过这个限制(并不是说您应该这样做)。

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

主题标题不超过78个字符的建议听起来很合理。没有人想要滚动查看整个主题行，重要的内容可能会在右侧被切断。

如果你向outlook客户端发送电子邮件，主题是>77个字符，它需要使用“=?”在主题内部ISO”(在我的情况下，因为重音)，然后OutLook将“切割”主题在它的中间，并网格它之后的所有内容，包括正文，附件等…全都是网状的!

我有几个类似的例子:

Subject: =?ISO-8859-1?Q?Actas de la obra N=BA.20100154 (Expediente N=BA.20100182) "NUEVA RED FERROVIARIA.=

TRAMO=20BEASAIN=20OESTE(Pedido=20PC10/00123-125),=20BEASAIN".?=

To:

正如你所看到的，在主题行中，它在78号字符上用“=”截断，后面跟着2或3行换行，然后糟糕地继续其余的主题。

有几个客户向我报告说，他们都在使用OutLook，其他电子邮件客户端可以处理这些问题。

如果你在它上面没有ISO，这也没什么，但是如果你把它添加到你的主题以更好地满足RFC，那么你会从OutLook中得到这个惊喜。如果你不添加iso，那么iPhone的电子邮件将无法理解它(并且使用此类字符的附加文件将无法在iPhone上运行)。