前一陣子用C++寫東西,需要往文件里寫數據,很簡單的代碼,大概是這個樣子:
#include
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
ofstream fout;
fout.open("d://test.dat");
int a = 0x7788;
fout.write((char*) &a, sizeof(int));
}
打開test.dat,內容是77 88 00 00,很正常。
打開test.dat,內容是77 88 00 00,很正常。
但我要是把a的值改成0x0a,毛病就出來了,寫出來的東西是:0D 0A 00 00 00!
要是把a改成0x770a或者是別的什么0a,只要是數字中某一個字節是0a,寫出來以后肯定變成0D 0A!比如0x770a就變成0D 0A 77!
更讓人寒的是,即使規定寫出的只能是一個字節,即寫:
fout.write((char*) &a, sizeof(char));
只要a的值的高字節是0a,寫出來一樣變成0D 0A!也就是指定輸出1個字節,實際卻輸出了2個字節!
真是讓人費解啊。我一度認為C++出現了有史以來最莫名其妙的BUG,不過,且慢……
0A是什么?0D 0A又是什么?這個問題的解原來在這里。先查查C++的文檔,里面說明,ofstream的open函數,第二個參數指明打開方式,缺省為ios_base::out,即按照字節流的方式輸出文本。再看看0A到底是什么,原來ASCII的0A是換行,也就是/n,再想想,Windows系統下的換行是如何處理的?/r/n啊。原來……
原來按照字節流的形式輸出文本時,ofstream會自動將輸出的/n變成/r/n,以適應WIndows系統,結果以輸出數據的角度看來,這個正常的舉動就變成了不可解的“0A變成0D 0A”。
既然如此,答案也出來了,查查文檔,將打開文件的一句改成:
fout.open(“d://test.dat”, ios_base::out | ios_base::binary);
搗亂的0A終於歸位了。
ifstream讀取文件時,如果使用in>>ch方法,則ifstream會自動將空格去除,故0x20不會讀取,同樣加入讀取參數ios::binary后,問題解決。