神秘的文件结束到底是什么判断出来的？

我用文本形式打开了一个文件，在文件中段有一部分二进制码，我使用的是fistream.eof()作为文件结束的判断，但是文件在读到那段二进制码时就认为整个文件结束了，我想应该是那段二进制码出现了文件结束的标志符，于是我有以下几个问题：
1.看到有文章说，对二进制文件必须使用二进制形式打开，并且使用feof（）来判断。但是我的文件基本上是文本形式，只有一小段二进制码，我使用的是一行一行的处理形式，用二进制打开会对程序有很大改动吗？
2.莫非对与二进制打开和文本打开，判断文件结尾的方式不同，到底哪个神秘的文件结束符号是什么，函数又是怎么判断的啊？
3.难道fistream.eof()和feof（）不只是封装使用的不同，为什么fistream.eof（）不行啊？
megaboy(点背不能怨社会，命苦不能怪政府！) 于 2005-8-14 13:10:02
其实二进制方式和文本方式判断文件结束的方式是一样的，都是遇到EOF就认为文件结束，EOF是一个宏，它代表了-1这个值，如果在文件当中读到了0xff或者到了文件末尾，文件结构指针里面的flags字节的_F_EOF位都会被置为1，这一位被置为1，库函数就会认为到了文件末尾了。函数feof()其实是一个类函数宏，这个宏就是通过把文件结构指针的flags字节跟_F_EOF进行与运算来检测_F_EOF是否为1，并判断是否到了文件末尾的。这个函数具有与下面类似的代码：

#define feof(f) ((f)->flags & _F_EOF)

对于flags和_F_EOF，不同的编译器可能有不同的标识符。


megaboy(点背不能怨社会，命苦不能怪政府！) 于 2005-8-14 13:19:00
噢，更正一下，忘记了feof是返回值为0表示遇到文件末尾的。上述那个_F_EOF应该是被置为0表示文件末尾，而feof是通过检测flags跟_F_EOF相与的结果是否为0来判断文件是否到了末尾。
newbiestar 于 2005-8-14 13:35:26
feof返回非0才是到达文件结束
51365133(渊海) 于 2005-8-14 13:38:45
TO megaboy(想忘记，却更是不能忘记！)

“其实二进制方式和文本方式判断文件结束的方式是一样的” 感觉有点问题

文本文件的结束是-1，但是有的时候2进制文件中可能会出现-1，所以引用了int eof(int handle)
51365133(渊海) 于 2005-8-14 13:40:02
#include <io.h>
检测文件指针是否已在尾部
int eof(int handle)

handle 已打开的文件句柄

1-文件结尾，0-不在结尾位置，-1 操作出错
megaboy(点背不能怨社会，命苦不能怪政府！) 于 2005-8-14 14:33:33
eof是系统输入输出函数，使用低级文件句柄。它检测EOF的方式跟feof其实是相同的，只不过它检测的不是标准文件结构指针里面的_F_EOF标志，而是_O_EOF标志，这个标志存在于文件柄属性字节里头，跟_F_EOF一样，如果文件遇到0xff或者文件末尾，会设置_O_EOF。

文本方式跟二进制方式其实只有一个区别，那就是文本方式输入时会把/n(0A)解释为0D0A，输出时会把0D0A重新复原为/n(0A)。除此之外，文本方式跟二进制方式是一样的。但是，并不是所有标准文件函数都会进行这个转换的，字节级的函数比如fread和fwrite等是无视这个转换的。

Agener 于 2005-8-14 15:20:51
那到底，我改怎么办呢？看了半天我还是没有看出，二进制中出现了0xff，到底该怎么判断文件结束，按照 megaboy(想忘记，却更是不能忘记！) 的说法，feof()也没有办法回避0xff的歧义啊！
为什么其他的软件，例如textpad，能够正确的判断文件结束？
megaboy(点背不能怨社会，命苦不能怪政府！) 于 2005-8-14 16:50:09
刚刚查阅了一些更详细的资料，发现我所说的那种把-1当作文件结束标记的情况并非发生在所有的操作系统上。某些操作系统特别是早期的操作系统有不少就把-1看作文件结束标记，但现在的操作系统多数来说不再以这种方法判断文件结束，而是直接比较文件的大小，DOS、windows和一部分unix/linux就是以文件大小来判断的，当超过文件大小读的时候，就会设置_F_EOF和_O_EOF位。

