Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #17314
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Newsgroups | comp.lang.php |
| Subject | Re: New line character not working in foreach loop |
| Date | 2017-01-30 07:01 +0100 |
| Organization | PointedEars Software (PES) |
| Message-ID | <5007566.DvuYhMxLoT@PointedEars.de> (permalink) |
| References | <421a78ff-7a42-4c0a-ba17-816d5d02a285@googlegroups.com> <o6kgok$q8f$1@solani.org> <ef62fkF1tj2U1@mid.individual.net> <o6km1e$uig$1@solani.org> <ef6g4rF4mdkU1@mid.individual.net> |
J.O. Aho wrote:
> On 01/29/17 13:09, Christoph M. Becker wrote:
>> On 29.01.2017 at 12:37, J.O. Aho wrote:
>>> On 01/29/17 11:39, 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, others may actually require
>>>> it.
>>>
>>> It's not the issue with the MTA as this don't seem to be the mail header
>>> 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".
>>
>> Even if there is
>>
>> Content-Type: text/plain
>>
>> If so, Outlook would be *seriously* broken.
>>
>
> Yes, even if so and yes it's seriously broken mail client.
>
> https://naveensnayak.wordpress.com/2012/08/30/ms-outlook-messing-up-line-breaks
“It’s not a bug, it’s a feature.”
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";
}
}
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";
}
}
(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 .= "<li>{$fields[$key]}: {$value}</li>\r\n";
}
}
$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[] = "<tr><th>{$fields[$key]}</th><td>{$value}</td></tr>";
}
}
$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.address@example.net now knows that your.address@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.
--
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.
Back to comp.lang.php | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
New line character not working in foreach loop wart2ww <fcc@bmi.net> - 2017-01-28 18:19 -0800
Re: New line character not working in foreach loop Jerry Stuckle <jstucklex@attglobal.net> - 2017-01-28 22:54 -0500
Re: New line character not working in foreach loop "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-29 11:39 +0100
Re: New line character not working in foreach loop "J.O. Aho" <user@example.net> - 2017-01-29 12:37 +0100
Re: New line character not working in foreach loop "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-29 13:09 +0100
Re: New line character not working in foreach loop "J.O. Aho" <user@example.net> - 2017-01-29 16:30 +0100
Re: New line character not working in foreach loop Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-30 07:01 +0100
Re: New line character not working in foreach loop "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-31 15:54 +0100
Re: New line character not working in foreach loop Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-29 15:04 +0100
Re: New line character not working in foreach loop "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-31 15:59 +0100
Re: New line character not working in foreach loop Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-01-31 17:07 +0100
Re: New line character not working in foreach loop "Christoph M. Becker" <cmbecker69@arcor.de> - 2017-01-31 17:45 +0100
Re: New line character not working in foreach loop "Peter H. Coffin" <hellsop@ninehells.com> - 2017-02-01 11:04 -0600
Re: New line character not working in foreach loop Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2017-02-03 13:48 +0100
csiph-web