Linux文件结构FILE,与普通open,read,write对比
2012-04-15 21:21
267 查看
做毕设的过程中想实现数据的保存,但是遇到的问题一大堆,本来打算用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.
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.
相关文章推荐
- 了解open/read/write/close等文件相关系统调用接口,纵向对比fd与FILE结构体
- file operate in python (open write read close )
- How to open/read/write a local file from an applet
- [Ruby笔记]4. ruby 读写文件 File open read write new
- babyos2(20) simple file system (2), file, open, close, read, write
- open/read/write/close等文件系统调用接口以及fd与FILE的比较
- 【体会Python之美】【文件】file,open,read,readline,readlines,write,close
- ReentrantReadWriteLock和两种同步方式的对比
- GPG key retrieval failed: [Errno 14] Could not open/read file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql
- Linux系统开发 2 文件IO open() close() read() write() perror() lseek() fcntl() ioctl()
- Read and Write File Code
- open/read/write和fopen/fread/fwrite的区别
- linux下 open() write() read() close函数
- Gvim 在进行文件对比时报cannot read or write temp files
- Linux基础编程-文件操作open,lseek,read,write,close
- read file in kernel (flip_open and flip_close)
- csharp:using OpenXml SDK 2.0 and ClosedXML read excel file
- Linux 文件IO函数(open/close/read/write/lseek)
- Open、Read、Write、Lseek、Close、Create、Delete、chdir系统调用
- linux文件操作函数(open、write、read、close)