不知道楼主使用什么操作系统。如果是dos和windows，那么产生你的问题的原因应该就不是读到文件尾了。
kl222 于 2005-8-14 17:04:05
你可以采用判断读入数据与文件的长度来确定是否结束.
Agener 于 2005-8-14 18:41:18
我用的是windows，但是就是在文件中间出现0xFF 就截断了：
ifstream m_ifstream(inputfile);
while(!m_ifstream.eof()){//标记文件结束
m_ifstream.getline(rdbuff1,100000);
……
}
就是这样，难道ifstream.eof()不是采用比较文件大小的方式？
怎么样获得一个文件的大小呢？
jixingzhong(瞌睡虫（既然选择了远方,那就只有风雨兼程了！！）) 于 2005-8-14 18:58:35
程序判断文件是否结束， 是看的文件结束标志！ 要注意的是， 不是说文件结束标志必须出现在文件的末尾才行的， 这个标志可以在文件的任何位置！
megaboy(点背不能怨社会，命苦不能怪政府！) 于 2005-8-14 19:28:29
我觉得不是的，虽然表面上看来好象有ff的地方就断掉，但可能是其它原因引起的。在windows里的确不是靠检测ff来判断的，我刚刚验证了一下，写了十个字节的数据，后面六个全写ff，一样很准确的判断出文件末尾在十个字节之后。
doway(john) 于 2005-8-14 20:16:22
mark
Agener 于 2005-8-14 22:15:55
不会吧，你们留一个信箱，我把文件传给你们看看。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
jixingzhong(瞌睡虫（既然选择了远方,那就只有风雨兼程了！！）) ： 程序判断文件是否结束， 是看的文件结束标志！ 要注意的是， 不是说文件结束标志必须出现在文件的末尾才行的， 这个标志可以在文件的任何位置！
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
如果真是这样，文件中间无意出现了结束符，那么程序岂不是根本无法正确判断文件结束了？标准函数库中的这个函数岂不天生固有这个一个大bug？？到底我的文件该怎么判断结束！！！还请指教！

