mb_send_mail()

(PHP 4 >= 4.0.6, PHP 5, PHP 7)

发送编码过的邮件

说明

发送邮件。邮件头和内容根据mb_language()设置来转换编码。这是mail()的一个包装器函数，所以详情参见mail()。

参数

被发送到该邮件地址。可通过逗号分隔地址的$to来指定多个收件人。该参数不会被自动编码。

邮件标题。

邮件消息。

String to be inserted at the end of the email header.

This is typically used to add extra headers(From, Cc, and Bcc). Multiple extra headers should be separated with a CRLF(rn). Validate parameter not to be injected unwanted headers by attackers.

When sending mail, the mailmustcontain aFromheader. This can be set with the$additional_headersparameter, or a default can be set inphp.ini.

Failing to do this will result in an error message similar toWarning: mail():"sendmail_from" not set in php.ini or custom "From:" header missing. TheFromheader sets alsoReturn-Pathunder Windows.Note:

If messages are not received, try using a LF(n)only. Some Unix mail transfer agents(most notably » qmail)replace LF by CRLF automatically(which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with » RFC 2822.$additional_parameter

$additional_parameter是一个 MTA 命令行参数。在使用 sendmail 时对设置正确的返回路径头很有帮助。

This parameter is escaped by escapeshellcmd() internally to prevent command execution.escapeshellcmd() prevents command execution, but allows to add addtional parameters. For security reason, this parameter should be validated.

Since escapeshellcmd() is applied automatically, some characters that are allowed as email addresses by internet RFCs cannot be used. Programs that are required to use these characters mail() cannot be used.

The user that the webserver runs as should be added as a trusted user to the sendmail configuration to prevent a 'X-Warning' header from being added to the message when the envelope sender(-f)is set using this method. For sendmail users, this file is/etc/mail/trusted-users.

返回值

成功时返回TRUE，或者在失败时返回FALSE。

参见

• mail()发送邮件
• mb_encode_mimeheader()为 MIME 头编码字符串
• mb_language()设置/获取当前的语言

Make sure that if you're using a form to type in the mail, that your form page has the right encoding, like if I want to send out a japanese email, by filling out a form, the form page needs this in the header:

# self-fix...
I posted "encode_mimeheader" workaround on the day before. But I found that the code depends on platforms. :(
In some platforms, hedders(after the header splited into two or more lines) will appear in the body content.
The cause is that 'there are some platforms where the translation from \n to \r\n is apparently done for you'.
# See the post by "leon at ietsmet dot nl" about mail function (23-Apr-2003).
Now, all you have to do is just changing the glue string from "\r\n " to "\n ".
function encode_mimeheader($str, $indent = 0, $encoding = 'utf-8', $mail_encoding = 'iso-2022-jp')
{
     ..... lefted out (all same).....
 $str = join("\r\n ", $lines); // RFC 2047,822 say newline must be ^\r\n, not only\n
 return $str;
}
should be below in some platform...
function encode_mimeheader($str, $indent = 0, $encoding = 'utf-8', $mail_encoding = 'iso-2022-jp')
{
     ..... lefted out (all same).....
 $str = join("\n ", $lines);
 // Though RFC 2047,822 say newline must be \r\n, not only \n,
 // in my platform, auto replacement will be done (accepts \n and \n\r\n -> \n\n)...
 return $str;
}
# notice: In both code, 1 space after newline is essential (gule str is *not* only "\r\n" nor "\n").
# This space is ignored only between encoded-words.
  c.f. about efficiency
Thinking about efficiency, my encode_mimeheader may have to determine where to split string into lines without mb_encode_mimeheader in the determining loop. But that loop will be repeated only one or a few times and this function will be usually used against not so long string. So, this loss is not critical in most case.
If you use only one encoding, you can easily check ascii or multi-byte char one by one accoding to the definition of the encoding and determining splitting point (this is far faster), but when you have to handle all encoding that is not so easy. At least, I don't want to touch. :p
To accept *any* encoding (encoding name will be passed as argument), you can use this code. This is because I post non-efficient code like this.
# Though I'm not sure whether the code actually work well with all encoding...

If you have problem using mb_send_mail to send utf-8 mails, you have to know the following things (I've spent hours on the net before finding the correct php code) :
- You have to use the mb_encode_mimeheader function on the sender name and on the recipient name (on names, not on emails !).
- Subject and message are automatically encoded.
- Add - at least - the following header :
$headers = "Mime-Version: 1.0\n";
$headers .= "Content-Type: text/plain;charset=UTF-8\n";
$headers .= "From: $sender";
- Last but not least, beware of the internal encoding, which is needed by mb_encode_mimeheader function in order to encode properly. I had to set the internal encoding to UTF-8 in order to make it work properly :
mb_internal_encoding("UTF-8");

As others say, mb_encode_mimeheader() seems to have a bug with JIS(ISO-2022-JP) encording. Token indicating start and end of multibyte char is inserted only before start of encoding and after the all.
We need the tokens at start and end of *all* encoded-text.
# PHP 4.3.2
So, we needs some workaround.
The post by "gordon at kanazawa-gu dot ac dot jp" seems to work well, but it doesn't. JIS nees some special tokens and base64_encode does'nt output them, so the code cannot used.
The post "RE: N03L in Japan", which simply splitting words in eash 10 chars is good enough in most case, there are some problem left. When there are some splited parts starting with ascii chars, 1 additional space will be inserted.
# RFC2047 only say within 76 words, shorter is not bad.
Additionally, thought it is really rare case, when we use "=?charset?" as literal string, we have to escape them.
# Some mailer can actually send this without escape and header will be broken. :(
Now, a little non-smart but maybe more accurate code is below function. I tested only with ISO-2022-JP, only in costomized phpBB2.0.5, only some cases.
As far as my test this code worked well, but I'm not sure.
# $str: source text
# $indent: ex. for "Subject: " header, give 9 and first line will be shorter than 76-1-9=66
# $encoding: source text encoding
# $mail_encoding: $str will be converted into this before base64 encode
function encode_mimeheader($str, $indent = 0, $encoding = 'utf-8', $mail_encoding = 'iso-2022-jp')
{
 $start_delimiter = strtoupper("=?$mail_encoding?B?");
 $start_pattern  = strtoupper("=\\?$mail_encoding\\?B\\?");
 $end_delimiter  = '?=';
 $str = mb_convert_encoding($str, $mail_encoding, $encoding);
 $length = mb_strlen($str, $mail_encoding);
 $max_part_length = 20; // enough short in most case (you can change this default value)
  
 for ($i=0, $index=0; $index

I have to use Japanese hankaku (single byte kana in (S)JIS) in mail subject and message,
so I tried the way that NO3L in Japan said, but I found there's a big problem.
In that way, mb_encode_mimeheader drop escape sequence from the head of encoded string from second line.
if you use long letter in subject, and if it includes multi byte string, It must crashed.
Therefore, if you want to use Japanese hankaku in mail subject, you might try like this.
Encoded subject letters in one line is not just 76 letters, so it is not based on RFC, but it work.
$intSubjectLength = mb_strlen($strSubject);
$intSeparateLength = 10;
for ($i=0; $i

鹏仔微信 15129739599 鹏仔QQ344225443 鹏仔前端 pjxi.com 共享博客 sharedbk.com