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

Groups > comp.lang.php > #17298 > unrolled thread

New line character not working in foreach loop

Back to article view | Back to comp.lang.php

Contents

  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

#17298 — New line character not working in foreach loop

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.

[toc] | [next] | [standalone]

#17300

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
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#17302

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.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17303

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".

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17304

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.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17307

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

-- 

 //Aho

[toc] | [prev] | [next] | [standalone]

#17314

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.

[toc] | [prev] | [next] | [standalone]

#17318

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
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

[toc] | [prev] | [next] | [standalone]

#17305

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 
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.

*All* software _MUST_ require it in the sense that is specified:

<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.

[toc] | [prev] | [next] | [standalone]

#17319

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

[toc] | [prev] | [next] | [standalone]

#17320

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.

-- 
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.

[toc] | [prev] | [next] | [standalone]

#17321

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
developers? :)

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#17323

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.

-- 
16 megs in a '95 box! Yo Ho Ho and a battle of RAM!

[toc] | [prev] | [next] | [standalone]

#17331

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.

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.

-- 
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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web