跨平台换行混淆

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

所以我把行改为

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

它又起作用了。但现在我很困惑。我在 linux 上进行编码，但在使用 filezilla 传输它们之后，我正在读取使用该程序创建的文本文件在 windows 上。现在是哪一部分导致文本文件中的行显示为一行？

我很确定“endl”在 linux 上工作得很好，所以现在我认为 windows 把文件弄乱了在用 filezilla 传输它们之后？弄乱文本文件的写入（和读出）方式将保证我的程序会中断，所以如果有人能解释这一点，我将不胜感激。

我也不记得我在我的程序中做了什么改变导致它中断，因为它之前工作得很好。我唯一添加的是线程。

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

多么奇怪。

Answer 1

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

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

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

是的，我确实认为standardize on one thing 对每个人都有更多的好处，而不是在任何地方都支持他们。我也否认存在“适当平台上的适当行尾”。微软决定他们的原生 API 不说 UTF-8 或不理解 Unix 行尾这一事实并不能阻止每个人的代码在 Windows 上这样做。只要确保不要将这些东西传递给 WinAPI。很多时候，您对系统永远看不到的内部数据进行文本处理，那么您为什么需要通过满足这些系统内部的期望来使您的生活复杂化呢？

Answer 2

在内部，所有应用程序都使用“\n”来表示行终止。

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

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

在 linux 上，行终止序列是 LF ('\n')。因此，您编写文件并将所有 '\n' 转换为 'LF' 字符。您将这些文件传输到 Windows 系统，然后读取该文件。在 Windows 上，行终止序列是 'CRLF' 所以读取文件的编辑器正在寻找两个字符以转换回 '\n' 但没有找到这些字符。现在取决于编辑器的智能程度，你得到的是单行还是多行。

Answer 3

endl 确实“在 Linux 上工作得很好”。流式传输 endl 流式传输 \n 字符并刷新流。总是。

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

这可能不是 C++ 问题，没有什么是“坏”的；您可能应该将 FileZilla 配置为将您的文件视为 text 而不是“binary”（一种不转换行尾的模式）。如果您的文件没有像“.txt”这样的扩展名，那么默认情况下它可能不会这样做。

Answer 4

如果您以 ASCII 格式传输文件，FTP 可能会弄乱您的文件（也就是说，它会转换换行符）。尝试以 BIN（二进制）传输。