问将代码从Windows传输到OS时PHP问题

EN

终于找到了一个简单的方法来解决这个问题！在查看php.ini文件时，我遇到了一个名为: auto_detect_line_endings的选项，它的默认值设置为: Off。

对此选项的说明如下：

; If your scripts have to deal with files from Macintosh systems,
; or you are running on a Mac and need to deal with files from
; unix or win32 systems, setting this flag will cause PHP to
; automatically detect the EOL character in those files so that
; fgets() and file() will work regardless of the source of the file.
; http://php.net/auto-detect-line-endings

这正是我要找的！

我只是在我的数据库文件的开头使用了ini_set()函数(我在每个php页面上加载了这个函数)，它似乎解决了这个问题！ini_set()函数还返回脚本完成后在php.ini文件中更改的选项。

我使用的ini_set()函数的整行：

ini_set("auto_detect_line_endings", true);

谢谢你们的帮助！

关于ini_set()函数的更多信息如下：集()函数

关于auto_detect_line_endings选项的更多信息如下：自动检测行尾选项

检查您的php开头标签前面是否有空格。还可以尝试使用windows (crlr)行尾从notepad++重新保存文件。(编辑> EOL转换> Windows格式)

值得注意的是，这个错误总是说输出是在第1行启动的。这让我想到，在Mac和Windows操作系统处理新行或空白的方式上是否存在某种编码差异？或者Dropbox传输会把事情搞砸吗？

不要重做代码，也不要担心header()调用，甚至cookie之类的东西。这不是问题所在。

问题是Windows行结束与Mac行结束不同。更多细节这里。

不同的操作系统使用不同的字符来标记行尾：

• Unix / Linux / OS使用LF (行提要，'\n'，0x0A)
• OS X之前的Mac使用CR (回车，'\r'，0x0D)
• Windows / DOS使用CR+LF (回车后跟着行提要，'\r\n'，0x0D0A)

在这种情况下，页面的格式会导致Apache中的PHP解析器阻塞文件。在进行header()调用或设置cookie之前，可能会将内容发送到浏览器。这意味着从技术上讲，错误的行尾会强制发送一个“头”，因为文件本身无意中将数据输出到浏览器。

解决方案可能是避免使用Dropbox &只需将文件复制到闪存驱动器并以这种方式传输。这是一个想法，但我不相信Dropbox是这方面的罪魁祸首。这意味着即使您将文件复制到闪存驱动器，该问题也可能仍然存在。

或者，如果这不起作用，按照文章的链接做&下载一个好的文本编辑工具，比如TextWrangler。只需将文件加载到TextWrangler中&然后手动更改行尾，使它们成为Mac (CR)，并重新保存文件。

解决此问题的另一个长期解决方案可能是使用像git这样的版本控制系统，再加上GitHub上的帐户来管理您的代码。好处是通过将代码推送到GitHub &从GitHub中提取代码，流程本身将处理跨平台行结束的麻烦。而且，您也不需要担心直接将文件复制到DropBox这样的服务中所造成的意外。

但同样，非常确信这与Dropbox无关。这都是关于Windows行结束与Mac行结束不同的问题。

编辑：--关于如何处理Windows到Mac行尾Mac提示的大量转换，有一些有趣的想法。最让人费解的是使用zip和unzip来促进这个过程。我还没试过这个，所以请注意！但是这听起来确实是值得测试的东西，因为最后一行是BTW，它是要解压缩的"-a“标志，这使得ascii文件的行尾被转换。

我一直使用以下方法(在名为fixascii的文件中)： #!/bin/sh zip -qr foo.zip "$@“& unzip -aqo foo.zip & rm foo.zip 然后将其执行为： 要转换的fixascii文件或目录 它比大多数其他命令都有好处，因为你可以将它不受惩罚地指向整个目录树，它将处理其中的所有文件，而不会破坏任何二进制文件，这些二进制文件中可能有一串看起来像行尾的位。 我见过太多次有人破坏了大量的图像和其他二进制文件，试图使用dos2unix或tr结合find修复文本文件上的行尾，但未能确保只处理文本文件。解压缩找出哪些文件是ascii，转换它们，并且不使用二进制文件。 BTW，它是要解压缩的"-a“标志，这使得ascii文件的行尾被转换。

然后查看unzip的官方手册页面中的-a (转换文本文件)选项；重点是我的：

通常，所有文件都是按照存储的方式提取的(作为“二进制”文件)。 -a选项使压缩后的文件作为文本文件(在zipinfo列表中有't‘标签，而不是'b')被自动提取，转换行尾、文件结束字符和字符集本身。(例如，Unix文件使用行尾提要(LFs)表示行结束(EOL)，并且没有结束-of-file ( EOF )标记；Macintoshes使用回车返回(CRs)用于EOLs；大多数PC操作系统使用CR+LF进行EOLs，而控制-Z用于EOF。)此外，IBM大型机和密歇根终端系统使用EBCDIC而不是更常见的ASCII字符集，NT支持Unicode。请注意，zip对文本文件的识别并不完美；有些“文本”文件实际上可能是二进制文件，反之亦然。因此，解压缩打印“文本”或“二进制”，作为在使用-a选项时提取的每个文件的可视检查。-aa选项强制将所有文件提取为文本，而不管假定的文件类型如何。

编辑：，如果您可以访问Linux机器，您可能需要签出dos2unix。还有更多的这里的细节。并发现了另一个堆栈溢出问题这里。