关于文本模式和二进制模式对文件进行操作的区别

看到这个标题可能很多人会说:“不就是文本模式下系统会对其中的换行符进行转义吗!”以前我也是这么想的,但是最近又有些迷糊了……


之前在做数据结构的课程设计,我选的题目是huffman编码对文本文件进行压缩。

手痒的我把自己的程序在图片上试了试,压缩出来的文件出奇的小……其压缩率甚至超过了专业的压缩软件……不用想……肯定是数据读写过程中漏掉了很多东西,

或许是在读取过程中提前遇到了EOF导致数据根本就没读完;

或者写入时文件中某些数据的值和EOF相同,导致文件系统错误判断了文件的大小,自作主张把后面那一截都切掉了?


后者的可能性应该是很小的(当然,我是菜鸟,我什么都不知道……),毕竟文件系统可不是一个字符串(以0为终止),来个 -1 就把这个文件的后面一截都给掐了……

而且这种情况以我目前的水平也完全没法进行测试,于是我开始着手对读取过程进行测试。

以下为我的测试代码的框架,其中cloud1.jpg是一张1366*768的图片。

#include <stdio.h>
#include <stdlib.h>
#include <conio.h>

int main( void )
{
   FILE*pf = fopen( "I:/多媒体/图片/cloud1.jpg" , "r" );
   int n = 0;
   int i = 0;
   while( ( n = fgetc( pf ) ) != EOF )
   {
      i++;
   }
   printf( "i=%d,n=%d" , i , n );
   getch();
   return 0;
}

通过修改保存 fgetc 的返回值的容器 n 的数据类型( char 或 int ),以及文件的打开模式( r 或 rb ),我得到了以下三组数据(char+r没测试):

第一组:【char + rb 】:貌似jpg图片的开头第一个字节就是0xff,所以用char来装这个返回值的话马上就被当成了EOF,结束了循环……



第二组:【int + rb】这组数据是正确的,计数器i准确地记录的整个文件的字节数,可以看到它与系统给出的信息482KB是相同的。



第三组:【int + r】:这一组是问题所在——显然文件的读取提前结束了!



我不禁在想,EOF到底是个什么东西!!??难道仅仅只是 -1 吗?确实,用char来装这个返回值时,0xff 就是-1,但是为什么用了足够大的 int 类型之后,两种模式会出现不同呢?这里面到底是什么原因?恳请大神帮忙分析之!!!

感激不尽!!!

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值