我什么时候使用PHP常量“PHP_EOL”？
什么时候使用PHP_EOL是一个好主意？
我有时在PHP的代码示例中看到这一点。 这是否处理DOS / Mac / Unix的endline问题？
是的， PHP_EOL表面上用于以跨平台兼容的方式查找换行符，因此它可以处理DOS / Mac / Unix问题。
当你想要一个新的行，并且你想要跨平台的时候你使用PHP_EOL 。
这可能是当你写文件到文件系统（日志，出口，其他）。
你可以使用它，如果你想生成的HTML是可读的。 所以你可以用PHP_EOL来关注你的<br /> 。
你可以使用它，如果你正在从cron运行php脚本，你需要输出一些东西，并将其格式化为屏幕。
你可以使用它，如果你正在build立一个电子邮件发送，需要一些格式。
从PHP 5.6.30和7.1.1的main/php.h ：
#ifdef PHP_WIN32 # include "tsrm_win32.h" # include "win95nt.h" # ifdef PHP_EXPORTS # define PHPAPI __declspec(dllexport) # else # define PHPAPI __declspec(dllimport) # endif # define PHP_DIR_SEPARATOR '\\' # define PHP_EOL "\r\n" #else # if defined(__GNUC__) && __GNUC__ >= 4 # define PHPAPI __attribute__ ((visibility("default"))) # else # define PHPAPI # endif # define THREAD_LS # define PHP_DIR_SEPARATOR '/' # define PHP_EOL "\n" #endif
正如你所看到的， PHP_EOL可以是"\r\n" （在Windows服务器上）或"\n" （在其他任何地方）。 在PHP版本5.4.0RC8 之前， PHP_EOL有第三个值： "\r" （在MacOSX服务器上）。 这是错误的，并已修复2012年3月1日bug 61193 。
正如其他人已经告诉你的，你可以在任何types的输出中使用PHP_EOL （其中任何一个值都是有效的 – 例如：HTML，XML，日志…），你需要统一换行符 （在我看来你应该这样做） 。
我只是想显示由PHP源支持的PHP_EOL的可能值，因为它还没有在这里显示…
PHP_EOL（string）这个平台的正确的'End Of Line'符号。 自PHP 4.3.10和PHP 5.0.2起可用
当您在服务器的文件系统上读取或写入文本文件时，可以使用此常量。
在大多数情况下，行结束并不重要，因为大多数软件都能够处理文本文件，而不pipe它们的来源如何。 你应该与你的代码一致。
如果行结束很重要，则明确指定行结束而不是使用常量。 例如：
- HTTP标头必须用
\r\n分隔 - CSV文件应该使用
\r\n作为行分隔符
我想提出一个答案，说明“什么时候不使用它”，因为它还没有被覆盖，可以想象它被盲目地使用，没有人注意到有一个问题，直到后来下线。 有些与现有的一些答案有些矛盾。
如果输出到HTML中的网页，尤其是<textarea> ， <pre>或<code> <textarea> ，您可能总是希望使用\n而不是PHP_EOL 。
原因是，尽pipe代码可能在一台服务器上运行良好，如果部署在Windows主机上（例如Windows Azure平台），则可能会改变在某些浏览器中显示页面的方式（特别是Internet Explorer – 其中一些版本将会同时看到\ n和\ r）。
我不确定自IE6以来这是否仍然是一个问题，所以它可能是相当有争议的，但似乎值得一提的是，如果它可以帮助人们提示思考的上下文。 可能还有其他一些情况（如严格的XHTML），在某些平台上突然输出\r可能会导致输出出现问题，我相信还有其他类似的边缘情况。
正如已经有人指出的那样，在返回HTTP标头时，您不希望使用它，因为它们应该始终在任何平台上遵循RFC。
我不会将它用于CSV文件分隔符之类的东西（正如有人提出的那样）。 服务器运行的平台不应该确定生成或消耗的文件中的行结尾。
PHP_EOL的定义是它为您提供了正在操作的操作系统的换行符。
在实践中，你应该几乎不需要这个。 考虑一些情况：
-
当你输出到networking时，除了你应该保持一致以外，没有任何约定。 由于大多数服务器都是Unixy，所以您仍然需要使用“\ n”。
-
如果你输出到一个文件，PHP_EOL似乎是一个好主意。 不过，如果你想在Unix上运行一些CRLF格式的文件，而不会破坏现有的换行符（这是一个双启动系统的家伙），你可以得到类似的效果， ，我可以说我更喜欢后者的行为）
PHP_EOL太可笑了，真的不值得使用它。
我发现PHP_EOL对于文件处理非常有用，特别是如果您将多行内容写入文件。
例如，你有一个很长的string，你想在写入纯文件的时候分成多行。 使用\ r \ n可能无法正常工作，因此只需将PHP_EOL放入您的脚本中即可，结果非常棒。
看看下面这个简单的例子：
<?php $output = 'This is line 1' . PHP_EOL . 'This is line 2' . PHP_EOL . 'This is line 3'; $file = "filename.txt"; if (is_writable($file)) { // In our example we're opening $file in append mode. // The file pointer is at the bottom of the file hence // that's where $output will go when we fwrite() it. if (!$handle = fopen($file, 'a')) { echo "Cannot open file ($file)"; exit; } // Write $output to our opened file. if (fwrite($handle, $output) === FALSE) { echo "Cannot write to file ($file)"; exit; } echo "Success, content ($output) wrote to file ($file)"; fclose($handle); } else { echo "The file $file is not writable"; } ?>
不，PHP_EOL不处理endline问题，因为使用该常量的系统与发送输出的系统不同。
我不会推荐使用PHP_EOL。 Unix / Linux使用\ n，MacOS / OS X也从\ r更改为\ n，在Windows上，许多应用程序（尤其是浏览器）也可以正确显示它。 在Windows上，也很容易改变现有的客户端代码来使用\ n并且仍然保持向后兼容性：只需要将修剪分隔符从\ r \ n更改为\ n并将其包装在trim（）函数中。
有一个显而易见的地方可能是有用的：当你正在编写主要使用单引号string的代码。 它可以论证：
echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL; echo 'this other $one'."\n";
它的艺术是一致的。 混合和匹配的问题是，当你拿到很长的string时，你并不想去寻找你使用的引用types。
与生活中的所有事物一样，这取决于上下文。
DOS / Windows标准“新行”是CRLF（= \ r \ n）而不是LFCR（\ n \ r）。 如果把后者放在一起，很可能会产生一些意想不到的结果（事实上，这种预期的！）D行为。
现在，几乎所有（写得很好的）程序都接受用于换行符代码的UNIX标准LF（\ n），甚至邮件发送者守护程序（RFC将CRLF设置为标题和消息体的换行符 ）。
您正在编写主要使用单引号string的代码。
echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL; echo 'this other $one'."\n";
我有一个站点，日志脚本在用户的操作之后将新的文本行写入文本文件，用户可以使用任何操作系统。
在这种情况下使用PHP_EOL似乎并不是最优的。 如果用户在Mac OS上并写入文本文件，则会放入\ n。 在Windows计算机上打开文本文件时，不显示换行符。 为此，我使用“\ r \ n”而不是在任何操作系统上打开文件时都起作用。
如果输出多行，则使用error_log（）。
我发现很多debugging语句在我的Windows安装中看起来很奇怪，因为开发人员在分解string时已经假定了unix结尾。
我使用的WebCalendar，发现Mac iCal barfs导入一个生成的ics文件，因为行尾是在xcal.php硬编码为“\ r \ n”。 我进去用PHP_EOL取代所有的事件，现在iCal很高兴！ 我也在Vista上进行testing，Outlook也能够导入文件，即使行尾字符是“\ n”。
我在一些我必须写的命令行脚本中使用PHP_EOL常量。 我在本地Windows机器上开发，然后在Linux服务器上进行testing。 使用常数意味着我不必担心使用每个不同平台的正确行结束。
当jumi（PHP的joomla插件）由于某种原因编译你的代码时，它会从你的代码中删除所有的反斜杠。 比如$csv_output .= "\n"; 变成$csv_output .= "n";
非常烦人的错误！
使用PHP_EOL来取得你之后的结果。
我更喜欢使用\ n \ r。 此外，我在Windows系统上，\ n在我的经验中工作得很好。
由于PHP_EOL不能处理正则expression式，而这些是处理文本最有用的方式，所以我真的从来没有使用它或需要。
