ID: 23192
Updated by: [EMAIL PROTECTED]
Reported By: jc at mega-bucks dot co dot jp
Status: Assigned
Bug Type: Documentation problem
Operating System: Red Hat Linux 8.0
PHP Version: 4.3.2RC1
Assigned To: moriyoshi
New Comment:
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().
Previous Comments:
------------------------------------------------------------------------
[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"?
------------------------------------------------------------------------
[2003-04-16 21:11:27] [EMAIL PROTECTED]
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..
------------------------------------------------------------------------
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
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
