Request #12411 :: Support RFC 2047 standard for non-ascii characters as attachment filename.

Package home | Report new bug | New search | Development Roadmap

Status: Open | Feedback | All | Closed Since Version 1.8.7

Request #12411	Support RFC 2047 standard for non-ascii characters as attachment filename.
Submitted:	2007-11-09 02:58 UTC	Modified:	2010-01-01 14:11 UTC
From:	bmdevelopment	Assigned:	alec
Status:	Closed	Package:	Mail_Mime (version 1.5.2)
PHP Version:	5.2.4	OS:	FreeBSD 6.2-RELEASE #0
Roadmaps:	1.6.0RC1
Subscription	Your email:

Comments Patches (5) Add Comment Add patch

[2007-11-09 02:58 UTC] bmdevelopment (Bm Development)

Description:
------------
Currently when you attach a filename with non-ascii characters, such as Japanese, the name of the file itself is encoded according to the format in RFC 2231. This is the newer preferred format and works with email clients such as Thunderbird. However, email clients, such as Outlook and Outlook Express, do not support the newer RFC 2231, but only the older, deprecated RFC 2047.

Due to most clients using Outlook and Express, I had to add this support so that they were able to receive attachments with Japanese filenames.

I realize that RFC 2047 is old and basically no good, but I could not rely on MS to update Outlook anytime soon. So, I am submitting this patch to add RFC 2047 support. Hopefully, it can be used and reviewed by others.

The change basically adds another parameter to the addAttachment function that should either be '2047' or '2231' (default). This parameter is kept and eventually passed through to the _buildHeaderParam function in mimePart.php. Here, if the standard is 2047 I encode the filename accordingly. I've taken most of the code for converting to 2047 from _encodeHeaders function in mime.php and made slight modifications.

I think that is about it. This patch is working fine for me now. Please feel free to use, correct and improve it and add it to the code base if necessary. 



Test script:
---------------
<?php
include('Mail.php');
include('Mail/mime.php');

$text = 'Text version of email. ƒeƒLƒXƒg ƒo[ƒWƒ‡ƒ“ “ú–{Œê';
$html = '<html><body>HTML version of email. HTML ƒo[ƒWƒ‡ƒ“ “ú–{Œê</body></html>';
$file = 'test,test,test,test,test,test,ƒeƒXƒg,‚Ä‚·‚Æ,“ú–{Œê';
$crlf = "\n";
$hdrs = array( 'From' => 'test@test.com', 'Subject' => 'ƒeƒXƒg ‰Û‘è');

$mime = new Mail_mime($crlf);

$mime->setTXTBody($text);
$mime->setHTMLBody($html);
$mime->addAttachment($file, 'text/plain', '“Y•2047.csv', false, 'base64', 'attachment', 'UTF-8', '', '', '2047');
$mime->addAttachment($file, 'text/plain', '“Y•2231.csv', false, 'base64', 'attachment', 'UTF-8', '', '', '2231');
$mime->addAttachment($file, 'text/plain', '“Y•____.csv', false, 'base64', 'attachment', 'UTF-8');

$params['head_encoding'] = 'base64';
$params['text_encoding'] = 'base64';
$params['html_encoding'] = 'base64';
$params['head_charset'] = 'UTF-8';
$params['text_charset'] = 'UTF-8';
$params['html_charset'] = 'UTF-8';
//do not ever try to call these lines in reverse order
$body = $mime->get($params);
$hdrs = $mime->headers($hdrs);

$mail =& Mail::factory('mail');
$mail->send('ktanaka@bluemetrix.com', $hdrs, $body);
?>


Expected result:
----------------
The test script contains Japanese characters inline and is encoded in UTF-8. Hopefully, the characters are not destroyed when submitting.

Using the test, you can send yourself a mail with attachments having Japanese filenames - one filename using 2047 and two using 2231. As you will notice, Outlook and Outlook Express will not correctly display the filenames in the 2231 format, which is currently the only format supported in Mail_mime.

Comments

[2007-11-09 03:16 UTC] bmdevelopment (Bm Development)

Apologies for my carelessness, but I left a private email address in the test script. Is it possible to delete the test script and re-upload or delete this bug and I will re-post. Again, I apologize for this.

[2007-11-17 03:36 UTC] cwiedmann (Carsten Wiedmann)

> Outlook and Outlook Express will not correctly display
> the filenames in the 2231 format, which is currently the
> only format supported in Mail_mime.

Courios: Outlook have only a problem with 2231, if you are using POP or IMAP. With an other connector like Exchange or Kerio, this works also with 2231.

Outlook Express can only handle 2047/822.


> I think that is about it. This patch is working fine
> for me now. Please feel free to use, correct and
> improve it and add it to the code base if necessary. 

At the moment just some remarks:
- The attached patch is a reverse patch:
  From your version to the original version.
- The patch does not work with folded headers.
- Does only use B-encoding. But Q-encoding should also work.

Thus, this patch is at the moment only half the way. I also would give this request an other name: "Option: disabling RFC 2231 extension". Also I'm +1 to have this feature.

Regards,
Carsten

[2007-11-18 14:23 UTC] cwiedmann (Carsten Wiedmann)

> At the moment just some remarks:

