对于类似Unix的系统(包括Mac OSX和Linux),本机文本格式与C和C ++查看文本的方式相同,因此无需进行转换.在Windows平台上,必须转换行尾(将'\n'转换为字符序列CR LF或从其转换),并且必须解释Windows定义的EOF字符(1A). /p>在其他系统上,可能需要进行更广泛的转换(例如,如果将文本文件指定为正好包含80个字符的空格填充行,则实现必须不得不在读取80后本身生成一个'\n'字符字符,并且可能会抑制一行中的尾随空格字符.)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.103As 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 codeifstream 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可以读取?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持! 上岸,阿里云!
09-05 18:51
查看更多