什么时候使用PHP常量“ PHP_EOL”？

什么时候使用是个好主意PHP_EOL？

我有时会在PHP的代码示例中看到这一点。这样可以处理DOS / Mac / Unix终端问题吗？

是的，PHP_EOL表面上是用于以跨平台兼容的方式查找换行符，因此它可以处理DOS / Unix问题。

请注意，PHP_EOL表示当前系统的结束符。例如，在类似Unix的系统上执行时，它将找不到Windows终端行。

从main/php.hPHP版本7.1.1和版本5.6.30开始：

#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"（在其他任何设备上）。在5.4.0RC8 之前的 PHP版本上，PHP_EOL：（"\r"在MacOSX服务器上）可能存在第三个值。这是错误的，已于2012-03-01 修复，错误为61193。

正如其他人已经告诉您的那样，您可以PHP_EOL在需要统一换行符的任何类型的输出（这些值中的任何一个都是有效的，例如：HTML，XML，日志...）中使用。请记住，确定值的是服务器，而不是客户端。Windows访问者将从您的Unix服务器上获得价值，这有时对他们来说不方便。

我只想显示PHP_EOLPHP来源支持的可能值，因为此处尚未显示。

您可以使用PHP_EOL，当你想要一个新的生产线，和你想成为跨平台的。

这可能是在您将文件写入文件系统（日志，导出，其他）时。

如果希望生成的HTML可读，则可以使用它。因此，您可能会跟随<br />一个PHP_EOL。

如果您正在运行cron中的php作为脚本，并且需要输出某些内容并将其格式化为屏幕格式，则可以使用它。

如果您要建立一封电子邮件以发送需要某种格式的电子邮件，则可以使用它。

PHP_EOL（字符串）此平台的正确“行尾”符号。自PHP 4.3.10和PHP 5.0.2起可用

在服务器的文件系统上读取或写入文本文件时，可以使用此常数。

在大多数情况下，行尾并不重要，因为大多数软件都可以处理文本文件，而不管其来源如何。您应该与代码保持一致。

如果行尾很重要，请显式指定行尾，而不要使用常量。例如：

• HTTP标头必须以\r\n
• CSV文件应该使用\r\n作为行分隔符

我想提出一个针对“何时不使用它” 的答案，因为它尚未被涵盖，并且可以想象它被盲目使用了，直到下线才有人注意到这是一个问题。其中一些与某些现有答案有些矛盾。

如果以HTML格式输出到网页，尤其是in中的文本<textarea>，<pre>或者<code>您可能总是想使用\n而不是PHP_EOL。

这样做的原因是，虽然代码在一个服务器上可能可以很好地运行，而该服务器恰好是类Unix平台，但如果将其部署在Windows主机（例如Windows Azure平台）上，则可能会改变某些浏览器中页面的显示方式（特别是Internet Explorer-其某些版本将同时显示\ n和\ r）。

我不确定自IE6以来这是否仍然是一个问题，因此它可能还没有定论，但似乎值得一提，它是否可以帮助人们迅速思考上下文。可能还有其他情况（例如严格的XHTML），\r在某些平台上突然输出可能会导致输出问题，我敢肯定还有其他类似情况。

正如已经有人指出的那样，在返回HTTP标头时，您不希望使用它-因为它们在任何平台上都应始终遵循RFC。

我不会将它用于CSV文件上的分隔符（如有人建议的那样）。服务器所运行的平台不应确定生成或使用的文件中的行尾。

我发现PHP_EOL对于文件处理非常有用，尤其是在将多行内容写入文件时。

例如，您有一个长字符串要写入普通文件时分成多行。使用\ 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无法处理终端问题，因为使用该常量的系统与发送输出的系统不同。

我完全不建议使用PHP_EOL。Unix / Linux使用\ n，MacOS / OS X也从\ r更改为\ n，在Windows上，许多应用程序（尤其是浏览器）也可以正确显示它。在Windows上，也可以很容易地更改现有客户端代码以仅使用\ n并仍保持向后兼容性：只需将行修剪的定界符从\ r \ n更改为\ n并将其包装在类似函数trim（）中。

PHP_EOL的定义是，它为您提供了正在使用的操作系统的换行符。

实际上，您几乎永远不需要它。考虑以下几种情况：

• 当您输出到Web时，实际上没有任何约定，只是您应该保持一致。由于大多数服务器都是Unixy，因此无论如何您都希望使用“ \ n”。

• 如果要输出到文件，则PHP_EOL似乎是一个好主意。但是，通过在文件中包含文字换行符，可以得到类似的效果，如果您尝试在Unix上运行某些CRLF格式的文件而又不破坏现有的换行符，那么这将为您提供帮助（例如，使用双启动系统的人，可以说我更喜欢后者的行为）