snowbirdfly(胡晋) 于 2005-8-14 23:19:01
收藏了`
感谢楼主~~~
DiabloWalkOnTheEarth(WorldOfWg( 狗城是个烂代理 )) 于 2005-8-14 23:29:26
WIN下文本模式打开好像是26 ( ^Z )表示EOF 地. 要保险还是二进制方式读取吧...
jixingzhong(瞌睡虫（既然选择了远方,那就只有风雨兼程了！！）) 于 2005-8-15 11:31:38
我 错 了 ~~~

大家不要学我的 ~~
jixingzhong(瞌睡虫（既然选择了远方,那就只有风雨兼程了！！）) 于 2005-8-15 11:35:22
看 newbiestar() 的！
liixixi 于 2005-8-15 11:45:51
>DiabloWalkOnTheEarth(WorldOfWg( 狗城是个烂代理 )) says:
>> WIN下文本模式打开好像是26 ( ^Z )表示EOF 地. 要保险还是二进制方式读取吧...

这个是正解， 就是说， 如果以文本模式打开文件， 遇上26（sub）就是eof了， 你的二进制代码里肯定有sub。

至于这个问题， 其实是dos的历史问题遗留来的， 具体的原因忘了。

上面有人说这个和/r/n等有关系， 其实这个在不同平台下是不一样的， 和文本/二进制没本质联系。

文本/二进制文件本身是没有区别的， 在c语言中打开的时候， 唯一区别就是对sub的解释不一样， 恩， win下对/r/n的解释也不一样， 呵呵。



doway(john) 于 2005-8-15 12:21:07
dewey60@126.com

楼主的那个文件请发给我一份，我也正在学习IO部分内容，很有兴趣。想看一看具体文件的模式，想出个解决办法。


newbiestar 于 2005-8-15 12:35:59
回复人： jixingzhong(瞌睡虫（既然选择了远方,那就只有风雨兼程了！！）) ( ) 信誉：101 2005-08-15 11:35:00 得分: 0


看 newbiestar() 的！

=====================================
看我的干什么……-_-bbbb

Ctrl Z是command.com（Windows下面是CMD.exe）这个shell对EOF自己做的规定，算不得数，Unix的Shell一般都是用Ctrl D的，Ctrl Z在Unix控制台里面一般都不是EOF（不排除有某些比较BT的变种这样实现的可能，但是一般都是job control里面的内容）

EOF根本不可能存在于文件中（想想看也知道文件结束怎么可能存在于文件中呢？），一般只有某些函数会返回这样的值，譬如getc之类的。但是绝对不是0xff就会导致文件结束，这个是对getc这一族函数的误用导致的。
SammyLan(没有窍门，只有努力.LOVE 33 4 Ever) 于 2005-8-15 12:52:21
其它的说太多没用
fostream.eof()这个函数和C的feof()这个函数可以判断文件结尾

Wolf0403(完美废人)(CSDN，请不要侮辱 Linux) 于 2005-8-15 18:57:29
不知道 Win32 的 ReadFile 是如何， Linux 中的 syscall read(2) 当读取到一个文件结束的时候会返回 0。只有这种情况表示真正的 EOF。换言之，当文件系统读取一个文件到真实结尾的时候会向调用程序返回 0，而 EOF 这个宏则是 C 库封装过的一个标志罢了。C 标准库的『游戏规则』就是用 feof 来判断一个 FILE * 是否被读取到了文件结束的地方。想要绕开这个规则就去看更底层的东西吧。

Agener 于 2005-8-16 11:16:56
果然是26，我删掉后就正常了，不过我还是有疑惑，二进制打开的文件也能一行一行的读吗，就是那个ifstream::getline()能用吗?
newbiestar 于 2005-8-16 11:54:13
怎么可能和26有关系？

char buf[] = {26, 0x26, 026};
int ch;
FILE* w_fp = fopen("file", "w ");

fwrite(buf, 1, 3, w_fp);
rewind(w_fp);

while((ch = fgetc(w_fp)) != EOF)
{
printf("%d/n", ch);
}

我就不信不产生三行输出！
megaboy(点背不能怨社会，命苦不能怪政府！) 于 2005-8-16 11:58:20
用下面的程序试了一下，真的哦，是26这个EOF造成的，倒了，没想到，竟然发生这种事情，不过无论如何，算是又长了一智。

FILE * fpFile;
char test[10]={'a','b','c',26,'d','e','g'};
fpFile = fopen("test.txt", "w");
fwrite(test, sizeof(char),7,fpFile);
fclose(fpFile);
fpFile = fopen("test.txt", "r ");
fread(test, sizeof(char), 3, fpFile);
printf("%d/n", feof(fpFile));
fread(test, sizeof(char), 4, fpFile);
printf("%d/n", feof(fpFile));
fread(test, sizeof(char), 5, fpFile);
printf("%d/n", feof(fpFile));
fread(test, sizeof(char), 8, fpFile);
printf("%d/n", feof(fpFile));

结果是0 32 32 32。

再进一步试验，分别用文本方式和二进制写读文件，发现这个规律：

跟写入的方式无关，而跟读取的方式有关，如果用文本方式读，结果就是0 32 32 32，用二进制方式读，结果就是0 0 32 32。
newbiestar 于 2005-8-16 12:24:24
这个是Windows下面的库带来的问题（可能和Windows内核有关，因为VC 自带的库实现代码里面没有找到这样的处理，要不就是VC 实际用的库不是一个东西），反正Unix下面没这个问题，文本模式和二进制模式一样
ben_na(笨笨) 于 2005-8-16 12:53:50
这里有一篇我blog上的关于C 读取二进制文件的文章
可能可以说明一些问题

C 读写二进制文件

前几天写一个音频隐藏程序时碰到点问题，要读写二进制文件。
一开始，我的程序看起来像是这样:

//...
static string FILENAME = "test.wav";

ifstream iStream;
iStream.open(FILENAME.c_str());

char buffer[1024];
while (iStream.read(buffer, sizeof(buffer) / sizeof(char))) {
//...这里对读到的字节进行处理
}

iStream.close();
//...

可是循环几次后就“无故”跳出，文件根本没读完，可是程序码好像也没错。

为了测试二进制的读取，我特地写了个程序， 看起来像这样：

//...
static string FILENAME = "test.wav";

ifstream iStream;
iStream.open(FILENAME.c_str());

char ch;
while (iStream.get(ch)) {
cout << ch;
}

iStream.close();
//...

程序输出一部分字符后，就不再输出了,怎么回事？我把iostream以及fstreamr的读取、写入API都查了个便，好像没有什么发现，这段程序码

应该不会有问题的！

回忆以前写C代码的日子，fopen函数有个b参数，表示是二进制读写方式打开, 是否fstream也有二进制开启的参数？ 一查MSDN果然如此， 这

个参数是 ios_base::binary。


马上行动，以上程序改成这样：
//...
static string FILENAME = "test.wav";

ifstream iStream;
iStream.open(FILENAME.c_str(), ios_base::binary); // 二进制模式

char ch;
while (iStream.get(ch)) {
cout << ch;
}

iStream.close();
//...

哈哈，这回程序终于可以读取全部字节了，而且喇叭还嘟嘟地叫呢（二进制码当作字符输出，有些是空白，有的还会鸣喇叭(07h)，呵呵）。

可是为什么？读出都是字节，都是无格式，打开时以二进制和默认方式打开有什么区别吗？

别急，上面解决了怎么读，下面让我们"写"一点东西吧！

#include <iostream>
#include <fstream>
#include <string>

using namespace std;


int main() {
static string FILENAME = "test.txt";

ofstream oStream;
oStream.open(FILENAME.c_str()); // 标准（字符）模式打开哦

oStream << "Hello World!" << endl; // 写个换行符
oStream << "Hello World!";

oStream.close();
}

程序很简单，运行后产生test.txt文件，文件大小为26字节, 文件内容是这样：

Hello World!
Hello World!

明明是24个字节嘛，呵呵，算上一个换行符 0dh 0ah 就是26个字符了。 用ultra edit打开看是这样：

48 65 6C 6C 6F 20 57 6F 72 6C 64 21 0D 0A
48 65 6C 6C 6F 20 57 6F 72 6C 64 21

很清楚了吧！

下面我们把程序改成这样：

#include <iostream>
#include <fstream>
#include <string>

using namespace std;


int main() {
static string FILENAME = "test.txt";

ofstream oStream;
oStream.open(FILENAME.c_str(), ios_base::binary); // 二进制形式打开

oStream << "Hello World!" << endl; // 写个换行符
oStream << "Hello World!";

oStream.close();
}

运行后同样产生test.txt文件，咦！怎么少了一个字节（25个），打开后看是这样：

Hello World!
Hello World!

用ultra edit 打开，是这样：

48 65 6C 6C 6F 20 57 6F 72 6C 64 21 0A
48 65 6C 6C 6F 20 57 6F 72 6C 64 21

与上面比较可以得出，少了一个 0dh, 也就换不了行了。

有以了上对比，我们知道了C 标准IO流在字符模式下会对换行符进行扩展。

程序为例：

//...
oStream.open(FILENAME.c_str()); // 默认

char ch = 0x0a;

oStream << ch;
//...

输出两个字节: 0dh 0ah

如果是:
//...
oStream.open(FILENAME.c_str(), ios_base::binary); // 二进制模式

char ch = 0x0a;

oStream << ch;
//...

则只会输出: 0ah

相信现在对为什么在默认模式下读不到全部数据清楚了吧！ 人家见到0ah单独出现地晕了。

那么题外话： endl是什么？ 是 define endl '/n' ？ 不是， 在名字空间没有引入时我们要这样用呢： std::endl

源码之前无秘密

// 注，以下程序码和原来并不完全相同，为了可读性，我进行了一定修改

inline basic_ostream<char, char_traits<char> >&
endl(basic_ostream<char, char_traits<char> >& stream) {
stream.put('/n');
stream.flush();
return (stream);
}

哦， 原来endl是个函数。

为了更清楚，需要看看 << 的一个重载版本:

basic_ostream<char, char_traits<char> >&
operator<<(basic_ostream<char, char_traits<char> >&
(*pfn)(basic_ostream<char, char_traits<char> >&)) {
return ((*_Pfn)(*this)); // call basic_ostream manipulator
}

原来把endl当作函数指针传进去，在里面调用它，有了以上基础，我们可以写个自己的manipulator了。

inline basic_ostream<char, char_traits<char> >&
endl2(basic_ostream<char, char_traits<char> >& stream) {
stream.put('/n/n'); // 换两行
stream.flush();
return (stream);
}

这样以后这么调用 cout << "hello world!" << endl2; 就会在输出hello world!后换行并空一行啦！

OK， 我们可以像这样读取二进制文件：

//...
ifstream iStream;
iStream.open(FILENAME.c_str(), ios_base::binary);

char buffer[1024];
while (iStream.read(buffer, sizeof(buffer) / sizeof(char))) {
//...这里对读到的字节进行处理
}
//...


或者这样想一个字节一个字节读也行， 只是有点慢（我试着用这种方法copy一个10M的文件，等了我好久）：

//...
ifstream iStream;
iStream.open(FILENAME.c_str(), ios_base::binary);

char ch;
while (iStream.get(ch)) {
//...这里对读到的字节进行处理
}
//...

当然，习惯EOF的朋友可以这样:

//...
ifstream iStream;
iStream.open(FILENAME.c_str(), ios_base::binary);

int ch; // 注意，这里要整型，因为EOF为-1
while ((ch = iStream.get()) != EOF) {
//...这里对读到的字节进行处理
}
//...

虽然读取比写入更容易出错，但上面我们已经解决了读二进制文件。

让我们用二进制模式打开，写一些东西吧。

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

int main() {
static string FILENAME = "test.txt";

ofstream oStream(FILENAME.c_str(), ios_base::binary);
oStream << 1 << 2 << 3 << 4;
}

哦， 输出的是字符1234，因为默认的插入操作符是以字符形式输出的，应该改成这样：

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

int main() {
static string FILENAME = "test.txt";

ofstream oStream(FILENAME.c_str(), ios_base::binary);
int i1 = 1;
int i2 = 2;
int i3 = 3;
int i4 = 4;

oStream.write((char*)&i1, sizeof(i1));
oStream.write((char*)&i2, sizeof(i2));
oStream.write((char*)&i3, sizeof(i3));
oStream.write((char*)&i4, sizeof(i4));
}

有点麻烦哦，如果用上C 的安全转型static_cast,就更长了。当然，对于一个缓冲区来说，就简单多了。

//...
char buffer[1024];
...
oStream.write(buffer, sizeof(buffer));
//...

我们还可以像这样写结构体：

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

typedef struct tagTestStruct {
char c;
int i;
long l;
char buffer[8];
} TEST_STRUCT;

int main() {
static string FILENAME = "test.txt";

ofstream oStream(FILENAME.c_str(), ios_base::binary);

TEST_STRUCT myStruc;

myStruc.c = 'a';
myStruc.i = 1;
myStruc.l = 1l;
strcpy(myStruc.buffer, "hello");

oStream.write((char*)&myStruc, sizeof(TEST_STRUCT)); // 经过数据对齐，这里的sizeof(TEST_STRUCT)是20
}



doway(john) 于 2005-8-16 16:11:21
楼主发来的文件我看了，内容是对 3 个 HTTP 请求的响应。

第一个请求是 url: http://china-aoya.com/doce/gril2.htm，这个没有问题。

第二个请求是 url: http://ctmas.myetang.com/kejian/duominuo.fla，这个有问题，因为返回类型是：Content-Type: text/plain。这是一个 Flash 的源文件，看了一下 IIS 的 MIME设置，正确的返回类型应该是 application/octet-stream。

因此要想正确处理这个文件，楼主需要了解 Flash 的文件结构。楼主了解吗？哈哈，我也不了解。对于一个不了解的东西，我们又能怎么样呢？！

程序员不是闲人，更不是超人，有些事情不该我们干的。：）


Agener 于 2005-8-18 16:35:21
哈哈，谢谢楼上的兄弟，不过我的任务是跳过这一段代码，把后面的HTML读出来处理。不过现在我也不急着想了，偶师兄说他来摆平！我就等着拿结果了。
zhiri84(clz) 于 2005-8-18 23:09:29
高人
ahjoe(强哥) 于 2005-8-20 16:58:07
不能以文本方式打开处理二进制文件。
cppprogramlover(爱相随—) 于 2005-8-21 14:01:47
很简单，如果你的文本只有一段是二进制，那么这样（C）
int c;
while((c=getc(stream)!=EOF || !feof(stream))/**/;
效率是不会降低的，c 中类似。
cppprogramlover(爱相随—) 于 2005-8-21 14:02:48
如果真是这样，文件中间无意出现了结束符，那么程序岂不是根本无法正确判断文件结束了？标准函数库中的这个函数岂不天生固有这个一个大bug？？到底我的文件该怎么判断结束！！！还请指教！

直接用feof判断就不会了，象我上面说的那样
Agener 于 2005-8-23 20:34:55
谢谢了各位，我看可以结了