ID: 23192
Updated by: [EMAIL PROTECTED]
Reported By: jc at mega-bucks dot co dot jp
-Status: Assigned
+Status: Closed
Bug Type: Documentation problem
Operating System: Red Hat Linux 8.0
PHP Version: 4.3.2RC1
Assigned To: moriyoshi
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2003-07-30 00:48:24] [EMAIL PROTECTED]
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().
------------------------------------------------------------------------
[2003-07-29 19:57:21] gullevek at gullevek dot org
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).
------------------------------------------------------------------------
[2003-04-17 20:10:17] jc at mega-bucks dot co dot jp
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.
------------------------------------------------------------------------
[2003-04-17 08:14:58] [EMAIL PROTECTED]
???! 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.
------------------------------------------------------------------------
[2003-04-16 21:21:33] jc at mega-bucks dot co dot jp
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"?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/23192
--
Edit this bug report at http://bugs.php.net/?id=23192&edit=1
