當想到所有文件都轉換為 XML時，確實是一件好事。但是，這並非事實。仍舊還有大量的文件格式不是XML，甚至也不是ASCII。二進制文件仍然在網絡中傳播，儲存在磁盤上，在應用程序之間傳遞。相比之下，在處理這些問題方面，它們比文本文件顯得更有效率些。
在 C 和 C++ 中，讀取二進制文件還是很容易的。除了一些開始符（carriage return）和結束符（line feed）的問題，每一個讀到C/C++中的文件都是二進制文件。事實上，C/C++ 只知道二進制文件，以及如何讓二進制文件像文本文件一樣。當我們使用的語言越來越抽象時，我們最後使用的語言就不能直接、容易的讀取創建的文件了。這些語言想要用它們自己獨特的方式來自動處理輸出數據。
問題的所在
在許多計算機科學領域，C 和 C++ 仍舊直接依照數據結構來儲存和讀取數據。在C和C++中，依照內存中的數據結構來讀取和寫文件，是十分簡單的。在C中，你只需要使用fwrite()函數，並提供下列參數：一個指向你的數據的指針，告訴它有多少個數據，一個數據有多大。這樣，就直接用二進制格式把數據寫成文件了。
如上所述的那樣把數據寫成文件，同時如果你也知道其正確的數據結構的話，那麼也就意味著讀取文件也很容易。你只要使用 fread() 函數，並提供下列參數：一個文件句柄，一個指向數據的指針，讀取多少個數據，每一個數據的長度。 fread() 函數幫你把其余的事都做了。突然，數據又回到了內存中。沒有采用解析以及也沒有對象模型的方式，它只是把文件直接的讀到內存中。
在C和C++中，最大的兩個問題就是數據對齊（structure alignment）和字節交換（byte swapping）。數據對齊指的是有時編譯器會跳過數據中間的字節，因為如果處理器訪問到那些字節，就不再處於最優化狀態下了，要花費更多的時間（一般情況，處理器訪問未對齊數據花費的時間是訪問對齊數據的兩倍），花費更多的指令。因此，編譯器要為了執行速度而進行優化，跳過了那些字節並重新進行排序。另一方面，字節交換指的是：由於不同處理器對字節排序的方式不同，需要對數據的字節重新排序的過程。
數據對齊
因為處理器能夠一次處理更多的信息（在一個時鐘周期內），所以它們希望它們所處理的信息能以一種確定的方式排列。大多數的 Intel 處理器使整數類型（32位的）的儲存首地址能被4除盡（即：從能被4除盡的地址上開始儲存）。如果內存中的整數不是儲存在4的倍數的地址上的話，它們是不會工作的。編譯器知道這些。因此當編譯器遇到一個可能引起這種問題的數據時，它們就有下面三種選擇。
第一種，它們可以選擇在數據中添加一些無用的白空格符，這樣可以使整數的開始地址能被4除盡。這是一種最普遍的做法。第二種，它們可以對字段重新排序，以便使整數處於4位的邊界上。因為這樣會造成其它有趣的問題，因此，這種方式較少使用。第三種選擇是，允許數據中的整數不處於4位的邊界上，但是把代碼復制到一個合適的地方從而使那些整數處於4位的邊界上。這種方式需要一些額外的時間花費，但是，如果必須壓縮的話，那麼它就很有用了。
以上所說的這些大都是編譯器的細節問題，你用不著過多的擔心。如果你對寫數據的程序和讀數據的程序使用同樣的編譯器，同樣的設定，那麼，這些就不成其為問題了。編譯器用同樣的方法來處理同樣的數據，一切都OK。但是當你涉及到跨平台文件轉換問題時，用正確的方式來排列所有數據就顯得很重要了，這樣才能保證信息能被轉換。另外，一些程序員還了解怎樣讓編譯器不用理睬他們的數據。
字節交換（byte swapping）：高位優先（big endians）和低位優先（little endians）
高位優先和低位優先，指的是兩種不同的方式，把整數儲存在計算機中的的方式。因為整數是多於一個字節的，那麼，問題在於：最重要的字節是否應該首先被讀寫。最不重要的字節是變化的最頻繁的。這就是，如果你不斷給一個整數加一，最不重要的字節要改變256次，次不重要的字節才只變化一次。
不同的處理器用不同的方式儲存整數。Intel 處理器一般用低位優先方式來儲存整數，換句話說，低位首先被讀寫。大多數其它處理器用高位優先方式來儲存整數。因此，當二進制文件在不同平台上讀寫時，你就有可能不得不對字節重新排序以便得到正確的順序。
在 UNIX 平台上，還有一種特殊的問題，因為UNIX可以在Sun Sparc處理器、HP處理器、ＩＢＭ Power PC、Inter的芯片等多種處理器上運行。當從一種處理器轉移到另一種處理器上時，就意味著那些變量的字節排列順序必須翻轉，以便於它們能滿足新處理器所要求的順序。
用 C# 處理二進制文件
用 C# 處理二進制文件的話，就會有另外兩項新的挑戰。第一項挑戰是：所有的 .NET 語言都是強類型的。因此，你不得不從文件中的字節流轉換為你所想要的數據類型。第二項挑戰就是：一些數據類型比它們表面上要復雜的多，需要某種轉換。
類型破壞（type breaking）
因為 .NET 語言，包括 C#，都是強類型的，你不能只是任意的從文件中讀取一段字節，然後塞到數據結構中就一切OK了。因此當你要破壞類型轉換規則時，你就不得不這樣做了，首先讀取你所需要的字節數到一個字節數組中，然後把它們從頭到尾的復制到數據結構中。
在 Usenet （注：世界性的新聞組網絡系統）的文檔中搜尋，你會找到幾個構架在 microsoft.public.dotnet層次上的一組程序，它們可以容許你把任何對象轉換為一系列字節，並可以重新轉換回對象。它們可以在下面地址找到 Listing A
復雜的數據類型
在 C++ 中，你明白什麼是對象，什麼是數組，什麼既不是對象又不是數組。但是在 C# 中，事情並不像看起來的那樣簡單。一個字符串（string）就是一個對象，因此也是一個數組。因為在 C# 中，既沒有真正的數組，許多對象也沒有固定尺寸，因此一些復雜數據類型並不適合成為固定尺寸的二進制數據。
幸好， .NET 提供了一種方式來解決這種問題。你可以告訴 C# ，你想怎樣處理你的字符串（string）和其它類型的數組。這將通過 MarshalAs 屬性來完成。下面這個例子，就是在 C# 中使用字符串，這屬性必須要在所控制的數據使用之前被使用：
[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 50)]
你想要從二進制文件中讀取，或者儲存到二進制文件中的字符串（string）的長度就決定了參數 SizeConst 的大小。這樣就確定了字符串長度的最大值。
解決以前的問題
現在，你知道了 .NET 引入的問題是怎樣被解決的了。那麼，在後面，你就可以了解到，解決前面所遇到的二進制文件問題是那麼的容易。
包裝（pack）
不用麻煩的去設定編譯器來控制如何排列數據。你只需使用 StructLayout 屬性就可以使數據依照你的意願來排列或打包。當你需要不同的數據有著不同的包裝方式的時候，這就顯得十分有用了。這就像裝扮你的汽車一樣，任你的喜好。使用 StructLayout 屬性就像你很小心的決定是否把每一個數據都緊湊包裝或者還是只將它們隨便打發，只要它們能夠被重新讀出來就行了。 StructLayout 屬性的使用如下面所示：
[StructLayout(LayoutKind.Sequential, Pack = 1)]
這樣做可以使數據忽略邊界對齊，讓數據盡可能的緊湊包裝。這個屬性應當和你從二進制文件中讀取的任何數據的屬性都保持一致（即：你寫到文件中的屬性應和從文件讀出來屬性保持不變）。
你也許會發現，即使給你的數據加上了這個屬性後，也沒有完全解決問題。在某些情況下，你可能不得不進行沉悶冗長的反復實驗。由於不同計算機和編譯器在二進制層次上的有著不同的運行處理方式，這就是引起上述問題的原因。特別是在跨平台時，我們都必須特別小心的處理二進制數據。 .NET 是個好工具，適合其它二進制文件，但是也並不是一個完美的工具。
字節排列順序的翻轉（endian flipping）
讀寫二進制文件的經典問題之一就是：某些計算機首先是儲存最不重要的字節（如：Inter），而另外一些計算機是首先儲存最重要的字節。在 C 和 C++ 中，你不得不手動處理這個問題，而且只能是一個字段一個字段的翻轉。而 .NET 框架的優點之一就是：代碼可以在運行時訪問類型的元數據（metadata），你也就能夠讀取信息，並使用它來自動解決數據中每一段的字節排列順序問題。在 Listing B 上可以找到源代碼，你可以了解是如何處理的。
一旦你得知對象的類型，你能夠獲得數據裡的每個部分，並開始檢查每一個部分，並確定其是否是一個16位或32位的無符號整數。在任何一種上述情況下，你都可以改變字節的排序順序，而且不會破壞數據。
注意：你不是用字符串類（string）來完成所有的事。是采用高位優先還是低位優先，並不會影響到字符串類。那些字段是不受翻轉代碼的影響。你也只是要注意無符號整數而已。因為，負數在不同的系統上，並不是使用同一種表示方式的。負數可以只用一個記號（一位字節）表示，但是更常用的，卻是使用兩個記號（兩位字節）表示。這使得負數在跨平台時有些更困難。幸運的是，負數在二進制文件中極少使用。
這只是多說幾句了，同樣的，浮點數有時並不是用標准方式表示的。盡管大多數系統是以IEEE格式為基礎來設置浮點數的，但是還是有一小部分老的系統使用了其它的格式來設置浮點數的。
克服困難
盡管 C# 還是有一些問題，但是你依舊能夠使用它來讀取二進制文件。實際上，由於 C# 所使用的那種用來訪問對象的元數據（metadata）的方式，使它成為一種能夠更好讀取二進制文件的語言。因此， C# 能夠自動解決整個數據的字節交換（byte swapping）問題。
