字節沒有類型。當某些語言類型(如字符或字符串或Long)中的數據被轉換爲字節並寫入文件時,沒有嚴格的方式來說明類型是什麼:所有字節看起來相似,數字從0到255。
爲了瞭解,並從字節轉換回結構的語言類型,你需要知道的是,文件格式書寫的。
例如,你可能知道該文件被寫成ascii文本文件,因此每個字節代表一個ASCII字符。
或者您可能知道您的文件是以{uint} {50字節的字符串} {linefeed}格式編寫的,其中前2個字節表示一個uint,下一個50個字符串,後跟一個換行符。
因爲所有的字節看起來都是一樣的,所以如果你不知道文件格式,你不能以正確的語義讀取文件。例如,我可能會通過寫出一些ascii文本向您發送一個我創建的文件,但我可能會告訴您該文件充滿了2個字節的提示。你會寫一個程序來讀取這些字節作爲2字節的提示,它會工作:任何2個字節可以解釋爲一個uint。我可以告訴其他人,同一個文件是由4個字節組成的,他們可以把它看作4個字節長:任何4個字節都可以被解釋爲長整型。我可以告訴別人該文件是一個2字節的uint,後面跟着6個ascii字符。等等。
許多類型的文件都有一個定義的格式:例如Windows可執行文件或Linux ELF二進制文件。
如果您知道文件存在的原因,您可以猜測文件中字節的類型。但不知何故,你必須知道,然後你根據文件格式描述來解釋這些字節。
你可能會認爲「我會用描述它們的標記寫入字節,所以讀取程序可以知道每個字節的含義」。例如,具有'1'的字節可能意味着接下來的2個字節表示一個uint,具有'2'的字節可能意味着下面的字節告訴字符串的長度,並且之後的字節是字符串,所以上。當然,你可以做到這一點。但是(a)閱讀程序仍然需要了解這個約定,所以我上面所說的所有內容都是真實的(它始終是烏龜),(b)該方法使用大量空間來描述文件,以及(c)閱讀程序需要知道如何解釋動態描述的文件,該文件僅在某些情況下有用,並且可能意味着存在描述嵌入式元格式含義的元元數據格式。長話短說,所有字節看起來都是一樣的,並且必須告訴閱讀程序在這些字節能夠有意義地使用它們之前所代表的內容。
術語:寫這樣的文件稱爲序列化;閱讀,反序列化。 –