c语言中能保存程序但不能读取,c语言文件操作，读取二进制文件发现0x1A读取不了...

1.  发现读到0x1A的时候 文件无法往下读取

参考：

这种现象目前只发现存在于windows中，unix/linux没有。为什么会这样呢？

0x1A在ASCII码中代表EOF，在过去，ASCII码EOF曾经在unix/linux中被作为文件结束符使用，微软继承了这个传统，也以EOF作为文件的结束符，不过，笔者手里的一些资料表明，微软在dos5.0以后就抛弃了这种做法。但实际情况是，笔者在dos6.22、windows3.1、windows3.2、windows9x、windows2k、xp、2003都存在这种问题。同时，这种问题是系统还是库函数造成的也有待进一步查证，由于没有源码，无法证实，如果哪位朋友有这方面的资料，希望可以共享。另一方面，鉴于dos/windows下所有主流编译器例如VC、BCB、gcc、tc2.0、bc3.1等都是同样的结果，笔者倾向于这是系统原因造成的。

大部分的系统都会发生这样的情况。

解决方法就是：

如何解决这个问题？其实标准已经给出了其中一种解决方法，由于二进制方式的输入输出是一一对应的，字符不会产生变化，那么用二进制读取就不会产生这个问题，事实也证明是可以的，只是存在一点麻烦，由于windows下会把/n转换为/r/n，二进制读取时必须对此转换进行堙别和还原，这会增加代码的复杂性，这种麻烦很让人讨厌。因此笔者尝试在低级函数中寻找更好的答案，但让人失望的是几款主流编译器的低级函数即使在文本方式下都没有对/r/n进行转换，由于低级函数的行为跟标准无关，如果有哪款编译器的低级函数对/r/n进行了还原，那就是比二进制方式更好的解决方法。

但无论如何，以上方法都不完美，这是否意味着windows的文本方式没有任何意义？这实在让人沮丧。如果哪位朋友对此有深入的研究，欢迎一起讨论。

2.大小端转换的问题：

检查大小端：

int checkCPU( )

{

{

union w

{

int a;

char b;

} c;

c.a = 1;

return(c.b ==1);

}

}返回1代表小端，返回0代表大端。

转换函数还没找到。

3.对齐

结构体对齐需要使用pack() #pragma pack(1)

typedef struct _FDT_RawDataHeader_

{

WORD        wSize;

BYTE        byReserved[6];

ULONGLONG   ullSystemTime;

} FDT_RawDataHeader, *PFDT_RawDataHeader;

#pragma pack()

4.fopen后面跟的路径如果有\要换成\\

如果是当前目录则使用.\\如果是上一级目录则是..\\

5.显示所有文件名的参考代码

#include      #include      #include      using namespace std;    void   filesearch(string path,int layer)      {              struct _finddata_t   filefind;              string  curr=path+"\\*.*";              int   done=0,i,handle;              if((handle=_findfirst(curr.c_str(),&filefind))==-1)  return;                while(!(done=_findnext(handle,&filefind)))              {              printf("测试的--%s\n",filefind.name);                   if(!strcmp(filefind.name,"..")){                   //文件为返回上一级不处理  continue;                   }                                      for(i=0;i>path;              filesearch(path,0);              system("PAUSE");              return   0;      }      用c++写的