互联网电子邮件的主题行中允许有多少个字符？ 我对The RFC for email 进行了扫描，但无法具体看到它被允许多长时间。 我有一位同事想以编程方式对其进行验证。
如果没有正式的限制，在实践中建议的长度是多少？
【问题讨论】：
请参阅RFC 2822，第 2.1.1 节开始。
这有两个限制 标准名额 一行中的字符。每一行 字符数不得超过 998 字符，并且应该不超过 78 个字符，不包括 CRLF。
正如 RFC 稍后所述，您可以通过将主题折叠成多行来解决此限制（不是您应该这样做的）。
每个标题字段在逻辑上都是 单行字符包括 字段名称、冒号和 场体。不过为了方便， 并处理 998/78 字符 每行限制，字段正文 标题字段的一部分可以拆分 成多行表示； 这称为“折叠”。一般 规则是，无论这个标准 允许折叠空白（不 只是 WSP 字符），一个 CRLF 可能是 在任何 WSP 之前插入。为了 比如头域：
Subject: This is a test可以表示为：
Subject: This is a test
主题标题中不超过 78 个字符的建议听起来很合理。没有人愿意滚动查看整个主题行，并且某些重要的内容可能会在右侧被截断。
【讨论】：
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.
【讨论】：
c-client
经过一些测试：如果您向 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 上不起作用）。
【讨论】：
我不认为这里有正式的限制，而且我很确定 RFC 中也没有任何硬性限制，正如你所发现的那样。
我认为一般主题行（不仅仅是电子邮件）的一些非常常见的限制是：
显然，您想提出一些合理的建议。如果您正在编写电子邮件客户端，您可能希望使用 256 个字符之类的内容，并且显然要针对那里的大型商业服务器进行彻底测试，以确保它们正确地为您的邮件提供服务。
希望这会有所帮助！
【讨论】：
虽然 RFC5322 定义了 1000 (998 + CRLF) 个字符的限制，但它是在仅限 ASCII 字符的标头上下文中这样做的。
RFC 6532 解释了如何处理多字节 Unicode 字符。
第 3.4 节（对行长限制的影响）指出：
[RFC5322] 的第 2.1.1 节将行数限制为 998 个字符，并且 建议将行限制为仅 78 个字符。这 规范将以前的限制更改为 998 个八位字节。 （注意，在 ASCII、八位字节和字符实际上是相同的，但这是 在 UTF-8 中不正确。） 78 个字符的限制仍以术语定义 字符，而不是八位字节，因为它旨在解决显示 宽度问题，而不是行长问题。
例如，由于您被限制为 998 个八位字节，因此您的主题行中不能有 998 个笑脸，因为这种类型的每个表情符号都是 4 个八位字节。
为交互式终端运行 php -a。
// Multi-byte string length:
var_export(mb_strlen("\u{0001F602}",'UTF-8'));
// 1
// ASCII string length:
var_export(strlen("\u{0001F602}"));
// 4
// ASCII substring of four octet character:
var_export(substr("\u{0001F602}",0,4));
// '?'
// ASCI substring of four octet character truncated to 3 octets, mutating character:
var_export(substr("\u{0001F602}",0,3));
// '▒'
【讨论】：
重要的是您使用哪种机制发送电子邮件。大多数现代库（即 System.Net.Mail）都会对您隐藏折叠。您只需在没有 (CR,LF,HTAB) 的情况下输入很长的电子邮件主题行。如果你开始尝试自己弃牌，所有的赌注都将被取消。它将开始报告错误。因此，如果您遇到此问题，只需过滤掉 CR、LF、HTAB 并让库为您完成工作。您通常还可以将编码文本类型设置为单独的字段。无需在主题行中进行 iso 编码。
【讨论】：