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

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

之前在做数据结构的课程设计，我选的题目是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 类型之后，两种模式会出现不同呢？这里面到底是什么原因？恳请大神帮忙分析之！！！

感激不尽！！！