PHP_EOL should generally be used for platform-specific output.
- Mostly for file output really.
- Actually the file functions already transform
rnon Windows systems unless used in
fopen(…, "wb")binary mode.
For file input you should prefer
n however. While most network protocols (HTTP) are supposed to use
rn, that's not guaranteed.
Therefore it's best to break up on
nand remove any optional
$lines = array_map("rtrim", explode("n", $content));
Or use the
file(…, FILE_IGNORE_NEW_LINES)function right away, to leave EOL handling to PHP or auto_detect_line_endings.
A more robust and terser alternative is using
preg_split()and a regexp:
$lines = preg_split("/R/", $content);
Rplaceholder detects any combination of r + n. So would be safest, and even work for Classic MacOS
? 9text files (rarely seen in practice).
Obligatory microoptimization note:
While regex has a cost, it's surprisingly often speedier than manual loops and string postprocessing in PHP.
And there are a few classic examples where you should avoid
PHP_EOL due to its platform-ambiguity:
- Manual generation of network protocol payloads, such as HTTP over
mail()and MIME construction (which really, you shouldn't do tediously yourself anyway).
- File output, if you want to consistently write just Unix
nnewlines regardless of environment.
So use a literal
"rn" combination when not writing to files, but preparing data for a specific context that expects network linebreaks.