为什么Windows无法读取0x1A(EOF)字符以外的字符，而Unix可以读取? [英] Why can Windows not read beyond the 0x1A (EOF) character but Unix can?

问题描述

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

我正在编写一个小程序，它在Mac OS和Ubuntu(Unix ...)上运行良好.程序必须读取数据文件，并将字节(char s/unsigned char s)和memcpy()分成浮点数.这将包括采用以下四个值进行阅读和阅读的过程.左移它们到32位int中，然后将int的存储器复制到float中.像这样:

0x43 0x66 0x1A 0x79 -> read in int32 and memcpy() into 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!");
}

非常感谢您的帮助.

最大

解决方案

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

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

在Windows平台上，必须转换行尾(将'\n'转换为字符序列CR LF或从其转换)，并且必须解释Windows定义的EOF字符(1A). /p>

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

Possible Duplicate:
Why failbit set when eof on read? Is there a way out?

I am writing a little program and it was working brilliantly on Mac OS and Ubuntu (Unix...). The program has to read in a data file and separate the bytes (chars / unsigned chars) and memcpy() them into floats. This would include the process of taking say the following four values, reading & left shifting them into a 32bit int and then copying the ints memory into a float. Like so:

0x43 0x66 0x1A 0x79 -> read in int32 and memcpy() into float -> val = 230.103

As I said, this works fine for Unix, but Windows seems to interpret the char 0x1A as an end of file (EOF) error and stop reading in data. Why does Windows do such a thing and not Unix? And how could I turn it off?

I even tried error handling by looking at the ifstream itself and check if the EOL flag has been set. Then I would clear() the ifstream's error flags and continue reading (using get()) but the damn thing always returns the same EOF / 0x1A character and does not read in the next character.

EDIT: Added some code

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!");
}

Any help is very much appreciated.

Max

解决方案

With ifstream input (PATH, ios::in);, you open the file in (the default) text mode. When a file is opened in text mode, the standard library performs platform-specific conversions on the data read from the file to map the platform's native format for text files into the view that C (and C++) has of a text file.

For unix-like systems (including Mac OSX and Linux), the native text format is the same as how C and C++ view a text, so no conversions are needed.

On Windows platforms, the line-endings have to be converted ('\n' is converted to and from the character sequence CR LF), and the EOF character that Windows defines (1A) has to be interpreted.

On other systems, more extensive conversions might be needed (for example, if a text-file is specified as space-padded lines of exactly 80 characters, the implementation will have had to generate a '\n' character itself after reading 80 characters, and it might suppress the trailing space characters in a line).

这篇关于为什么Windows无法读取0x1A(EOF)字符以外的字符，而Unix可以读取?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！