gpt4 book ai didi

c++ - 跨平台换行混淆

转载 作者:可可西里 更新时间:2023-11-01 15:00:18 32 4
gpt4 key购买 nike

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

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/Binary 交换传输模式(甚至删除了 force-ASCII-for-txt-extension),但没有任何区别。换行符出现在 linux 中,但不出现在 windows 中。 fz-messup

真奇怪。

最佳答案

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

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

  • 在所有平台上统一行尾('\n', LF)。
  • 始终以二进制方式打开文件,即使您编写的是文本。
  • 让打开文件的用户使用能够理解任何行尾的文本查看器。 Windows 有很多(包括 Visual Studio、Notepad++、写字板和您最喜欢的浏览器)。

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

关于c++ - 跨平台换行混淆,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/8033950/

32 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com