對象本身是一個字節序列,這就是機器如何理解所有的數據,無論是對象,文本,圖像..等等。你能否清楚這個想法,爲什麼我們要將字節序列(對象)轉換爲另一個字節?當我們進行序列化時,我們是否重構字節,或者製作一個模板來保存這個對象,以便在通過網絡傳輸時給它一個特殊的含義?假設一種方法,即將內存中的對象保留原樣,並將該對象放入IP數據報並通過網絡發送出去,可能會出現什麼問題?序列化:將字節轉換爲字節?
0
A
回答
1
對象本身包括許多引用,其是指向其中對象的另一組件發生在這個特殊的時刻在存儲器中存在這種特殊的機器上。序列化的要點是它將對象轉換爲可以在其他某個機器上可以讀取的字節。
此外,內存中的對象表示已針對快速訪問和修改進行了優化,而不一定需要最少的字節數。一些序列化協議,尤其是用於RPC或數據存儲的序列化協議,優化了必須使用壓縮算法傳輸或存儲多少個字節,這使得訪問或修改對象的屬性變得更加困難,以換取使用更少的字節來做到這一點。
2
第一:壓縮。
你必須明白,從內存渲染磁盤和鏡像的文件圖像文件 - 是不一樣的。在磁盤上,它們(通常忘記BMP)被壓縮。憑藉當前的網絡吞吐量和硬盤容量,壓縮是必不可少的。
第二:架構。
內存中的數字只是一個比特序列,是的。但是,什麼位數被算作數字? 8? 16? 32? 64?任何一位。有字節,單詞,整數,長整數,浮點數(地獄,浮點!)和另外幾十個數字。而且參與者也很重要,所謂的大端和小端。因此,一臺(x86)機器上的123456789與另一臺機器上的數字不同(例如,x64)。
第三:文件(讀取:傳輸)格式!=內存對象格式。
那麼,文件(或網絡包)中的數據結構和從內存中的文件加載的對象之間存在差異。另外,內存中的對象結構可能因程序版本而異。在Win 3.1和f.e.中,加載到內存的映像是一個很大的區別。此外,結構填料和4-,8-,16-,32位邊界對齊等,等,等
0
對象本身是字節
號的對象的一個序列本身不是只是'字節序列',除非它只包含原始數據。它可以包含
- 引用
- 那些對象可能已經連載的其他對象,在這種情況下,反向引用需要序列化,而不是引用的對象一遍
- 這些提法可能空
- 有可能是沒有目標可言,只是原始數據
所有這些都增加了任務的複雜性遠遠超出了剛剛序列化「BYT序列中的天真想法ES'。
相關問題
- 1. 將java字節轉換爲c#字節(序列化問題)
- 2. 將hexdump轉換爲字節序列
- 3. Python 3.4將字節字節字節轉換爲字節對象
- 4. 將字節轉換爲字節[]
- 5. 如何將字節[]轉換爲字節[]
- 6. 通過反轉字節將小字節轉換爲大字節
- 7. 序列化與字節代碼轉換
- 8. 將不可序列化的對象轉換爲字節數組
- 9. 將字節轉換爲字節到字節
- 10. 將char轉換爲字節
- 11. 將字節[]轉換爲SAFEARRAY
- 12. 將字節[]轉換爲Int8
- 13. 將NSData轉換爲字節
- 14. 將UUID轉換爲字節
- 15. 將pandas.DataFrame轉換爲字節
- 16. 將NSString轉換爲字節
- 17. 將FloatBuffer []轉換爲字節[]
- 18. 將PDF轉換爲字節
- 19. 將字節轉換爲位
- 20. 將BitmapImage轉換爲字節[]
- 21. 將字節轉換爲SByte
- 22. 將HttpContent轉換爲字節[]
- 23. 將字節[]轉換爲JsonObject
- 24. 將UIImage轉換爲字節
- 25. 將字節轉換爲UIImage
- 26. 將sbyte轉換爲字節
- 27. 將字節[]轉換爲int
- 28. 將DataHandler轉換爲字節[]
- 29. 將IRandomAccessStreamWithContentType轉換爲字節[]
- 30. 將字節[]轉換爲PDF