# 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...
