go to bug id or search bugs for
iconv_mime_encode() fails on certain UTF-8 strings containing at least one multibyte character. The error is reproducable for these strings.
I have further noticed that it is more likely that this error occurs if a multibyte character is found at the following character positions within the string:
24±1, 52±3, 82±4, 112±5, 143±5
The code that led me to the previous conclusion can be found here: http://pastebin.com/GXQZ129M
$preferences = array(
'scheme' => 'Q',
'input-charset' => 'utf-8',
'output-charset' => 'utf-8',
'line-length' => 74,
'line-break-chars' => "\r\n",
// Note the ellipsis character at the end of the following string:
iconv_mime_encode('subject', "d obeybiubrsfqllpdtpge…", $preferences);
PHP Notice: iconv_mime_encode(): Unknown error (7) in /home/soulmerge/test.php on line 11
Notice: iconv_mime_encode(): Unknown error (7) in /home/soulmerge/test.php on line 11
Add a Patch
Add a Pull Request
Error 7 is likely E2BIG, what occurs if there's not enough room at
*outbuf when calling iconv().
The culprit is the check whether there is sufficient place in the
line to add another encoded word. out_charset_len + 12 is not
sufficient for quoted-printable encoding of UTF-8. In the worst
case it is out_charset_len + BOILERPLATE + CHARS_PER_BYTE *
MAX_BYTES (where BOILERPLATE == 7, CHARS_PER_BYTE == 3 and
MAX_BYTES == 6), i.e. out_charset_len + 25.
AFAIK, this would be sufficient for all other character encodings
and for Base64 encoding as well. Of course, changing this
threshold might change the result of iconv_mime_encode with regard
to folding, but that supposedly would only break some tests, if
they're relying on the exact output. It would more severly affect
any code that uses small line-length values, but presumably such
code doesn't exist – actually, I can't see a reason to set
line-length < 76.
Only changing the threshold does not work, unfortunately.
We have encountered the same bug when encoding UTF-8 strings with PHP 5.6.32 and PHP 7.1.7. A fix after this long time would be really nice.
As a sidenote: This error impacts also the ZendFramework (5.6.32) because Zend/Mail;Zend/Header is checking with iconv_mime_encode() if a subject line is valid and throws a "Subject value must be composed of printable US-ASCII or UTF-8 characters" instead of sending the mail when the bug occurs.
Sorry. ZendFramework-version is obviouisly not 5.6.32, it is: 2.4.13