为什么 Windows 不能读取超出 0x1A (EOF) 字符但 Unix 可以? [英] Why can Windows not read beyond the 0x1A (EOF) character but Unix can?

查看:16
本文介绍了为什么 Windows 不能读取超出 0x1A (EOF) 字符但 Unix 可以?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

<块引用>

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

我正在编写一个小程序,它在 Mac OS 和 Ubuntu(Unix...)上运行良好.程序必须读入数据文件并将字节(chars/unsigned chars)和 memcpy() 分隔成浮点数.这将包括采用以下四个值的过程,阅读 &将它们左移为 32 位 int,然后将 int 的内存复制到 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 输入(路径,ios::in);如果(输入.is_open()){无符号整数计数器 = 0;而(输入.好()){BYTE 字节;字节 = input.get();printf("%i,", 字节);计数器++;}printf("
%i,", 计数器);input.close();} 别的 {printf("无法打开文件!");}

非常感谢任何帮助.

最大

解决方案

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

对于类 Unix 系统(包括 Mac OSX 和 Linux),原生文本格式与 C 和 C++ 查看文本的方式相同,因此不需要转换.

在 Windows 平台上,必须转换行尾(' ' 与字符序列 CR LF 相互转换),以及 EOF 字符必须解释 Windows 定义的 (1A).

在其他系统上,可能需要更广泛的转换(例如,如果文本文件被指定为恰好 80 个字符的空格填充行,则实现将不得不生成 ' ' 字符本身读取 80 个字符后,它可能会抑制一行中的尾随空格字符).

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("
%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 (' ' 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 ' ' character itself after reading 80 characters, and it might suppress the trailing space characters in a line).

这篇关于为什么 Windows 不能读取超出 0x1A (EOF) 字符但 Unix 可以?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