info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: New line character not working in foreach loop
170 views
Skip to first unread message
Jerry Stuckle
Jan 28, 2017, 10:54:35 PM1/28/17
to
On 1/28/2017 9:19 PM, wart2ww wrote:
> The code I have works correctly except the \n newline character is not working. When the email message is sent, the index values are all printed on one line. What have I done wrong?
>
> foreach ($_POST as $key => $value) {
>
> if (isset($fields[$key])) {
> $emailText .= "$fields[$key]: $value\n"; }
> }
>
> Thank you for your help.
>
Try
$emailText .= "#fields[key]": $value" . "\n"; }
In your code, $value\n" would not be taken as a variable followed by a
newline character.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================
> The code I have works correctly except the \n newline character is not working. When the email message is sent, the index values are all printed on one line. What have I done wrong?
>
> foreach ($_POST as $key => $value) {
>
> if (isset($fields[$key])) {
> $emailText .= "$fields[$key]: $value\n"; }
> }
>
> Thank you for your help.
>
Try
$emailText .= "#fields[key]": $value" . "\n"; }
In your code, $value\n" would not be taken as a variable followed by a
newline character.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================
Christoph M. Becker
Jan 29, 2017, 5:39:20 AM1/29/17
to
On 29.01.2017 at 03:19, wart2ww wrote:
> The code I have works correctly except the \n newline character is not working. When the email message is sent, the index values are all printed on one line. What have I done wrong?
>
> foreach ($_POST as $key => $value) {
>
> if (isset($fields[$key])) {
> $emailText .= "$fields[$key]: $value\n"; }
> }
The proper newline character sequence for emails is CRLF, i.e. "\r\n".
> The code I have works correctly except the \n newline character is not working. When the email message is sent, the index values are all printed on one line. What have I done wrong?
>
> foreach ($_POST as $key => $value) {
>
> if (isset($fields[$key])) {
> $emailText .= "$fields[$key]: $value\n"; }
> }
While some MTAs have problems with CRLF, others may actually require it.
--
Christoph M. Becker
J.O. Aho
Jan 29, 2017, 6:37:28 AM1/29/17
to
which should be have "\r\n", but in the body itself, then it's a lot
about the client used, this mail would look like intended in Thunderbird
and would still just be one liner in Outlook, no matter if you have
"\r\n" or "\n".
--
//Aho
Christoph M. Becker
Jan 29, 2017, 7:09:22 AM1/29/17
to
Content-Type: text/plain
If so, Outlook would be *seriously* broken.
--
Christoph M. Becker
Thomas 'PointedEars' Lahn
Jan 29, 2017, 9:04:46 AM1/29/17
to
Christoph M. Becker wrote:
> On 29.01.2017 at 03:19, wart2ww wrote:
>> The code I have works correctly except the \n newline character is not
>> working. When the email message is sent, the index values are all printed
>> on one line. What have I done wrong?
>>
>> foreach ($_POST as $key => $value) {
>>
>> if (isset($fields[$key])) {
>> $emailText .= "$fields[$key]: $value\n"; }
>> }
>
> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
> While some MTAs have problems with CRLF,
If there are any, screw them; obviously their developers do not want their
> On 29.01.2017 at 03:19, wart2ww wrote:
>> The code I have works correctly except the \n newline character is not
>> working. When the email message is sent, the index values are all printed
>> on one line. What have I done wrong?
>>
>> foreach ($_POST as $key => $value) {
>>
>> if (isset($fields[$key])) {
>> $emailText .= "$fields[$key]: $value\n"; }
>> }
>
> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
> While some MTAs have problems with CRLF,
users, and their users who are Internet service providers do not want their
customers, to receive proper e-mails. Those bugs ought to be fixed, and
there is no leverage on those people if you keep catering to their bugs.
Industry standards exist to be followed, not ignored.
> others may actually require it.
<https://tools.ietf.org/html/rfc5322#section-2.1>
Are you confusing MTAs and MUAs?
--
PointedEars
Zend Certified PHP Engineer <http://www.zend.com/en/yellow-pages/ZEND024953>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.
J.O. Aho
Jan 29, 2017, 10:30:40 AM1/29/17
to
https://naveensnayak.wordpress.com/2012/08/30/ms-outlook-messing-up-line-breaks
--
//Aho
Thomas 'PointedEars' Lahn
Jan 30, 2017, 1:01:29 AM1/30/17
to
The described one is purely a *display* issue, _not_ one of encoding.
It has *nothing to do* with the issue in this thread.
As the blog post indicates, Outlook *up to version 2012* (and maybe not
later) will remove, for seeming convenience of reading (again, µ$~1’s idea
of convenience) *any* *additional* linebreaks *for display* of *a plain-text
message* *if you have configured it that way*. The setting appears to be
the default there, probably because µ$~1 assumes e-mails to be written
manually by people only.
The correct way for *a MUA* for *writing* line breaks in a plain-text
Internet message is separating lines with CRLF. Period.
As the blog post indicates, adding a <HT> (Horizontal Tab) character
*before* the <CR><LF> (so that the resulting line reads “…<HT><CR><LF>”)
would suppress Outlook (2012)’s special display behavior even if the user
has not changed their settings accordingly:
<?php
foreach ($_POST as $key => $value) {
if (isset($fields[$key])) {
$emailText .= "{$fields[$key]}: {$value}\t\r\n";
if (isset($fields[$key])) {
}
}
Of course, as the OP says that this message is _not_ a plain-text message,
for the user to *see* any line breaks *displayed* there, in a *working* NUA
without such “features”, the final message body source must read at least
…<br><CR><LF>
where “<br>” must be written verbatim (and if it is XHTML it has to be
“<br/>”; one can use “<br />” for backwards compatibility), and <CR> and
<LF> are *two* non-printable characters, "\r" and "\n" in PHP (the double-
quotes are important):
<?php
foreach ($_POST as $key => $value) {
if (isset($fields[$key])) {
$emailText .= "{$fields[$key]}: {$value}<br />\r\n";
if (isset($fields[$key])) {
}
}
(It is simply untrue that "\n" would be *implicitly* equivalent to "\r\n"
in Windows. Do not listen to wannabes.)
Semantic markup would use lists instead:
<?php
$emailText .= "<ul>\r\n";
foreach ($_POST as $key => $value) {
if (isset($fields[$key])) {
}
}
$emailText .= "</ul>\r\n";
In this case, one has field names and corresponding values; in an HTML
e-mail, that warrants the semantic use of a table instead of a list. And of
course it is tedious and messy to add the CRLF manually each time, so a
later joined array of strings, where each element represents a line, comes
in handy:
<?php
$emailText = ['<table>'];
/* optional */
$emailText[] = '<thead><th>Field</th><th>Value></th></tr></thead>';
$emailText[] = '<tbody>';
foreach ($_POST as $key => $value) {
if (isset($fields[$key])) {
}
}
$emailText[] = '</tbody></table>';
$emailText = implode("\r\n", $emailText) . "\r\n";
[Note that in HTML the default horizontal alignment (per UA stylesheet) for
“th” element content is “center”, and the default vertical alighment for
both “th” and “td” element content is “middle”. To keep the message as
small as possible, you should specify a document stylesheet if you want to
suggest a different formatting to the HTML UA used by the MUA.]
Finally, note that because not all people want to receive HTML e-mails¹, and
not all of them have e-mail clients that can process them, HTML e-mails
should be sent as *multi-part* messages: one part that is plain text and one
that is HTML (this is equivalent to a plain-text message with an inline HTML
document attached. Then, if HTML rendering is not possible, at least the
message contained in the e-mail can be displayed without much hassle.
But because the then-recommended multi-part format more than doubles the
size of the e-mail without adding considerable information, and HTML carries
with it an increased security risk due to its need for rendering (HTML
potentially can contain malicious code or references to such, or references
to external resources that *invariably* compromise privacy²), HTML e-mails
are frowned upon by many people in general¹. Consider *carefully* whether
you *really* need to send an HTML e-mail and, if possible, leave the user
the choice of the format in which they want to receive e-mails sent by your
application (multi-part messages are comparably big at the sender’s no
matter how they choose to display them).
_________
¹ count me among them²
² The display – and therefore download – of a simple embedded image
(that can be just a transparent GIF image, one pixel wide and high,
virtually invisible) suffices to know that you have read the e-mail,
so that, among other things, the target e-mail address is valid.
Consider
<img src="http://tracker.example/tracker.php?id=74656" alt="">
in an HTML e-mail. That looks pretty harmless, right?
WRONG.
Because of the request that the HTML UA in your e-mail client has made
for that “tracking pixel”, the person who caused the e-mail to be sent to
your.a...@example.net now knows that your.a...@example.net is
valid. Combined with personal information that you have provided in a
form, and the ID that connects your form submission with the e-mail you
received, they can know where approximately you are, your Internet
Service Provider (both from your IP address) aso. That is why you agreed
to their terms of use when checking that checkbox before submitting that
form (otherwise you could not have submitted it).
IOW, never display HTML messages; but if you do, never let referred
resources in them be downloaded by default, never provide e-mail
addresses in forms that you do not want to be exposed, and never even
*attempt* to *display* e-mails sent by someone who you do not know.
Christoph M. Becker
Jan 31, 2017, 9:54:03 AM1/31/17
to
On 30.01.2017 at 07:01, Thomas 'PointedEars' Lahn wrote:
> Finally, note that because not all people want to receive HTML e-mails¹, and
> not all of them have e-mail clients that can process them, HTML e-mails
> should be sent as *multi-part* messages: one part that is plain text and one
> that is HTML (this is equivalent to a plain-text message with an inline HTML
> document attached. Then, if HTML rendering is not possible, at least the
> message contained in the e-mail can be displayed without much hassle.
ACK. Also don't make the mistake to tell the recipient that the email
> Finally, note that because not all people want to receive HTML e-mails¹, and
> not all of them have e-mail clients that can process them, HTML e-mails
> should be sent as *multi-part* messages: one part that is plain text and one
> that is HTML (this is equivalent to a plain-text message with an inline HTML
> document attached. Then, if HTML rendering is not possible, at least the
> message contained in the e-mail can be displayed without much hassle.
is only available as HTML version, and that they should follow a link to
read it online. And don't even make it worse by not adding the link:
| Diese Mailing wird nur als HTML-Version versendet. Klicken Sie HIER um
| das Mailing anzuzeigen.
I'm regularly getting this from a well-known German email provider.
*facepalm*
--
Christoph M. Becker
Christoph M. Becker
Jan 31, 2017, 9:58:50 AM1/31/17
to
On 29.01.2017 at 15:04, Thomas 'PointedEars' Lahn wrote:
> Christoph M. Becker wrote:
>
>> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
>> While some MTAs have problems with CRLF,
>
> If there are any, screw them; obviously their developers do not want their
> users, and their users who are Internet service providers do not want their
> customers, to receive proper e-mails. Those bugs ought to be fixed, and
> there is no leverage on those people if you keep catering to their bugs.
> Industry standards exist to be followed, not ignored.
In an ideal world, I'd fully agree. However, this world is far from
being ideal, and sometimes you don't really have a choice.
> Are you confusing MTAs and MUAs?
Actually, I confused the header with the body. See the respective note
regarding the $additional_headers parameter of mail()[1].
[1]
<http://php.net/manual/en/function.mail.php#refsect1-function.mail-parameters>
--
Christoph M. Becker
> Christoph M. Becker wrote:
>
>> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
>> While some MTAs have problems with CRLF,
>
> If there are any, screw them; obviously their developers do not want their
> users, and their users who are Internet service providers do not want their
> customers, to receive proper e-mails. Those bugs ought to be fixed, and
> there is no leverage on those people if you keep catering to their bugs.
> Industry standards exist to be followed, not ignored.
being ideal, and sometimes you don't really have a choice.
> Are you confusing MTAs and MUAs?
regarding the $additional_headers parameter of mail()[1].
[1]
<http://php.net/manual/en/function.mail.php#refsect1-function.mail-parameters>
--
Christoph M. Becker
Thomas 'PointedEars' Lahn
Jan 31, 2017, 11:07:09 AM1/31/17
to
Christoph M. Becker wrote:
> On 29.01.2017 at 15:04, Thomas 'PointedEars' Lahn wrote:
>> Christoph M. Becker wrote:
>>> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
>>> While some MTAs have problems with CRLF,
>> If there are any, screw them; obviously their developers do not want
>> their users, and their users who are Internet service providers do not
>> want their customers, to receive proper e-mails. Those bugs ought to be
>> fixed, and there is no leverage on those people if you keep catering to
>> their bugs. Industry standards exist to be followed, not ignored.
>
> In an ideal world, I'd fully agree. However, this world is far from
> being ideal, and sometimes you don't really have a choice.
On a broader perspective, consider this: This world not just is, but it is
> On 29.01.2017 at 15:04, Thomas 'PointedEars' Lahn wrote:
>> Christoph M. Becker wrote:
>>> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
>>> While some MTAs have problems with CRLF,
>> If there are any, screw them; obviously their developers do not want
>> their users, and their users who are Internet service providers do not
>> want their customers, to receive proper e-mails. Those bugs ought to be
>> fixed, and there is no leverage on those people if you keep catering to
>> their bugs. Industry standards exist to be followed, not ignored.
>
> In an ideal world, I'd fully agree. However, this world is far from
> being ideal, and sometimes you don't really have a choice.
shaped by those who live in it. It will not be something even close to an
ideal world if those who strive to know allow the idiots of this world to
do what they do.
Christoph M. Becker
Jan 31, 2017, 11:45:07 AM1/31/17
to
On 31.01.2017 at 17:07, Thomas 'PointedEars' Lahn wrote:
> Christoph M. Becker wrote:
>
>> On 29.01.2017 at 15:04, Thomas 'PointedEars' Lahn wrote:
>>> Christoph M. Becker wrote:
>>>> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
>>>> While some MTAs have problems with CRLF,
>>> If there are any, screw them; obviously their developers do not want
>>> their users, and their users who are Internet service providers do not
>>> want their customers, to receive proper e-mails. Those bugs ought to be
>>> fixed, and there is no leverage on those people if you keep catering to
>>> their bugs. Industry standards exist to be followed, not ignored.
>>
>> In an ideal world, I'd fully agree. However, this world is far from
>> being ideal, and sometimes you don't really have a choice.
>
> On a broader perspective, consider this: This world not just is, but it is
> shaped by those who live in it. It will not be something even close to an
> ideal world if those who strive to know allow the idiots of this world to
> do what they do.
Aren't we *used* to work around non-standard conforming software as Web
> Christoph M. Becker wrote:
>
>> On 29.01.2017 at 15:04, Thomas 'PointedEars' Lahn wrote:
>>> Christoph M. Becker wrote:
>>>> The proper newline character sequence for emails is CRLF, i.e. "\r\n".
>>>> While some MTAs have problems with CRLF,
>>> If there are any, screw them; obviously their developers do not want
>>> their users, and their users who are Internet service providers do not
>>> want their customers, to receive proper e-mails. Those bugs ought to be
>>> fixed, and there is no leverage on those people if you keep catering to
>>> their bugs. Industry standards exist to be followed, not ignored.
>>
>> In an ideal world, I'd fully agree. However, this world is far from
>> being ideal, and sometimes you don't really have a choice.
>
> On a broader perspective, consider this: This world not just is, but it is
> shaped by those who live in it. It will not be something even close to an
> ideal world if those who strive to know allow the idiots of this world to
> do what they do.
developers? :)
--
Christoph M. Becker
Peter H. Coffin
Feb 1, 2017, 12:25:09 PM2/1/17
to
On Tue, 31 Jan 2017 17:07:04 +0100, Thomas 'PointedEars' Lahn wrote:
> On a broader perspective, consider this: This world not just is, but it is
> shaped by those who live in it. It will not be something even close to an
> ideal world if those who strive to know allow the idiots of this world to
> do what they do.
Doesn't mean we should be contributing to the problem. "Be liberal with
> On a broader perspective, consider this: This world not just is, but it is
> shaped by those who live in it. It will not be something even close to an
> ideal world if those who strive to know allow the idiots of this world to
> do what they do.
what you accept" isn't the whole of the philosophy.
--
16 megs in a '95 box! Yo Ho Ho and a battle of RAM!
Thomas 'PointedEars' Lahn
Feb 3, 2017, 7:45:08 AM2/3/17
to
Peter H. Coffin wrote:
> On Tue, 31 Jan 2017 17:07:04 +0100, Thomas 'PointedEars' Lahn wrote:
>> On a broader perspective, consider this: This world not just is, but it
>> is shaped by those who live in it. It will not be something even close
>> to an ideal world if those who strive to know allow the idiots of this
>> world to do what they do.
>
> Doesn't mean we should be contributing to the problem. "Be liberal with
> what you accept" isn't the whole of the philosophy.
That is exactly my point.
> On Tue, 31 Jan 2017 17:07:04 +0100, Thomas 'PointedEars' Lahn wrote:
>> On a broader perspective, consider this: This world not just is, but it
>> is shaped by those who live in it. It will not be something even close
>> to an ideal world if those who strive to know allow the idiots of this
>> world to do what they do.
>
> Doesn't mean we should be contributing to the problem. "Be liberal with
> what you accept" isn't the whole of the philosophy.
ISTM that you are attempting to turn the Internet robustness principle
upside down, justifying e.g. Outlook’s bugs/unintuitive “features”.
It is the *MUA* which is “accepting” here.
Thomas 'PointedEars' Lahn
Feb 3, 2017, 7:48:46 AM2/3/17
to
Peter H. Coffin wrote:
> On Tue, 31 Jan 2017 17:07:04 +0100, Thomas 'PointedEars' Lahn wrote:
>> On a broader perspective, consider this: This world not just is, but it
>> is shaped by those who live in it. It will not be something even close
>> to an ideal world if those who strive to know allow the idiots of this
>> world to do what they do.
>
> Doesn't mean we should be contributing to the problem. "Be liberal with
> what you accept" isn't the whole of the philosophy.
> On Tue, 31 Jan 2017 17:07:04 +0100, Thomas 'PointedEars' Lahn wrote:
>> On a broader perspective, consider this: This world not just is, but it
>> is shaped by those who live in it. It will not be something even close
>> to an ideal world if those who strive to know allow the idiots of this
>> world to do what they do.
>
> Doesn't mean we should be contributing to the problem. "Be liberal with
> what you accept" isn't the whole of the philosophy.
That is exactly my point.
ISTM that you are attempting to turn the Internet robustness principle
upside down, justifying e.g. Outlook’s bugs/unintuitive “features”.
It is the *receiving* MTA and the *MUA* which are “accepting” here.
ISTM that you are attempting to turn the Internet robustness principle
upside down, justifying e.g. Outlook’s bugs/unintuitive “features”.
0 new messages