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( )
c;c.a = 1;
return(c.b ==1);
}}返回1代表小端，返回0代表大端。
轉換函式還沒找到。
3.對齊
結構體對齊需要使用pack()
#pragma pack(1)
typedef struct _fdt_rawdataheader_
fdt_rawdataheader, *pfdt_rawdataheader;
#pragma pack()
4.fopen後面跟的路徑如果有\要換成\\
如果是當前目錄則使用.\\如果是上一級目錄則是..\\
5.顯示所有檔名的參考**
#include
#include
#include
using namespace std;
void filesearch(string path,int layer)
for(i=0;i
cout<<" ";
if ((_a_subdir==filefind.attrib)) //如果該檔案是資料夾
用c++寫的
C語言二進位制檔案讀取解析
filedefine.h ifndef filedefine h define filedefine h include using namespace std 檔案操作，對磁碟的讀寫 fopen 開啟模式 和 快取區大小 開啟模式 input output b binary 沒有b修飾的是預設as...
用 C 讀取二進位制檔案
當想到所有檔案都轉換為 xml時，確實是一件好事。但是，這並非事實。仍舊還有大量的檔案格式不是xml，甚至也不是ascii。二進位制檔案仍然在網路中傳播，儲存在磁碟上，在應用程式之間傳遞。相比之下，在處理這些問題方面，它們比文字檔案顯得更有效率些。在 c 和 c 中，讀取二進位制檔案還是很容易的。除...
二進位制讀取檔案內容 C
filestream tempstream new filestream filename,filemode.open binaryreader tempreader new binaryreader tempstream,system.text.encoding.default char cc t...