When is it a good idea to use PHP_EOL
?
I sometimes see this in code samples of PHP. Does this handle DOS/Mac/Unix endline issues?
When is it a good idea to use PHP_EOL
?
I sometimes see this in code samples of PHP. Does this handle DOS/Mac/Unix endline issues?
I found PHP_EOL very useful for file handling, specially if you are writing multiple lines of content into a file.
For example, you have a long string that you want to break into the multiple lines while writing into plain file. Using \r\n might not work so simply put PHP_EOL into your script and the result is awesome.
Check out this simple example below:
I prefer to use \n\r. Also I am on a windows system and \n works just fine in my experience.
Since PHP_EOL does not work with regular expressions, and these are the most useful way of dealing with text, then I really never used it or needed to.
I use the PHP_EOL constant in some command line scripts I had to write. I develop on my local Windows machine and then test on a Linux server box. Using the constant meant I didn't have to worry about using the correct line ending for each of the different platforms.
You use
PHP_EOL
when you want a new line, and you want to be cross-platform.This could be when you are writing files to the filesystem (logs, exports, other).
You could use it if you want your generated HTML to be readable. So you might follow your
<br />
with aPHP_EOL
.You would use it if you are running php as a script from cron and you needed to output something and have it be formatted for a screen.
You might use it if you are building up an email to send that needed some formatting.
I'd like to throw in an answer that addresses "When not to use it" as it hasn't been covered yet and can imagine it being used blindly and no one noticing the there is a problem till later down the line. Some of this contradicts some of the existing answers somewhat.
If outputting to a webpage in HTML, particularly text in
<textarea>
,<pre>
or<code>
you probably always want to use\n
and notPHP_EOL
.The reason for this is that while code may work perform well on one sever - which happens to be a Unix-like platform - if deployed on a Windows host (such the Windows Azure platform) then it may alter how pages are displayed in some browsers (specifically Internet Explorer - some versions of which will see both the \n and \r).
I'm not sure if this is still an issue since IE6 or not, so it might be fairly moot but seems worth mentioning if it helps people prompt to think about the context. There might be other cases (such as strict XHTML) where suddently outputting
\r
's on some platforms could cause problems with the output, and I'm sure there are other edge cases like that.As noted by someone already, you wouldn't want to use it when returning HTTP headers - as they should always follow the RFC on any platform.
I wouldn't use it for something like delimiters on CSV files (as someone has suggested). The platform the sever is running on shouldn't determine the line endings in generated or consumed files.
I am using WebCalendar and found that Mac iCal barfs on importing a generated ics file because the end-of-line is hardcoded in xcal.php as "\r\n". I went in and replaced all occurrences with PHP_EOL and now iCal is happy! I also tested it on Vista and Outlook was able to import the file as well, even though the end of line character is "\n".