为什么apache在找到CLRF而不是LF时不会感到困惑？答案

【问题标题】：Why doesn't apache get confused when it finds CLRFs instead of LFs?为什么apache在找到CLRF而不是LF时不会感到困惑？
【发布时间】：2016-02-17 13:59:39
【问题描述】：

我在 win 10 环境中使用 homestead 开发基于 laravel 的网站。我在 git 中将 autoclrf 设置为 true。此外，我在设置的“Windows 端”使用 git。这意味着，当文件被提交到 repo 时，CLRF 被转换为 LF，反之亦然，当它们被签出时。问题是，驻留在 ubuntu 中的 apache 为驻留在 Windows 中的脚本提供服务。为什么当它发现脚本具有 windows 风格的行尾而不是 LF 时，它不会感到困惑？

【问题讨论】：

这不是一个真正的编程问题，因此不适合 SO。但是，我认为仅仅是因为它意味着读取文件并将内容推送到浏览器，甚至不关心换行符。
您期望会混淆PHP的区别是什么？由 CRLF 组成的换行符对 PHP 来说只是一些空格，就像由单个 LF 组成的换行符一样。
@MattGibson 感谢您的回答。据我了解，对于 PHP 解析器，可以安全地忽略换行符。那么在哪些情况下它们之间的区别很重要？
@FranzGleichmann 我不同意。问题是关于 PHP 解析器的工作细节，我认为它属于编程类别。你不同意吗？
@AlexanderLomia 它是关于程序如何工作的，而不是关于编程本身。 MattGibson：基本上只有当你在 Windows 中用一个愚蠢的编辑器打开一个 linux 创建的文件时（大多数智能编辑器都能识别），或者当你用你的脚本读取一个文件并在它只有 \n 时显式查找“\r\n”时.

标签： php git apache laravel

【解决方案1】：

这基本上是因为 PHP 在大多数情况下对 LF 和 CR+LF 之间的区别不敏感，这是有道理的，因为它使用 the same lexer on Windows and Unix platforms 所以它需要处理这两种类型的文件。

来自词法分析器的小代表代码sn-p；

if (*p == '\n' || (*p == '\r' && (*(p+1) != '\n'))) {                   \
    CG(zend_lineno)++;                                                  \
}

如您所见，它在同一代码库中处理 LF 或 CR+LF。

【讨论】：