背景

最近項目中弄個接口，涉及到二進制文件處理，剛開始對讀寫文件夾這塊沒有太注意，結果最后浪費了一些時間。

文件大小600+k(不到一兆)，二進制存儲，總長度638208個字節，如下：

正文

最初，通過fopen打開文件，如下：

/* 打開文件*/

if((fp_input = fopen(strFilePath.GetBuffer(), "r")) == NULL)

{

MessageBox("Can't open intput file!");

}

然后獲取文件的總長度，如下：

/* 獲取文件總長度(總字節數) */

long filesize(FILE *stream)

{

long curpos, length;

curpos = ftell(stream);

fseek(stream, 0L, SEEK_END);

length = ftell(stream);

fseek(stream, curpos, SEEK_SET);

return length;

}

一切看似都很正常，文件能打開，總長度獲取也沒問題，然后就是通過fread讀取文件內容了，如下：

/* 讀取文件內容 */

if(fread(str_file, 1, flength, fp_input) == 0)

{

MessageBox("Can't read file!");

return;

}

OK，下面就開始根據接口格式解析文件內容了。

問題也就出來了，明明文件總長度為638208個字節，但每次處理到629000+個字節后程序就崩掉了。開始我以為是我解析代碼里面內存沒處理好造成內存溢出了，然后我就把所有分配內存的地方注釋掉，發現還有問題。調了一段時間后，我就在函數入口的地方直接偏到629000+的位置看了內存里面的內容，發現竟然為空。現在就定位了問題出在前面的讀文件，往前看代碼，發現fopen的時候用的“r”，改成“rb”，重新跑了下程序。OK了，OK了，OK了，為什么？

為什么用“r”和“rb”都能讀取文件內容，但讀出來的東西卻不一樣了？

帶著疑問，在網上搜了一把(之前確實沒注意過這個問題，也沒遇到過)，發現真有這樣的問題，原因如下：

先看一段MSDN：

If the given stream is opened in text mode, carriage return–linefeed pairs are replaced with single linefeed characters. The replacement has no effect on the file pointer or the return value.

就是說如果按“文本模式”打開一個文件，那么在讀入的時候，Windows默認的換行符CR+LF就會轉換成一個單個的LF。

引自：https://blog.csdn.net/tgdzsjh/article/details/32702073

r遇到0x0d后面沒有0x0a會自動加一個，遇到0x1a會忽略后面的內容

rb不會

r 讀到\r\n會改為\n,讀到\x1a會返回EOF

rb 讀到什么返回什么,讀到文件末尾才會返回EOF

引自：https://blog.csdn.net/cattylll/article/details/7107089

總結

以上是生活随笔為你收集整理的java实现fread_fread函数读取到的数据和实际数据不一样的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。