电子邮件主题长度限制是多少？

227

Internet电子邮件的主题行中允许有多少个字符？我扫描了RFC以获取电子邮件，但没有明确看到允许的时间。我有一个同事想要对其进行编程验证。

如果没有正式的限制，那么在实践中建议的长度是多少？

email limit

— 斯科特·弗格森
source

17

255是对一些售票产品的限制（吉拉为例），似乎是对后市的限制，雷鸟和Gmail似乎截断后130

— reconbot

1

RFC2047更适合验证，我看到许多批量邮件软件会产生无效的RFC2047内容。

— 2014年

3

在数据库中，将长度（不是特别长或短的文本字段）定义为VARCHAR（255）或类似的等效名称是很常见的（您可以说一种传统）。如果提供了更长的字符串，则将产生错误或将其截断到极限。这就是为什么此处提到的Jira和Outlook不支持更多字符的原因。出于兼容性原因，我不建议使用255+，只需在5岁的蛋糕上添加一些奶油即可；）

— Alph.Dev 2014年

195

请参阅RFC 2822第2.1.1节。

此标准对一行中的字符数有两个限制。每行字符不得超过998个字符，并且应不超过78个字符（不包括CRLF）。

如RFC稍后所述，您可以通过将主题折叠在多行上来解决此限制（而不是应该这样做）。

每个头字段在逻辑上都是一行字符，包括字段名称，冒号和字段正文。但是，为了方便起见，并且为了处理每行的998/78字符限制，可以将标头字段的字段正文部分拆分为多行表示；例如，这称为“折叠”。一般规则是，只要此标准允许折叠空白（不仅仅是WSP字符），都可以在任何WSP之前插入CRLF。例如，标头字段：
       Subject: This is a test
可以表示为：
       Subject: This
        is a test

建议主题标题中的字符数不超过78个。没有人愿意滚动查看整个主题行，而重要的事情可能会在右侧被切断。

— 迈克尔·彼得罗塔
source

8

IMF规范的最新版本RFC 5322可在以下位置找到： tools.ietf.org/html/rfc5322#section-2.1.1

— james.garriss 2012年

6

此答案仅解决行长度限制，而不是总长度限制。

— Chalky 2015年

1

有RFC，而且有可用性。Jakob Nielsen的文章电子邮件主题行：吸引读者的5条提示总结为：“着眼于前40个字符。描述性和写得很好的主题行使收件人可以做出明智的决定，以获取更多细节或继续前进。”

— 爱德华·洛佩兹

3

需要说明的是，主题行没有长度限制，因为标准通过将单个标头包装在任意多行上来允许标头长于998字节。推荐使用约80个字符确实是一个合理的建议。如果您正在编写电子邮件客户端，则必须能够处理荒谬的主题，而又不能以可怕的方式破坏，最好是在显示为列表的一部分时被截断。

— thomasrutter

1

...对于其他任何标头字段（例如“发件人”）也是如此。PS，如果您想知道为什么是78而不是80，或者为什么是998而不是1000，这是因为电子邮件标准将CRLF（\ r \ n）指定为分隔符，即两个字节，因此每行1000字节，其中998是标头本身。还要注意，标题的名称以及冒号后的任何空格（例如“ Subject：”）也必须适合该名称。

— thomasrutter

20

RFC2322指出主题标头“没有长度限制”

但是要生成长标头，但您需要将其分成多行，此过程称为“折叠”。

RFC 5322中将该主题定义为“非结构化”

这是一些引号（[...]表示我省略的内容）

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.

— 杰森
source

@jasen您知道折叠工具吗？

— mahdi

任何写得很好的电子邮件库都可以做到这一点。我最喜欢的是c-client

— Jasen

这是正确的答案。问题“实践中的长篇大论”的第二部分完全取决于您的应用程序。如果要保存收到的电子邮件，则必须支持无限长度。

— 罗布

4

经过一些测试：如果您向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".?=

至：

如您所见，在主题行中，它在char 78上用“ =”开头，后接2或3个换行符，然后继续其余主题。

有人从所有使用OutLook的客户那里向我报告了此消息，其他电子邮件客户端可以处理这些问题。

如果您没有使用ISO，它不会受到损害，但是如果将其添加到主题中以使其与RFC兼容，那么OutLook会给您带来惊喜。一点点，如果您不添加ISO，那么iPhone电子邮件将无法理解它（并且使用此类字符附加名称的文件在iPhone上将无法使用）。

— 塞尔吉奥
source

5

您设置的主题有很多问题：1.空格应该用'_'编码。2.'encoded-word'（=？charset？Q / B？data？=）的长度不能超过75个字符（rfc2047）。3rd您不能在行尾使用'='char换行（标题QP编码与正文QP不同）。底线是：这不是Outlook的错。

— Pawel Lesnikowski 2012年

2

我不相信这里有正式的限制，而且我很确定您在RFC中也没有指定任何硬性限制。

我认为一般来说，主题行（不仅仅是电子邮件）有一些很常见的限制：

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

显然，您想提出一个合理的建议。如果您正在编写电子邮件客户端，则可能要使用256个字符，并且显然要针对大型商用服务器进行全面测试，以确保它们正确地为您的邮件提供服务。

希望这可以帮助！

— 埃德·阿尔托弗
source

13

256没有比250或300或372好的原因没有特别的原因。我们早就使用字节作为字符串长度了。

— 2009年

4

255是某些产品的实际限制（例如，Jira和Outlook）

— reconbot 2011年

5

这个答案是错误的。IMF规范的最新版本RFC 5322明确定义了最大行长。请参阅@Michael的答案。

— james.garriss 2012年

2

+1行长限制适用于邮件的所有行，但是我看不到任何内容不能跨越多行主题（这意味着该主题的字符数没有限制）。参见2.2.3和随后的示例。

— Cypher 2014年

1

VARCHAR 255可能是MySQL / MariaDB中最常见（且更有效）的数据列长度。字节肯定是最重要的。如果长度小于256，MySQL将使用1个字节来存储长度，否则大于1。如果您认为字符串长度不是很重要并且以字节为单位，请看一下C ++如何实现std :: string。

— ebyrob

0

重要的是您正在使用哪种机制发送电子邮件。大多数现代库（即System.Net.Mail）都会对您隐藏折页。您只需要输入很长的电子邮件主题行，而无需（CR，LF，HTAB）。如果您开始尝试自己进行折叠，则所有投注都将关闭。它将开始报告错误。因此，如果遇到此问题，只需过滤掉CR，LF，HTAB，然后让库为您完成工作。通常，您还可以将编码文本类型设置为单独的字段。主题行中不需要iso编码。

— 卡里亚托
source