我不确定这是什么时候开始的，但最近我所有的PHP文件都遇到了一个相当烦人的问题，即在每一行的末尾都添加了空格。有点烦人，但并非完全不可能使用/解决。但是，我也注意到，当受此问题困扰的代码被复制并粘贴到其他地方时，这些无害的空格是新的空白行，这是一个相当大的问题。
我注意到打开受影响的文件并使用 UTF-8 NO BOM 重新保存它们似乎可以纠正问题，直到文件关闭并稍后重新打开。我已经通过一个程序运行了我的所有文件，该程序将文件更改为无 BOM，但它似乎根本没有任何影响。
我想知道这是否是我使用的编辑器(UltraEdit(的问题，计算机/本地服务器上的文件设置，ftp程序(FileZilla(的问题，甚至是Web服务器的问题。
问题的根源是使用 FTP 在 Windows 系统(您的工作站(和 Linux 系统(您的 Web 服务器(之间进行传输。对于文本文件，在以两种方式传输文件时，应使用 FTP 程序的 ASCII(或文本(模式(而不是"二进制"模式(。使用二进制模式传输它也是可以的。产生问题的是它们的混合。
Windows 使用两个字符(CR 和 LF(来标记文本文件中的行尾。Linux(以及OSX和其他Unix-es(仅使用LF来实现此目的。FTP 程序的文本/ASCII 传输模式在传输时执行适当的转换。二进制模式不会更改它传输的文件。
这就是发生的事情：你在Windows上创建一个文件。它的线条以CR LF结尾。您可以使用二进制模式在 Linux 上传输它。不会删除 CR 字符。它们在网页上不可见，但某些 Linux 程序会显示(作为 ^M(。它们就在每行的末尾。您可能会修改 Web 服务器上的脚本，以快速修复您在将页面上线时发现的问题，然后您重新传输文件，但这次使用的是文本传输模式。或者，也许朋友/同事在他们自己的Windows计算机上复制文件，他们使用与您的帐户设置不同的FTP程序。由于文本模式，FTP 程序在每个 NL 字符之前插入一个新的 CR 字符。这使得行以 CR CR LF 结尾。某些 Windows 程序将第一个 CR 字符显示为空格。其他人则将其视为新行(即使它只是新行的"一半"(。
它与 UTF-8 BOM 无关。顺便说一句，UTF-8 BOM 完全没用。
我无法告诉UltraEdit，但Notepad++，PSPad和其他Windows编辑器会检测并在其状态栏中显示他们编辑的文件(Windows或Linux(中新行的类型。它们还允许用户将新生产线的类型从一个系统更改为另一个系统。
解决方案非常简单：修复换行符后，将FTP客户端配置为对PHP文件(和其他文本文件(使用文本传输模式。还要教你的同事如何设置他们的程序来做同样的事情。
文件编辑器有问题。
下载记事本++并将字符设置为UTF-8 不带BOM并保存。
编辑：
将文件权限设置为只读。