Update: The subject is properly encoded *if* I truncate it to be:

$subject = "【tokyo-avland】公的証明書の送";

This gives the following subject header:

Subject: =?ISO-2022-JP?B?GyRCIVobKEJ0b2t5by1hdmxhbmQbJEIhWzh4RSo+WkxAPXEkTkF3GyhC?=

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

Although mb_send_mail() seems to resolve your problem, the behaviour is quite by design.

mb_encode_mimeheader is implemented in accordance with section 2 ("Syntax of encoded-words") of RFC2047(http://www.ietf.org/rfc/rfc2047.txt).

---------------------------------------------------------
   An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters.  If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used.

   While there is no limit to the length of a multiple-line header field, each line of a header field that contains one or more 'encoded-word's is limited to 76 characters.
--------------------------------------------------------- EOQ

>Please double-check the documentation

Ok, 

#1 I can't find anywhere in the docs that say that mb_encode_mimeheader() follows RFC2047.

#2 Just becuase it follows RFC2047 doesn't say anything about how mb_encode_mimeheader() treats lines that are too long. Nowhere in the documentation does it say that mb_encode_mimeheader() truncates lines ...

#3 Since the documentation doesn't say anything I had assumed that mb_encode_mimeheader() would trim correctly convert strings that are too long into "CRLF space" encoded words. Is this right? If so it should be added to the documentation

#4 It seems that mb_encode_mimeheader() *did* correctly detect that my headers line was too long and did split the header properly. *However* the subject was garbled when my mail reader put it back together. I am assuming this is because the string is double-byte and mb_encode_mimeheader() cut the string *inside* a double-byte. If this is the case then I would consider *that* a bug.


I'm not conversant in double-byte characters ... Did mb_encode_mimeheader() incorrectly cut the string inside a double-byte character?

Oh, and you said:

>Although mb_send_mail() seems to resolve your problem

How does mb_send_mail() seem to solve my problem? I cannot find anything in mb_send_mail() documentation that says it will act differently than mb_encode_mimeheader(). But it does solve the problem I will certainly use it :)

Hmm, yes, you are right and this is absolutely a problem that is caused by lack of words in the misleading documentation.

Besides I forgot to append the correct diagnosis of this problem.

mb_encode_mimeheader() can only deal with the most basic elements of strings. That is, it simply treats such a charcter that is represented by a numeric html entity as separate components.

Therefore if line folding is done in the middle of a entity compounded of several characters, it inserts CRLF & space there and ends up cluttering the structure of the html entity.

To avoid this, you have to do the following conversion on the string before passing it to mb_encode_mimeheader()

$subject = mb_convert_encoding($subject, "ISO-2022-JP", "HTML-ENTITIES");
var_dump($subject);
var_dump(mb_encode_mimeheader($subject, "ISO-2022-JP", "B"));

Thanks. Should I also submit a documentation bug then concerning mb_encode_mimeheader()?

I'll try out your solution. But what is "HTML-ENTITIES"? I cannot find any mention of that in the mb_string documenation?

Yep, you are always welcome; but I'd rather to see your mb reports such as this one at the php-i18n list first than at the bug database..

I want to make PHP better and of course make the work of the people in charge of checking bug reports easier so I have to ask:

Why doesn't this belong in a bug report?

From what I have understood from your comments, there is no bug in mb_encode_mimeheader() *but* there is a problem with the documentation. So there is a bug, not with the function but with the documentation no?

For me a bug is when a function does not behave as documented  or gives a "broken" result when given valid input.

In this case I gave valid input to the function (the RFC says what to do when the input string is longer than 76 chars) and the function gave back a broken header ...

At the very least there is bug in the docs because it does not state that mb_encode_mimeheader() is not guaranteed to work will double-byte strings that are too long?

I'll happilly submit "report" these to the i18n list instead, I just thought here was the better place since the function *is* broken and should be fixed or the documentation should fixed :)

Oh, and what is "HTML-ENTITIES"?

???! This is still a valid bug report and I've marked as assigned to indicate other volunteers that I'll fix the part of the document regarding this issue.

As for HTML-ENTITIES, I really feel & admit the insufficiency of docs and so I did register a new entry for it. See bug #23250.

Ok. Thanks for all the hard work. I'll keep an eye out for when bug #23250 is closed so that I can understand what HTML-ENTITIES does.

In the meantime I'll try out your solution and see if it works.

I have the same line break problem, but my source string is not HTML-ENCODED, it is plain ISO-2022-JP already, so I can't use $string=mb_encode_mimeheader(mb_convert_encoding($string, "ISO-2022-JP", "HTML-ENTITIES"),$encoding);
fact is, mb_encode_mimeheaders breaks the line withing an MB string, even it is an mb_ functions.
I have read through the whole thread here and I think, this function is buggy and has to be fixed ASAP.
At the moment you have to ship around with inserting a single byte whitespace AFTER the 18th multibyte or 36th single byte character (use mb_strimwidth eg).

gullevek at gullevek dot org:

If the string is really encoded in ISO-2022-JP already and you are trying to transform it into the MIME encoded form,

The code should be like the following:

mb_internal_encoding("ISO-2022-JP");
$string=mb_encode_mimeheader(#string, "ISO-2022-JP");

By contrast to other functions, mb_encode_mimeheader() doesn't take any parameter that specifies the encoding of the source string, if you have to explicitly pass it to the function, you should call mb_internal_encoding() followed by a mb_encode_mimeheader().

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation better.

This is actually a user error:

$subject 
= "【tokyo-avland】公的証明書の送付期限のお知らせ";
$subject = mb_encode_mimeheader($subject);

Correct it must be:

$subject = mb_encode_mimeheader("Subject: " . $subject);

I was puzzling about that for a long time, too, until I got it: where else is 
mb_encode_mimeheader supposed to know when to break from?