OK, today I've had some time to rewrite the patch (against CVS). The method Mail_mime::addAttachment() have now a tithe parameter:
| @param bool $rfc2231 Allow the language to be used for
|                       display the filename as well as
|                       the character set.
|                       Defaults to true

If you set this parameter to "false", the old behaviour is used. The headers are encoded like e.g. "Subject" and respect the parameters "head_encoding" and "head_charset" from Mail_mime::get().

In case of setting this parameter to "false", "$charset" and "$language" is not used.

So you can now encode the "name" and "filename" with Q or B encoding and with the same charset you have defined for the normal headers.

Long filenames are now also folded with the old style: no problems with e.g. with Outlook Express or Outlook. (see Bug #12429)

I have changed the private method Mail_mime::_encodeHeaders(), to a public static method Mail_mime::encodeHeaders(). So we can use this (the same)  function from the class Mail_mime and the class Mail_mimePart.

Regards,
Carsten

[2008-09-29 02:44 UTC] alec (Aleksander Machniak)

mime_param.patch it's my patch for the same issue.

[2009-06-17 10:54 UTC] alec (Aleksander Machniak)

The following patch has been added/updated:

Patch Name:  mime_bulk.patch
Revision:    1245236075
URL:         http://pear.php.net/bugs/patch-display.php?bug=12411&patch=mime_bulk.patch&revision=1245236075&display=1

[2009-06-17 10:59 UTC] alec (Aleksander Machniak)

I've attached a bulk patch which addresses issues #12411, #12429, #14232, #15320, #14529, #14779. Test script:
<?php

include('Mail/mime.php');

$text = '';
$crlf = "\n";
$file = 'empty.txt'; //some empty file
$files = array(
    'empty.txt',
    'with space.txt',
    'with unicode żąśźć.txt',
    'long name with spaces, very long long long long long very very long long.txt',
    'long name with spaces, very long long long long long very very and żąśźęć.txt',
);
$mime = new Mail_mime($crlf);

foreach ($files as $name) {
        copy($file, '/tmp/'.$name);
        $mime->addAttachment('/tmp/'.$name, 'text/plain', '', true,
                'base64', 'attachment', 'UTF-8', '', '', 'quoted-printable');
}

$mime->setTXTBody($text);

echo $mime->getMessage();

?>

And result:

MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="=_8ea5f688b1cf8f2db7d4f37126f5ac3f"

--=_8ea5f688b1cf8f2db7d4f37126f5ac3f
Content-Transfer-Encoding: base64
Content-Type: text/plain charset=UTF-8;;
 name=empty.txt;
Content-Disposition: attachment;
 filename=empty.txt;


--=_8ea5f688b1cf8f2db7d4f37126f5ac3f
Content-Transfer-Encoding: base64
Content-Type: text/plain charset=UTF-8;;
 name="with space.txt";
Content-Disposition: attachment;
 filename="with space.txt";


--=_8ea5f688b1cf8f2db7d4f37126f5ac3f
Content-Transfer-Encoding: base64
Content-Type: text/plain charset=UTF-8;;
 name="=?UTF-8?Q?with_unicode_=C5=BC=C4=85=C5=9B=C5=BA=C4=87.txt?="; 
Content-Disposition: attachment;
 filename*=UTF-8''with%20unicode%20%C5%BC%C4%85%C5%9B%C5%BA%C4%87.txt;


--=_8ea5f688b1cf8f2db7d4f37126f5ac3f
Content-Transfer-Encoding: base64
Content-Type: text/plain charset=UTF-8;;
 name="long name with spaces, very long long long long long very very lo.txt"; 
Content-Disposition: attachment;
 filename*0*=UTF-8''long%20name%20with%20spaces,%20very%20long%20long%20long;
 filename*1*=%20long%20long%20very%20very%20long%20long.txt;


--=_8ea5f688b1cf8f2db7d4f37126f5ac3f
Content-Transfer-Encoding: base64
Content-Type: text/plain charset=UTF-8;;
 name="=?UTF-8?Q?long_name_with_spaces,_very_long_long_long_long_long_very_v.txt?="; 
Content-Disposition: attachment;
 filename*0*=UTF-8''long%20name%20with%20spaces,%20very%20long%20long%20long;
 filename*1*=%20long%20long%20very%20very%20and%20%C5%BC%C4%85%C5%9B%C5%BA%C4;
 filename*2*=%99%C4%87.txt;


--=_8ea5f688b1cf8f2db7d4f37126f5ac3f--

[2009-12-03 13:39 UTC] alec (Aleksander Machniak)

Added patch mime_bulk.patch.

[2009-12-03 13:41 UTC] alec (Aleksander Machniak)

Updated my bulk patch. Contains fixes for test scripts.

[2009-12-30 12:34 UTC] alec (Aleksander Machniak)

-Assigned To:
+Assigned To:      alec
-Roadmap Versions:
+Roadmap Versions: 1.6.0RC1

[2010-01-01 14:11 UTC] alec (Aleksander Machniak)

-Status: Assigned
+Status: Closed
This bug has been fixed in SVN.

If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET).

If this was a problem with the pear.php.net website, the change should be live shortly.

Otherwise, the fix will appear in the package's next release.

Thank you for the report and for helping us make PEAR better.