php因cr和lf不匹配而中断

当我上传一些PHP文件时，我遇到了一些奇怪的问题，有些PHP文件有cr+lf EOL字符，有些有cr，有些有lf。
我正在使用Win8、Filezilla、Notepad++和PHPRunner进行一些模板化工作（都存储在dropbox同步文件夹中）。当我处理手工编制的php文件时，我有时使用PHPRunner跨ftp文件，有时使用Filezilla

当我在notepad++中打开文件时，似乎有时这些行尾会自行更改，我需要转到notepad++->edit EOL conversion将它们更改回unix样式

所以这通常不会困扰我（除了它们随机变化的方式有点奇怪之外），但是在PHP中，如果您需要一个具有不同行结尾的文件，那么它会自动失败，并且没有任何效果。 所以我的问题是

1） 这是PHP的预期行为吗？如果是的话，它有没有办法在同一个源文件中接受不同的EOL编码

2） 你知道为什么我的下线角色会被改变吗？是Filezilla、notepad++还是dropbox或PHPRunner在修补？（打开文件时，我从未看到文件更改的通知，仅在重新启动计算机时发生）

---

这有点让人费解，所以我想问一下是否有其他人遇到过这种情况

任何数量的应用程序都喜欢更改行尾；在许多情况下，它被认为是有用的行为。Ftp程序（等）具有在跨系统传输时转换文本文件的选项。FTP的“ascii”模式（通常是文本文件的默认模式）支持自动转换。如果您最终上载了一些文件并进行了转换，而一些文件没有进行转换，那么最终将得到一个不一致的集合

记事本++可能也在这样做；我不用它，所以我不能说。最糟糕的是，程序只会为您所接触的行插入其首选的行尾，从而导致文件的行尾不一致。至少，听起来你没有那么做

---

简而言之：从记事本++开始，检查每个与文件接触的工具的设置

您应该展示您已经尝试过的内容？因此看起来PHP不喜欢仅限CR的EOL。将其更改为CR+LF或仅更改为LF将修复它，PHP将正确运行。我一辈子都搞不懂为什么我的行尾总是换成CR。我猜是记事本++在打开文件时做的，但检查了unix设置的选项，实际上无法捕获发生的更改。