Home » Mail » Mail_Mime » Bug #443
Bug in MAIL_mime::addAttachment()
Details
| Submitted | 2003-12-17 02:31 UTC |
|---|---|
| From | nsr_xh at yahoo dot com dot cn |
| Status | Wont fix |
| Package | Mail_Mime |
| PHP Version | 4.3.4 |
| OS | win2000 & linux |
| Roadmaps | (Not assigned) |
Comments
[2003-12-17 02:31 UTC] nsr_xh at yahoo dot com dot cn
Description:
------------
I add a file with a long chinese name. Add I encode it to mime format: it like this:
$filename = "
=?gb2312?B?udjT2rPZtb2hotTnzcu6zc60y6K/qLXEx+m/9s2zvMax7aOoMjAwMw==?=
=?gb2312?B?xOoxMdTCMTHI1dbBMTHUwjIyyNWjqS54bHM=?="
And I add this to my mime mail like this:
$o_mime->addAttachment($file, $contenttype, $filename, true, "base64");
But I found that MAIL_mime deal whit the filename using basename():
$filename = basename($filename);
Because my $filename contains "/", so at last, my attachment is like this:
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="9s2zvMax7aOoMjAwMw==?=
=?GB2312?B?xOoxMdTCMTHI1dbBMTHUwjIyyNWjqS54bHM=?="
and can not be decoded:)
[2004-02-15 13:42 UTC] neufeind at php dot net
Where do the slashes come from? Do they result from any conversion-function? I mean, are they part of the name (and needed for chinese names) or do they result from a conversion from a conversion from a different character encoding? Normally slashes (on Unix/Linux-systems) and backslashes (on Windows-systems) should not be used since they are "special characters". But possibly the chinese name just needs to be decoded properly before doing a "basename()"?
Most of us are not familiar with chinese at all. So we'd appreciate your feedback on how to possibly solve this issue.
[2004-02-18 00:44 UTC] nsr_xh at yahoo dot com dot cn
Thanks for your reply.
Because I use Chinese to send an email, the attach filename should be encoded to mime's encoded-words described in RFC2047.
I use base64 to encode the Chinese filename, but the result contains slashes.
It will be ok if I use quotedprintable as my encoding.
[2004-02-25 18:42 UTC] gschlossnagle at php dot net
RFC 2183, which specifies the nature and structure of the Content-Disposition header does not mandate that it's attributes be base64 encoded. Since / is a valid base64 character, and since it creates ambiguity when used in names which may or may not be encoded, base64 encoding your filenames seems like a bad design choice.
Here's the relevant snippet from 2183 that says what you're doing is non-compliant btw:
Current [RFC 2045] grammar restricts parameter values (and hence
Content-Disposition filenames) to US-ASCII. We recognize the great desirability of allowing arbitrary character sets in filenames, but it is beyond the scope of this document to define the necessary mechanisms. We expect that the basic [RFC 1521] `value' specification will someday be amended to allow use of non-US-ASCII characters, at which time the same mechanism should be used in the Content-Disposition filename parameter.
[2004-07-02 07:42 UTC] d-sano at cybozu dot co dot jp
I was faced the same problem when using JIS encoded
filename.
I think that $name should be the file's name not the file's path, so basename() should be applied only to $file when $isfilename is TRUE.
Here is the patch style diff which I used.
I would like to apply this patch to original source too.
Index: mime.php
===================================================================
RCS file: /home/cvsroot/Framework/pear/pear-20040624/Mail/mime.php,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 mime.php
*** mime.php 24 Jun 2004 01:24:59 -0000 1.1.1.1
--- mime.php 2 Jul 2004 05:01:08 -0000
***************
*** 196,202 ****
function addHTMLImage($file, $c_type='application/octet-stream', $name = '', $isfilename = true)
{
$filedata = ($isfilename === true) ? $this->_file2str($file) : $file;
! $filename = ($isfilename === true) ? basename($file) : basename($name);
if (PEAR::isError($filedata)) {
return $filedata;
}
--- 196,207 ----
function addHTMLImage($file, $c_type='application/octet-stream', $name = '', $isfilename = true)
{
$filedata = ($isfilename === true) ? $this->_file2str($file) : $file;
! if ($isfilename === true) {
! // Force the name the user supplied, otherwise use $file
! $filename = (!empty($name)) ? $name : basename($file);
! } else {
! $filename = $name;
! }
if (PEAR::isError($filedata)) {
return $filedata;
}
***************
*** 224,237 ****
$filedata = ($isfilename === true) ? $this->_file2str($file) : $file;
if ($isfilename === true) {
// Force the name the user supplied, otherwise use $file
! $filename = (!empty($name)) ? $name : $file;
} else {
$filename = $name;
}
if (empty($filename)) {
return PEAR::raiseError('The supplied filename for the attachment can\'t be empty');
}
- $filename = basename($filename);
if (PEAR::isError($filedata)) {
return $filedata;
}
--- 229,241 ----
$filedata = ($isfilename === true) ? $this->_file2str($file) : $file;
if ($isfilename === true) {
// Force the name the user supplied, otherwise use $file
! $filename = (!empty($name)) ? $name : basename($file);
} else {
$filename = $name;
}
if (empty($filename)) {
return PEAR::raiseError('The supplied filename for the attachment can\'t be empty');
}
if (PEAR::isError($filedata)) {
return $filedata;
}