为什么Windows无法读取超过0x1A（EOF）字符，而Unix可以读取？

Question

可能重复：
为什么在读取eof时设置了故障位？有出路吗？

我正在编写一个小程序，它在Mac OS和Ubuntu（Unix ...）上运行良好。该程序必须读取数据文件并将字节（chars / unsigned chars）分开，然后将memcpy()它们分成浮点数。这将包括以下过程：读取以下四个值，将其读取并向左移至32位int，然后将ints内存复制到中float。像这样：

0x43 0x66 0x1A 0x79->将int32和memcpy（）读入float-> val = 230.103

就像我说的那样，这在Unix上可以正常使用，但是Windows似乎将解释char 0x1A为文件结尾（EOF）错误，并停止读取数据。为什么Windows会这样做而不是Unix？我该如何关闭呢？

我什至尝试通过查看错误ifstream本身来检查错误，并检查是否已设置EOL标志。然后，我将clear()使用ifstream的错误标志并继续读取（使用get()），但是该死的东西总是返回相同的EOF / 0x1A字符，并且不会读取下一个字符。

编辑：添加了一些代码

ifstream input (PATH, ios::in);
if (input.is_open()) {
  unsigned int counter = 0;
  while (input.good()) {
    BYTE byte;
    byte = input.get();
    printf("%i, ", byte);
    counter++;
  }
  printf("\r%i, ", counter);
  input.close();
} else {
  printf("Can't open file!");
}

很感谢任何形式的帮助。

最高

Answer 1

使用ifstream input (PATH, ios::in);，可以以（默认）文本模式打开文件。在文本模式下打开文件时，标准库会对从文件读取的数据执行特定于平台的转换，以将文本文件的平台本机格式映射到C（和C ++）具有文本文件的视图中。

对于类似Unix的系统（包括Mac OSX和Linux），本机文本格式与C和C ++查看文本的方式相同，因此无需进行转换。

在Windows平台上，必须转换行尾（'\n'在字符序列之间进行转换CR LF），并且1A必须解释Windows定义的EOF字符（）。

在其他系统上，可能需要进行更广泛的转换（例如，如果将文本文件指定为正好包含80个字符的空格行，则实现将不得不'\n'在读取80个字符后自行生成一个字符，并且它可能会抑制一行中的尾随空格字符）。