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

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

Email 电子邮件主题长度限制是多少？,email,limit,Email,Limit,互联网电子邮件的主题行允许有多少个字符？我做了一次扫描，但看不出具体允许多长时间。我有一位同事希望通过编程验证它如果没有正式的限制，那么实际建议的长度是多少？我不认为这里有正式的限制，而且我很确定RFC中也没有任何硬限制，正如您所发现的那样我认为主题行（不仅仅是电子邮件）的一些常见限制是： 80个字符 128个字符 256个字符很明显，你想提出一些合理的建议。如果您正在编写一个电子邮件客户机，您可能需要使用256个字符，并且显然需要针对大型商业服务器进行彻底测试，以确保它们正确地为

互联网电子邮件的主题行允许有多少个字符？我做了一次扫描，但看不出具体允许多长时间。我有一位同事希望通过编程验证它

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

我不认为这里有正式的限制，而且我很确定RFC中也没有任何硬限制，正如您所发现的那样

我认为主题行（不仅仅是电子邮件）的一些常见限制是：

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

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

希望这有帮助

请参见第2.1.1节开始

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

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

每个标题字段在逻辑上都是一个单行字符，包括字段名、冒号和现场机构。但为了方便起见,，以及处理998/78字符每行限制，字段主体标题字段的一部分可以拆分转换为多行表示；这就是所谓的“折叠”。将军规则是，无论这个标准在哪里允许折叠空白（非空白）仅限WSP字符），CRLF可以是在任何WSP之前插入。对于例如，标题字段：

       Subject: This is a test

可表示为：

       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".?=

致：

如您所见，在主题行中，它以“=”在字符78上剪切，后跟2或3行提要，然后继续使用主题的其余部分

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

若你们并没有ISO，这并没有什么坏处，但若你们把它添加到你们的主题中，好让RFC满意，那个么你们会从OutLook得到这个惊喜。位如果不添加ISOs，则iPhone电子邮件将无法理解它（并且使用此类字符附加文件名在iPhone上不起作用）。

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

但要生成长标题，您需要将其拆分为多行，这是一个称为“折叠”的过程

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

这里有一些引号（[…]表示我省略的内容）

重要的是您使用的是哪种机制来发送电子邮件。大多数现代图书馆（即System.Net.Mail）都会对您隐藏折叠。你只需在邮件主题行中插入一个很长的内容，不带（CR、LF、HTAB）。如果你开始尝试自己折叠，所有的赌注都会被取消。它将开始报告错误。因此，如果您遇到这个问题，只需过滤掉CR、LF、HTAB，让库为您完成工作。通常还可以将编码文本类型设置为单独的字段。主题行中不需要iso编码

没有特别的理由说明为什么256比250、300或372好。我们早已不再使用字节来表示字符串长度。255是某些产品（例如Jira和outlook）的实际限制。这个答案是错误的。当前版本的IMF规范RFC 5322明确定义了最大线长度。请参阅@Michael的答案。+1行长度限制适用于消息的所有行，但我没有看到任何内容表明主题不能跨越多行（这意味着主题的字符数没有限制）。请参见2.2.3和后面的示例。VARCHAR 255可能是MySQL/MariaDB中最常见（且更有效）的数据列长度。字节无疑仍然是相关的。如果长度小于256，MySQL将使用1字节来存储，否则将使用更多字节。看看C++如何实现STD::string，如果你认为字符串长度不是很重要，并且在ByTS.中计数。255是某些售票产品的限制（例如JIRA），并且似乎是Outlook的限制，雷鸟和Gmail在130之后似乎截断。我看到很多批量邮件软件产生无效的RFC2047内容。在数据库中，将不太长或不太短的文本字段的长度定义为VARCHAR（255）或类似的等效名称是非常常见的（可以说是一种传统）。如果显示较长的字符串，则会生成错误，或者干脆将其截断到极限。这就是为什么这里提到的Jira和Outlook不支持更多字符的原因。出于兼容性原因，我不建议在5年生蛋糕上添加一些奶油；）IMF规范的最新版本RFC5322可以在这里找到：这个答案只解决了行长度限制，而不是总长度限制。有RFC，也有可用性。总结为：“关注前40个字符。描述性和书写良好的主题行允许收件人做出明智的决定，以获得更多细节或继续。”为了澄清，su没有长度限制

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.