Upgrading from 3.1.3 to 3.3.1 (PHP4 branch) I noticed something odd. All of a sudden message text would get clipped, static footers that I inserted into the text would disappear, etc. I made no other changes to the code.
Replacing all copies of \r\n, with foo1
Replacing all copies of \r, with foo2
Replacing all copies of \n, with foo3
And then all of foo? back to a given sequence (\r\n, \r, or \n), I quickly found that the only thing that made the e-mails arrive intact was when I replaced all copies of foo? with \r\n, including the EOL sequence in my static text that I force.
I saw too other threads to this effect:
viewtopic.php?t=73643
viewtopic.php?t=72519
I can't quite figure out why this would be the case.
-joho
Weird EOL handling since 3.3.1 (PHP4 branch) upgrade
Moderators: Chris Corbyn, General Moderators
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Swift does this:
That should in theory turn all valid line endings into \r\n. Are you able to provide me with a test case to work with by any chance?
Does changing to message encoding have any effect? (not a permanent solution).
Code: Select all
$str = str_replace(array("\r\n", "\r"), "\n");
$str = str_replace("\n", "\r\n");Does changing to message encoding have any effect? (not a permanent solution).
Code: Select all
$message->setEncoding("8bit");
//and/or
$part->setEncoding("8bit");-
panczel.levente
- Forum Newbie
- Posts: 2
- Joined: Sun Sep 23, 2007 4:43 pm
I'm experiencing the same problem (I think).
I'm using version 3.3.1 for PHP5
While attaching related CSS in quted-printable encoding I've found that the string gets trimmed. I made some tries to isolate the problem, and found that the minimal fragment causing the error can be presented by the following code:
Which yields:
These two errors are present:
1) The '=' character is inserted into the string though line break is not necessary there.
2) The '{' finishes the output; anything following it is stripped away.
The problem is most probably with the line-ending fixation logic [Encoder.php line 212: while(preg_match(...) || preg_match(...))], until that point seems everything fine.
I'm using version 3.3.1 for PHP5
While attaching related CSS in quted-printable encoding I've found that the string gets trimmed. I made some tries to isolate the problem, and found that the minimal fragment causing the error can be presented by the following code:
Code: Select all
Swift_Message_Encoder::instance()->QPEncode("\r\nbody\r\n{\r\na")(in HEX: 62 6F 3D 0D 0A 64 79 0D 0A 7B)bo=
dy
{
These two errors are present:
1) The '=' character is inserted into the string though line break is not necessary there.
2) The '{' finishes the output; anything following it is stripped away.
The problem is most probably with the line-ending fixation logic [Encoder.php line 212: while(preg_match(...) || preg_match(...))], until that point seems everything fine.
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Perfect! I'll create a completely new test case for my QP encoding logic and see where we get. What you're saying looks very promising and meets my suspicions that my QP logic could be improved. The difficulty comes in making it both fast and accuratepanczel.levente wrote:I'm experiencing the same problem (I think).
I'm using version 3.3.1 for PHP5
While attaching related CSS in quted-printable encoding I've found that the string gets trimmed. I made some tries to isolate the problem, and found that the minimal fragment causing the error can be presented by the following code:Which yields:Code: Select all
Swift_Message_Encoder::instance()->QPEncode("\r\nbody\r\n{\r\na")(in HEX: 62 6F 3D 0D 0A 64 79 0D 0A 7B)bo=
dy
{
These two errors are present:
1) The '=' character is inserted into the string though line break is not necessary there.
2) The '{' finishes the output; anything following it is stripped away.
The problem is most probably with the line-ending fixation logic [Encoder.php line 212: while(preg_match(...) || preg_match(...))], until that point seems everything fine.
~joho, if this is the cause too, switching to a different encoding will work for now.