Linux文件结构FILE,与普通open,read,write对比

做毕设的过程中想实现数据的保存，但是遇到的问题一大堆，本来打算用sqlite的，但是由于存储速度及复杂性，还是用file实现。

1. linux 中 open ,read, write 这些都是用来写文件描述符的，但是对于文件操作还是不是很清楚！！！

！！！！！！！！！先MARK一下。！！！！！！！！

2.读取的时候总是只能读一行， fread, fwrite, fclose。

3.写数据的时候只写一行，在FILE结构中，要用 at

文件使用方式 　　　　　　　       意 义

• “rt”　　　　　　只读打开一个文本文件，只允许读数据 
• “wt”　　　　　　只写打开或建立一个文本文件，只允许写数据
• “at”　　　　　　追加打开一个文本文件，并在文件末尾写数据
• “rb”　　　　　　只读打开一个二进制文件，只允许读数据
• “wb”　　　　 　 只写打开或建立一个二进制文件，只允许写数据
• “ab” 　　　　 　追加打开一个二进制文件，并在文件末尾写数据
• “rt+”　　　　　 读写打开一个文本文件，允许读和写
• “wt+”　　　　　 读写打开或建立一个文本文件，允许读写
• “at+”　　　　　 读写打开一个文本文件，允许读，或在文件末追加数据
• “rb+”　　　　　 读写打开一个二进制文件，允许读和写 
• “wb+”　　　　　 读写打开或建立一个二进制文件，允许读和写
• “ab+” 　　　　　读写打开一个二进制文件，允许读，或在文件末追加数据

4.FILE中用的EOF=-1,这个看看下面的

(1) 字节的读取 
在正常的情况下, getc 以 unsigned char 的方式读取文件流, 扩张为一个整数,并返回. 换言之, getc 从文件流中取一个字节, 并加上24个零,成为一个小于256的整数,然后返回.

int c; 
while ((c = fgetc (rfp))!= -1) // -1就是 EOF 
fputc (c, wfp); 

上面 fputc 中的 c 虽然是整数, 但在 fputc 将其写入文件流之前, 又把整数的高24位去掉了, 因此 fgetc, putc 配合能够实现文件复制. 到目前为止, 把 c 定义为 char仍然是可行的, 但下面我们将看到,把 c 定义为 int 是为正确判段文件是否结束. 


(2) 判断文件结束. 
多数人认为文件中有一个EOF,用于表示文件的结尾. 但这个观点实际上是错误的,在文 件所包含的数据中,并没有什么文件结束符. 对getc 而言, 如果不能从文件中读取, 则返回一个整数 -1,这就是所谓的EOF. 返回 EOF 无非是出现了两种情况,一是文件已经读完; 二是文件读取出错,反正是读不下去了. 


请注意: 在正常读取的情况下, 返回的整数均小于256, 即0x0~0xFF. 而读不出返回的是 0xFFFFFFFF. 但, 假如你用fputc把 0xFFFFFFFF 往文件里头写, 高24位被屏蔽,写入的将是 0xFF. // lixforalpha 请注意这一点 


(3) 0xFF 会使我们混淆吗? 

不会, 前提是, 接收返回值的 c 要按原型定义为 int. 
如果下一个读取的字符将为 0xFF, 则 

int c; 
c = fgetc (rfp); // c = 0x000000FF; 
if (c != -1)     // 当然不等, -1 是 0xFFFFFFFF 
fputc (wfp);    // 噢, OXFF 复制成功. 


字符0xFF, 其本身并不是EOF. 


(4) 将 c 定义 char 

假定下一个读取的字符为 0xFF 则 

char c; 
c = fgetc (rfp); // fgetc(rfp)的值为 0x000000FF, 暗中降为字节, 


c = 0xFF 
if (c != -1)     // 字符与整数比较? c 被带符号(signed)扩展为


0xFFFFFFFF, 喔噢, 
条件成立,文件复制提前退出.  


while ((c=fgetc(rfp))!=EOF) 中的判别条件成立, 文件复制结束! 意


外中止. 


(5) 将 c 定义为 unsigned char; 


当读到文件末尾, 返回 EOF 也就是 -1 时, 


unsigned char c; 
c = fgetc (rfp); // fgetc (rfp)的值为EOF,即-1,即0xFFFFFFFF, 降


格为字节, c=0xFF 
if ( c!= -1)   // c 被扩展为 0x000000FF, 永远不回等于 


0xFFFFFFFF 


所以这次虽然能正确复制 0xFF, 但却不能判断文件结束. 事实上,在 c 


为 uchar 时, 
c != -1 是永远成立的, 一个高质量的编译器, 比如 gcc会在编译时指


出这一点. 


(6) 为何需要feof? 
FILE *fp;  
fp 指向一个很复杂的数据结构, feof 是通过这个结构中的标志来判断


文件是否结束的. 
如果文件用 fgetc 读取, 刚好把最后一个字符读出时, fp 中的EOF标志


不会打开,这时 
用feof判断,将会得到文件尚未结束的结论. 


fgetc 返回 -1 时, 我们仍无法确信文件已经结束, 因为可能是读取错


误! 这时我们 
需要 feof 和 ferror.