跨平台的换行符混乱

Question

由于某种原因，我的写入文本文件功能突然停止工作。

void write_data(char* filename, char* writethis)
{
    ofstream myfile;
    myfile.open (filename, std::ios_base::app);
    myfile << endl << writethis;
    myfile.close();
}

该函数是从循环中调用的，因此基本上它从空行开始，并将以下所有“ writethis”行附加在新行上。

然后突然之间，没有更多的换行符。 所有文本都附加在一行上。 所以我做了一些挖掘，发现了这一点：

1. Windows = CR LF
2. Linux = LF
3. MAC <0SX = CR

所以我把线改为

myfile << "\r\n" << writethis;

并且再次起作用。 但是现在我很困惑。 我在linux上编码，但是在通过filezilla传输它们之后，我正在Windows上读取由该程序创建的文本文件。 现在，哪一部分导致文本文件中的行显示为一行？

我很确定“ endl”在Linux上能正常工作，所以现在我想Windows用filezilla传输文件后将文件弄乱了吗？ 搞清楚文本文件的写入（和读出）方式将确保我的程序能够被打破，因此，如果有人可以解释这一点，我将不胜感激。

我还不记得我在程序中所做的更改导致此中断，因为它在早期运行良好。 我添加的唯一一件事是线程。

编辑：我曾尝试从ASCII /二进制交换传输模式（甚至删除了force-ASCII-for-txt-extension），但没有区别。 换行符出现在linux中，但不在Windows中。

真奇怪

Answer 1

发生的情况是，您编写了Unix行尾（'\\ n'），然后将其传输到Windows计算机上，以获取按位相同的文件，然后尝试使用不理解Unix行尾的查看器打开文件（可能是记事本） 。

根据我在编写可移植代码方面的经验：

• 在所有平台上对一个行尾（ '\\n' ，LF）进行标准化。
• 即使编写文本，也始终以二进制打开文件。
• 让打开文件的用户使用理解任何行尾的文本查看器。 有很多用于Windows的窗口（包括Visual Studio，Notepad ++，Wordpad和您喜欢的浏览器）。

是的，我确实认为每个人都可以标准化一件事而不是在所有人的支持下受益更多。 我也否认“在适当的平台上存在适当的行尾”。 Microsoft决定其本机API不讲UTF-8或不理解Unix行尾的事实，并不能阻止在Windows上每个人的代码都这样做。 只要确保不要将这些内容传递给WinAPI。 很多时候，您会对系统永远不会看到的内部数据进行文本处理，那么为什么您还要满足这些系统内部的期望，却使生活变得复杂？

Answer 2

endl 确实 “对于Linux来说工作得很好”。 流endl流一个\\n字符并刷新流。 总是。

但是，在Windows的实现层上，文本模式下的文件流会将\\n转换为\\r\\n ，并且在平台之间传输文件时，通常还会发现行尾被转换。

这可能不是C ++问题，什么也没有“损坏”。 您应该将FileZilla配置为将文件视为文本而不是“ 二进制 ”（不转换行尾的模式）。 如果您的文件没有扩展名（如“ .txt”），则默认情况下可能不会这样做。

Answer 3

如果您将文件传输为ASCII，FTP可能会弄乱您的文件（即，它会转换换行符）。 尝试以BIN（二进制）的形式传输。

Answer 4

在内部，所有应用程序均使用'\\ n'表示行终止。

问题在于，行终止顺序是特定于文本文件的平台（随着研究的进行）注：文本文件，这是打开文件时的默认格式。 如果在打开文件时显式选择二进制，则在读/写时不会发生翻译。

这实际上意味着当您将\\ n字符写入文件时，它会转换为特定于平台的字符序列。 但也请注意，读取文件时，此平台特定的序列将转换回'\\ n'。 您遇到的问题是您已在一个平台上编写了文件，并在另一个平台上读取了它们。

在Linux上，行终止顺序为LF（'\\ n'）。 这样，您写入文件，所有的'\\ n'都将转换为'LF'字符。 您将这些文件传输到Windows系统，然后读取文件。 在Windows上，行终止顺序为'CRLF'，因此读取文件的编辑器正在寻找两个字符以转换回'\\ n'，但找不到这些字符。 现在，这取决于编辑器是单行还是多行。