Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.php > #17314

Re: New line character not working in foreach loop

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>

Show all headers | View raw


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 | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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