电子邮件标头中的 -- 是什么？答案

【问题标题】：What are -- in email headers?电子邮件标头中的 -- 是什么？
【发布时间】：2015-04-07 12:58:16
【问题描述】：

最近我遇到-- 作为 php 中mail() 函数的标头。我试图用谷歌搜索，但没有找到任何结果，所以我发布了这个问题。在尝试编辑我的代码时，我发现这两个 -- 之后的 id 应该是唯一的。我的 php 脚本发送带有附件的电子邮件。

<?php

$file = "http://wpbrisk.com/download/email/email/doc1.pdf"; // Specify the Url of the attachment here

$filename = "doc1.pdf"; // Specify the name of the file here

$to="hudixt@gmail.com"; // Enter the mail to which you want to sent the attachement
$your_name = "Hudixt"; // Your name
$from_mail = "info@wpbrisk.com"; // Your email

$subject = "This is a mail with attachment."; // Subject
$message = "<div id='hello'>World</div>"; // message

// Get the content of the file
    $content = file_get_contents($file);

    $content = base64_encode($content);
    $uid = md5(uniqid(time()));

    $header = "From: ".$from_name." <".$from_mail.">\r\n";

    $header .= "MIME-Version: 1.0\r\n";
    $header .= "Content-Type: multipart/mixed; boundary=\"".$uid."\"\r\n\r\n";
    $header .= "This is a multi-part message in MIME format.\r\n";
    $header .= "--".$uid."\r\n";


    $header .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";
    $header .= $message."\r\n\r\n";
    $header .= "--".$uid."\r\n";

    $header .= "Content-Type: application/octet-stream; name=\"".$filename."\"\r\n"; // use different content types here

    $header .= "Content-Transfer-Encoding: base64\r\n";
    $header .= "Content-Disposition: attachment; filename=\"".$filename."\"\r\n\r\n";
    $header .= $content."\r\n\r\n";
    $header .= "--".$uid."--";
    mail($mailto, $subject, "", $header);
        ?>

你能告诉我这个--在标题中的含义以及为什么它应该是唯一的。

【问题讨论】：

请发布所有相关代码和您正在谈论的上下文。我想这与 MIME 部分边界有关，对吧？
双破折号是某些格式的注释，可能就是这样
对我来说似乎有些界限
如果我必须做出有根据的猜测，我会说它们是边界。见en.wikipedia.org/wiki/MIME#Multipart_messages
@MrTux 和其他人你能告诉我为什么这些边界应该是独一无二的以及它们需要什么

标签： email header mime

【解决方案1】：

这些“--ID--”行是 MIME 部分边界（请参阅https://en.wikipedia.org/wiki/MIME）。它们在https://www.rfc-editor.org/rfc/rfc2046 中进行了描述。它们用于分隔消息的不同部分。

根据 RFC#2046，只有那些必须是唯一的“足够”。如果您想将一封电子邮件封装到另一封电子邮件中，则边界不能相互推断，即它们必须是不同的。所以最好让它们“尽可能和需要”独一无二：

这意味着作曲代理能够选择并指定一个唯一的边界参数值不包含封闭多部分的边界参数值作为前缀。 (https://www.rfc-editor.org/rfc/rfc2046#section-5.1)

【讨论】：

【解决方案2】：

对我来说似乎是 MIME 边界...

基本上，当您在一封电子邮件中包含多种类型的内容时，不同的部分会使用 ID 进行分隔。然后每个部分前面都有“--”，然后是边界。来自 RFC：

因此，典型的多部分 Content-Type 标头字段可能如下所示：

 Content-Type: multipart/mixed; 
      boundary=gc0p4Jq0M2Yt08jU534c0p

这表明实体由几个部分组成，每个部分本身的结构在语法上与 RFC 822 消息相同，除了标题区域可能完全为空，并且每个部分前面都有一行 --gc0p4Jq0M2Yt08jU534c0p

请参阅http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html 了解更多信息。

回答你的最后一个问题，当你有一封带有文本和附件的电子邮件时，整个邮件将有 Content-Type: multipart/mixed，文本将是 text/plain，附件（假设是一个 word 文件）将是应用程序/msword。每个新的内容类型部分将由 '--' 分隔。 $边界。选择的边界是唯一的，并且与其他消息部分不同，这样它就不会出现在它们中的任何一个中 - 当解释电子邮件内容的应用程序找到 $boundary 时，它必须可以安全地假设这是一个预期的边界而不是只是消息中的侥幸。

希望有帮助！

【讨论】：