我讀過關於數據庫與文件系統存儲文件的許多討論。這些討論大多討論圖像和媒體文件。我的問題是：數據庫與文件系統 - 對於非圖像文件和字節數
1）相同的參數是否適用於存儲.doc，.pdf，.xls，.txt？對於我應該注意的文檔文件有什麼特別之處？ 2）如果我以二進制形式存儲在數據庫中，如果我的主機交換機器，會不會有endian問題？例如，我將數據插入到big-endian機器中，然後將其移植到小端機器上，然後嘗試提取（例如，寫入文件，將其發送到我的桌面，然後嘗試打開）。
感謝您的任何指導！
1）是的，幾乎相同的論點適用於存儲PDF和什麼......任何被壓縮的東西也可以想到。
如果想要在不同字節序的主機之間移植，那麼每個非文本文件格式都必須處理字節序問題。他們主要是通過定義文件中長度超過一個字節的所有二進制字段的字節序應該是什麼。寫入和讀取格式的軟件必須特別注意字節交換，如果它運行在相反端的平臺上。圖像與其他二進制文件格式沒有區別。選擇是任意的，但大端（網絡字節順序）是一種流行的選擇，尤其是在網絡軟件中，因爲C中的宏無處不在，幾乎可以自動處理這些宏。
另一種定義二進制文件格式以便它們可以移植的方式是支持二進制字段的字節順序，並在標題中包含一個標記以表明哪一個被使用。在打開文件時，讀者請參考標記。通過這種方式，可以在寫入文件的主機或具有相同字節序的其他主機（這是常見的情況）下稍微更高效地讀取文件，而反向字節序的主機需要花費更多的努力。
至於數據庫，假設您使用的字段類型像blob，當您閱讀您所寫的任何內容時，您將獲得完全相同的字節流，因此您不必擔心該字節的字節順序數據庫客戶或服務器。
2）這取決於數據庫。通過定義上述的磁盤格式，數據庫可以使用與任何字節序兼容的底層磁盤格式。
儘管考慮（正確地）考慮將底層數據文件移動到不同字節順序的數據庫主機，但數據庫並不經常針對其底層文件格式的可移植性。例如，根據this answer，MySQL的MyISAM不是可移植的。
雖然我不認爲你需要擔心這一點。如果數據庫服務器被切換到不同的字節序的主機，確保數據保持可讀性是該過程的一個重要步驟，並且DBA處理任務（或許你自己？）不會忘記這麼做，因爲如果他們這樣做忘了，那麼什麼都不會工作（也就是說，破壞不會侷限於二進制BLOB！）