本文较为详细的分析了C#读取二进制文件方法。分享给大家供大家参考。具体分析如下：
当想到所有文件都转换为 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 属性的使用如下面所示：
这样做可以使数据忽略边界对齐，让数据尽可能的紧凑包装。这个属性应当和你从二进制文件中读取的任何数据的属性都保持一致（即：你写到文件中的属性应和从文件读出来属性保持不变）。
你也许会发现，即使给你的数据加上了这个属性后，也没有完全解决问题。在某些情况下，你可能不得不进行沉闷冗长的反复实验。由于不同计算机和编译器在二进制层次上的有着不同的运行处理方式，这就是引起上述问题的原因。特别是在跨平台时，我们都必须特别小心的处理二进制数据。 .NET 是个好工具，适合其它二进制文件，但是也并不是一个完美的工具。
字节排列顺序的翻转（endian flipping）
读写二进制文件的经典问题之一就是：某些计算机首先是储存最不重要的字节（如：Inter），而另外一些计算机是首先储存最重要的字节。在 C 和 C++ 中，你不得不手动处理这个问题，而且只能是一个字段一个字段的翻转。而 .NET 框架的优点之一就是：代码可以在运行时访问类型的元数据（metadata），你也就能够读取信息，并使用它来自动解决数据中每一段的字节排列顺序问题。在 Listing B 上可以找到源代码，你可以了解是如何处理的。
一旦你得知对象的类型，你能够获得数据里的每个部分，并开始检查每一个部分，并确定其是否是一个16位或32位的无符号整数。在任何一种上述情况下，你都可以改变字节的排序顺序，而且不会破坏数据。
注意：你不是用字符串类（string）来完成所有的事。是采用高位优先还是低位优先，并不会影响到字符串类。那些字段是不受翻转代码的影响。你也只是要注意无符号整数而已。因为，负数在不同的系统上，并不是使用同一种表示方式的。负数可以只用一个记号（一位字节）表示，但是更常用的，却是使用两个记号（两位字节）表示。这使得负数在跨平台时有些更困难。幸运的是，负数在二进制文件中极少使用。
这只是多说几句了，同样的，浮点数有时并不是用标准方式表示的。尽管大多数系统是以IEEE格式为基础来设置浮点数的，但是还是有一小部分老的系统使用了其它的格式来设置浮点数的。
克服困难
尽管 C# 还是有一些问题，但是你依旧能够使用它来读取二进制文件。实际上，由于 C# 所使用的那种用来访问对象的元数据（metadata）的方式，使它成为一种能够更好读取二进制文件的语言。因此， C# 能够自动解决整个数据的字节交换（byte swapping）问题。
希望本文所述对大家的C#程序设计有所帮助。
