什么时候使用php_ol是一个好主意?
我有时会在PHP代码示例中看到这种情况。这是否处理DOS/Mac/Unix终端线问题?
什么时候使用php_ol是一个好主意?
我有时会在PHP代码示例中看到这种情况。这是否处理DOS/Mac/Unix终端线问题?
当前回答
DOS/Windows标准的换行符是CRLF (= \r\n)而不是LFCR (\n\r)。如果我们选择后者,很可能会产生一些意想不到的结果(好吧,实际上是意料之中的!): D)的行为。
现在,几乎所有(编写良好的)程序都接受UNIX标准LF (\n)作为换行代码,甚至邮件发送守护进程(RFC将CRLF设置为标题和消息正文的换行)。
其他回答
PHP 7.1.1和5.6.30版本的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”(在其他任何服务器上)。在5.4.0RC8之前的PHP版本中,PHP_EOL可能有第三个值:"\r"(在MacOSX服务器上)。这是错误的,已于2012-03-01修复,bug 61193。
正如其他人已经告诉您的那样,您可以在需要统一换行符的任何类型的输出中使用PHP_EOL(这些值中的任何一个都是有效的—例如:HTML、XML、日志……)。请记住,决定值的是服务器,而不是客户机。您的Windows访问者将从您的Unix服务器获取值,这有时对他们来说很不方便。
我只是想展示PHP源代码支持的PHP_EOL的可能值,因为这里还没有显示……
我正在使用WebCalendar,发现Mac iCal在导入生成的ics文件时呕吐,因为行尾在xcal.php中硬编码为“\r\n”。我进去,用PHP_EOL替换了所有的事件,现在iCal是快乐的! 我还在Vista和Outlook上进行了测试,即使行尾字符是“\n”,也能导入文件。
我更喜欢用\n\r。而且我在windows系统上,\n在我的经验中工作得很好。
由于PHP_EOL不能与正则表达式一起工作,而正则表达式是处理文本的最有用的方法,所以我真的从未使用过它,也不需要使用它。
您正在编写主要使用单引号字符串的代码。
echo 'A $variable_literal that I have'.PHP_EOL.'looks better than'.PHP_EOL;
echo 'this other $one'."\n";
当我的PHP没有浏览器时,我使用PHP_EOL常量。实际上,我间接地使用它。查看下面的示例。 例如,有一个叫code的网站。Golf(基本上是堆栈交换代码,但具有交互性)。有一个PHP只有控制台输出,我需要使用PHP_EOL常量来使用这个。
一种缩短它的方法是,一旦你需要使用PHP_EOL常量,就像这样做:
<?php
echo $n = PHP_EOL;
?>
这声明了变量$n,您可以使用它代替PHP_EOL常量作为换行符。甚至比<br>还要短,而且几乎任何需要换行符的东西都可以使用$n !