Hi,
I have finally found the root issue. Basically, the issue does not lie
in imap methods, rather it lies in PHP core.
PHP is not consistent in naming variables inside the $_SERVER array.
While running under Apache, it creates $_SERVER['WINDIR'], while running
directly from command line it creates $_SERVER['windir']. Because I was
checking just the upper case version to do some compatibility work for
non-windows systems, the compatibility code were active also on windows
resulting in inappropriate line breaks (just \n instead of \r\n) which
with combination with the Microsoft's SMTP server results in malformed
e-mail.
MC
On 21. 11. 2012 11:30, MC wrote:
what is the recommended way to encode e-mail text in UTF-8?
When the site were running in a single byte code page like iso-8859-2
I were happy with the imap_8bit function and quoted-printable encoding
of e-mails. However, the function does not seem to work correctly for
multi-byte code pages like UTF-8.
Did you use header 'Content-Type:text/html;charset=utf-8' on the email?
No, I am using text/plain content-type, more specifically:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: QUOTED-PRINTABLE
The result e-mail looks like the following (I've replaced all english
letters with just x):
xxxxý xxxx
x xříxxxx xxxxxxxxx xxxxxx xxěxx x xxxx=xxx xx xxxxxí xxxxxxxxxx
xxxxxxxx x xxxxxxxxxx xxxxxxxxx
x xxxxx=xxx
xxxxxáxx xxxáxxx
The raw encoded version of the above text is the following:
xxxx=C3=BD xxxx=0A=
=0A=
x x=C5=99=C3=ADxxxx xxxxxxxxx xxxxxx xx=C4=9Bxx x xxxx=3Dxxx xx
xxxxx=C3=AD=
xxxxxxxxxx xxxxxxxx x xxxxxxxxxx xxxxxxxxx=0A=
=0A=
x xxxxx=3Dxxx=0A=
=0A=
xxxxx=C3=A1xx xxx=C3=A1xxx=
The first "=" ("=3D") should be "f" and the second "a".
Or you think it might be a bug in the imap_8bit or imap_mail_compose
function? Parts/attachements which are rendered as BASE64 are not being
malformed, just the quoted printable ones.
Thanks,
MC
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
