跨平台换行混乱

nat*_*tli 11 c c++ text newline

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

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

该函数是从循环中调用的,所以基本上它以空行开始,并在新行上附加以下所有"writethis"行.

然后突然间,没有更多的新行.所有文本都附加在一行上.所以我做了一些挖掘,我遇到了这个:

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

所以我改行了

myfile << "\r\n" << writethis;
Run Code Online (Sandbox Code Playgroud)

它再次起作用.但现在我很困惑.我正在使用linux进行编码,但是在使用filezilla传输后,我正在阅读使用该程序在Windows上创建的文本文件.现在哪一部分导致文本文件中的行显示为一行?

我非常确定"endl"对linux工作得很好所以现在我认为windows 使用filezilla传输文件搞砸了文件?弄乱文本文件写入(和读出)的方式将保证我的程序中断,所以如果有人可以解释这一点,我会很感激.

我也不记得我在我的程序中改变了什么导致它破坏,因为它之前工作得很好.我添加的唯一内容是线程.

编辑: 我已经尝试从ASCII/Binary交换传输模式(甚至删除了force-ASCII-for-txt-extension),但它没有区别.换行符出现在linux中,但不出现在Windows上. FZ-messup

有多奇怪

ybu*_*ill 10

会发生什么情况是你编写Unix行结尾('\n'),然后将它传输到Windows机器获取一个按位相同的文件,然后尝试使用不理解Unix行结尾的查看器打开文件(可能是记事本) .

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

  • '\n'在所有平台上标准化一行结束(,LF).
  • 即使您编写文本,也始终以二进制文件打开文件.
  • 让打开文件的用户使用能够理解任何行结尾的文本查看器.Windows有很多(包括Visual Studio,Notepad ++,Wordpad和您最喜欢的浏览器).

是的,我确实认为每个人一件事情标准化而不是在任何地方支持所有这些事情都会带来更多好处.此外,我否认在适当的平台上存在"正确的行结尾".事实上,微软决定他们的原生API不会说UTF-8或者不理解Unix行结尾,这并不妨碍每个人的代码在Windows上做到这一点.请确保不要将此内容传递给WinAPI.很多时候,您对内部数据进行文本处理是系统无法看到的,那么为什么您需要通过满足这些系统内部的期望来使您的生活复杂化?

  • @ TomalakGeret'kal:这是不可能的,你通常不能确定哪个文件是文本的,什么是二进制文件.现在想象两台机器,一台Linux和一台Windows写入NAS上的同一文件.谁负责和转换? (3认同)
  • @ybungalobill:如果你是唯一一个写文件的人,那就太棒了.不幸的是,你必须处理由其他程序编写的文件(这里我们肯定有filezilla和可能编写该文件的其他文本编辑器(以读取的修改格式)).所以你真的需要详细解释发生了什么,所以OP可以考虑这些其他程序并进行适当补偿.虽然我在小规模上同意你的技术,但对于OP将遇到的一般情况来说,这还不够. (2认同)

Lig*_*ica 6

endl "只是正常工作的Linux".流式endl传输一个\n字符并刷新流.总是.

但是,文本模式下的文件流会将其转换\n\r\nWindows上的实现层,并且您经常会在平台之间传输文件时发现转换行结尾.

这可能不是C++问题,没有任何"破坏"; 您应该将FileZilla配置为将文件视为文本而不是" 二进制 "(一种不转换行结尾的模式).如果您的文件没有像".txt"这样的名称扩展名,那么默认情况下它可能不会这样做.

  • @natli:没什么奇怪的.Microsoft Notepad是一个笑话作为文本查看器.除了`\ r \n`之外什么都不懂,不能用大文件等等......那又怎么样?只是不要使用它.我的第三个子弹没有说二进制和ASCII. (2认同)