5

我正在使用 Zend_Mail 并想自定义发件人姓名。

我希望发件人姓名为FooBar爱你瑞安(其中 'Ryan' 被替换为收件人姓名,而爱你被替换为收件人语言中的 'loves' 的翻译,就像 CD Baby 所做的那样)。

我已经尝试过base64_encodemb_encode_mimeheader()以及其他类似的东西:

mb_internal_encoding('UTF-8');
mb_http_output('UTF-8');
iconv_set_encoding("input_encoding", 'UTF-8');
iconv_set_encoding("output_encoding", 'UTF-8');
iconv_set_encoding("internal_encoding", 'UTF-8'); 
header('Content-Type:text/html; charset=' . 'UTF-8');

它生成这个作为发件人:'=?UTF-8?B?RXh0cmFidXjniLHkvaByY3dhbHNoQGV4dHJhYnV4LmNvbQ==?= <email@example.com>'

然后在我的 Gmail 中显示为(unknown sender).

有任何想法吗?

4

3 回答 3

2

对我来说,唯一有效的解决方案如下:由于您在通常的 php sendmail 案例中设置了 utf8 主题,您可以像这样创建一个带有 utf8 注释的 base64 字符串:

$mail->addFrom($fromEmail, '=?utf-8?B?'.base64_encode($fromName).'?=');

有了这个解决方案,每件事都像魅力一样发挥作用。

于 2015-06-14T10:15:15.043 回答
1

我希望我早点尝试过:当我将中文字符串硬编码为发件人姓名(使用 utf8 字符)时,它工作正常。(我只在 Gmail 中测试过。)

所以我一直走的路是错误的。

我需要弄清楚为什么一个由 utf8 字符组成的动态生成的发件人名称在硬编码的中文字符串起作用时不起作用。但这似乎是一个不同的问题。

于 2013-01-02T21:44:06.940 回答
0

这是一个很好的问题,答案也很好——但是 ZendFramework 先进,并且引用的接口不幸已经过时了。

因此,这是相同的解决方案,但在 2017 年 6 月测试可以正常工作:

private static function ecvt($string)
{
    return mb_convert_encoding($string, 'ISO-2022-JP', 'UTF-8');
}
private static function hcvt($string)
{
    return "=?iso-2022-jp?B?" . base64_encode( self::ecvt($string) ) . "?=";
}
private function sendMail( )
{
    $mail = new Message();

    $content = 'Message body 日本語も';

    $mail->getHeaders()->addHeaderLine('Content-Type', 'text/plain; charset=ISO-2022-JP');

    $mail->setFrom('sender@acme.com', self::hcvt('Sender 日本語も') );
    $mail->addTo('receiver@acme.com', self::hcvt('Receiver 日本語も') );
    $mail->setSubject(self::hcvt('Some subject 日本語も'));

    $mail->setBody( self::ecvt($content) );
    $mail->setEncoding('ISO-2022-JP');

    // this is critical - it works around a bug in zendframework3 where
    // MIME encoding is botched in headers. By switching headers to ASCII,
    // I basically do the encoding myself.
    $mail->getHeaders()->setEncoding('ASCII');

    $this->mailTransport->send( $mail );
}

所有这一切的基础真的在这里 - 很好读,所以你知道发生了什么:RFC2047 https://www.ietf.org/rfc/rfc2047.txt

于 2017-06-01T04:48:54.530 回答