PHP_EOL太长了，以至于真的不值得使用它。

有一个明显的地方可能有用：在编写主要使用单引号字符串的代码时。关于是否：

echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;  
echo 'this other $one'."\n";

它的艺术是一致的。混合和匹配''和“”的问题是，当您得到长字符串时，您实际上并不需要去寻找使用哪种类型的引号。

与生活中的所有事物一样，它取决于上下文。

DOS / Windows标准“换行符”是CRLF（= \ r \ n），而不是LFCR（\ n \ r）。如果我们将后者放在首位，则可能会产生一些意想不到的（实际上，实际上是一种预期的！：D）行为。

如今，几乎所有（编写良好的）程序都接受UNIX标准LF（\ n）用于换行符，甚至包括邮件发送方守护程序（RFC将CRLF设置为标头和消息正文的换行符）。

如果要输出多行，可以使用error_log（）。

我发现许多调试语句在Windows安装上看起来都很奇怪，因为开发人员在分解字符串时假定unix结尾。

我在必须编写的某些命令行脚本中使用了PHP_EOL常量。我在本地Windows计算机上进行开发，然后在Linux服务器盒上进行测试。使用常量意味着我不必担心为每个不同的平台使用正确的行尾。

我有一个网站，在该网站上，用户可以使用任何操作系统执行操作后，日志记录脚本都会在文本文件中写入新行文本。

在这种情况下，使用PHP_EOL似乎并不是最佳选择。如果用户在Mac OS上并写入文本文件，它将放置\ n。在Windows计算机上打开文本文件时，不会显示换行符。因此，我使用“ \ r \ n”代替，在任何操作系统上打开文件时都可以使用。

您正在编写主要使用单引号字符串的代码。

echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;  
echo 'this other $one'."\n";

我正在使用WebCalendar，发现Mac iCal在导入生成的ics文件时使用barfs，因为行尾在xcal.php中被硬编码为“ \ r \ n”。我进去并用PHP_EOL替换了所有出现的内容，现在iCal很高兴！我还在Vista上进行了测试，即使行尾字符为“ \ n”，Outlook也能够导入文件。

当jumi（PHP的joomla插件）​​出于某种原因编译您的代码时，它将删除代码中的所有反斜杠。这样的东西$csv_output .= "\n";变成$csv_output .= "n";

非常烦人的错误！

使用PHP_EOL来获得您想要的结果。

在某些系统上使用此常量可能会很有用，因为例如，如果您正在发送电子邮件，则可以使用PHP_EOL使跨系统脚本在更多系统上运行...但是，即使有时有用，您也可以找到此常量常量未定义，使用最新的php引擎进行现代托管不会出现此问题，但是我认为写点代码可以节省这种情况是一件好事：

<?php
  if (!defined('PHP_EOL')) {
    if (strtoupper(substr(PHP_OS,0,3) == 'WIN')) {
      define('PHP_EOL',"\r\n");
    } elseif (strtoupper(substr(PHP_OS,0,3) == 'MAC')) {
      define('PHP_EOL',"\r");
    } elseif (strtoupper(substr(PHP_OS,0,3) == 'DAR')) {
      define('PHP_EOL',"\n");
    } else {
      define('PHP_EOL',"\n");
    }
  }
?>

因此，您可以毫无问题地使用PHP_EOL ...显然，PHP_EOL应该用于应该立即在更多系统上运行的脚本上，否则您可以使用\ n或\ r或\ r \ n ...

注意：PHP_EOL可以是

1) on Unix    LN    == \n
2) on Mac     CR    == \r
3) on Windows CR+LN == \r\n

希望这个答案有帮助。

输出到Windows客户端时，我刚刚遇到此问题。当然，PHP_EOL是针对服务器端的，但是php的大多数内容输出都是针对Windows客户端的。因此，我必须在这里为下一个人放置我的发现。

A）回显“我的文字”。PHP_EOL; //不好，因为它仅输出\ n，并且大多数版本的Windows记事本都在一行上显示，大多数Windows记帐软件无法导入这种类型的行尾字符。

B）回显'我的文字\ r \ n'; //错误，因为单引号的PHP字符串不能解释\ r \ n

C）回显“我的文字\ r \ n”；//是的，它起作用了！在记事本中看起来正确，并且在将文件导入其他Windows软件（例如Windows记帐和Windows制造软件）时有效。

我更喜欢使用\ n \ r。另外，我使用的是Windows系统，根据我的经验，\ n可以正常工作。

由于PHP_EOL不适用于正则表达式，而这些是处理文本的最有用的方法，因此我真的从未使用过它，也不需要使用它。