XmlSerializer 和 BinaryFormatter 之间有什么区别
上周我花了很大一部分时间进行连载。 在那段时间里，我发现了许多使用 BinaryFormatter 或 XmlSerializer 的示例。 不幸的是，我没有找到任何全面详细说明两者之间差异的例子。
我好奇的根源在于为什么 BinaryFormatter 能够直接反序列化到接口，而 XmlSerializer 却不能。 乔恩·斯基特回答“在运行时转换为多个（未知类型）”提供了直接二进制序列化到接口的示例。 Stan R. 在他对“XML 对象反序列化到接口。”
除了 BinaryFormatter 使用二进制序列化而 XmlSerializer 使用 XML 之外，我想更全面地了解根本差异。 何时使用其中一种以及每种的优缺点。
I spent a good portion of time last week working on serialization. During that time I found many examples utilizing either the BinaryFormatter or XmlSerializer. Unfortunately, what I did not find were any examples comprehensively detailing the differences between the two.
The genesis of my curiosity lies in why the BinaryFormatter is able to deserialize directly to an interface whilst the XmlSerializer is not. Jon Skeet in an answer to "casting to multiple (unknown types) at runtime" provides an example of direct binary serialization to an interface. Stan R. provided me with the means of accomplishing my goal using the XmlSerializer in his answer to "XML Object Deserialization to Interface."
Beyond the obvious of the BinaryFormatter utilizes binary serialization whilst the XmlSerializer uses XML I'd like to more fully understand the fundamental differences. When to use one or the other and the pros and cons of each.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
XML Serializer 生成 XML 以及 XML 模式（隐式）。 它将生成符合此架构的 XML。
其含义之一是它不会序列化任何无法在 XML 模式中描述的内容。 例如，在 XML Schema 中无法区分列表和数组，因此序列化程序生成的 XML Schema 可以用任何一种方式解释。
运行时序列化（
BinaryFormatter是其中的一部分）将实际的 .NET 类型序列化到另一端，因此如果您发送List，另一端将得到一个List。如果对方运行 .NET，这显然效果更好。
The XML Serializer produces XML and also an XML Schema (implicitly). It will produce XML that conforms to this schema.
One implication is that it will not serialize anything which cannot be described in XML Schema. For instance, there is no way to distinguish between a list and an array in XML Schema, so the XML Schema produced by the serializer can be interpreted either way.
Runtime serialization (which the
BinaryFormatteris part of) serializes the actual .NET types to the other side, so if you send aList<int>, the other side will get aList<int>.That obviously works better if the other side is running .NET.
XmlSerializer 通过读取具有公共 getter 和公共 setter（以及任何公共字段）的所有类型属性来序列化类型。 从这个意义上说，XmlSerializer 序列化/反序列化实例的“公共视图”。
相比之下，二进制格式化程序通过序列化实例的“内部”（即其字段）来序列化类型。 任何未标记为 [NonSerialized] 的字段都将被序列化为二进制流。 类型本身必须标记为 [Serializable]，任何要序列化的内部字段也必须标记为 [Serializable]。
The XmlSerializer serialises the type by reading all the type's properties that have both a public getter and a public setter (and also any public fields). In this sense the XmlSerializer serializes/deserializes the "public view" of the instance.
The binary formatter, by contrast, serializes a type by serializing the instance's "internals", i.e. its fields. Any fields that are not marked as [NonSerialized] will be serialized to the binary stream. The type itself must be marked as [Serializable] as must any internal fields that are also to be serialized.
我想最重要的之一是二进制序列化可以序列化公共和私有成员，而另一种仅适用于公共成员。
在这里，它提供了两者之间尺寸方面非常有用的比较。 这是一个非常重要的问题，因为您可能会将序列化对象发送到远程计算机。
http://www .nablasoft.com/alkampfer/index.php/2008/10/31/binary-versus-xml-serialization-size/
I guess one of the most important ones is that binary serialization can serialize both public and private members, whereas the other one works only with public ones.
In here, it provides a very helpful comparison between these two in terms of size. It's a very important issue, because you might send your serialized object to a remote machine.
http://www.nablasoft.com/alkampfer/index.php/2008/10/31/binary-versus-xml-serialization-size/
二进制格式化程序能够直接反序列化为接口类型的原因是，当对象最初序列化为二进制流时，包含类型和程序集信息的元数据会与对象数据粘在一起。 这意味着当二进制格式化程序反序列化对象时，它知道其类型，构建正确的对象，然后您可以将其转换为对象实现的接口类型。
另一方面，XML 序列化程序仅序列化为模式，并且仅序列化对象的公共字段和值，除此之外没有任何类型信息（例如，类型实现的接口）。
这是一篇很好的文章，.NET 序列化，比较了 BinaryFormatter，SoapFormatter 和 XmlSerializer。 我建议您查看下表，除了前面提到的序列化程序之外，还包括 DataContractSerializer，NetDataContractSerializer< /a> 和 protobuf-net。
The reason a binary formatter is able to deserialize directly to an interface type is because when an object is originally serialized to a binary stream metadata containing type and assembly information is stuck in with the object data. This means that when the binary formatter deserializes the object it knows its type, builds the correct object and you can then cast that to an interface type that object implements.
The XML serializer on the otherhand just serializes to a schema and only serializes the public fields and values of the object and no type information other then that (e.g. interfaces the type implements).
Here is a good post, .NET Serialization, comparing the BinaryFormatter, SoapFormatter, and XmlSerializer. I recommend you look at the following table which in addition to the previously mentioned serializers includes the DataContractSerializer, NetDataContractSerializer and protobuf-net.
只是权衡一下...
两者之间的明显区别是“二进制与 xml”，但它确实比这更深入：
BinaryFormatter=bf) 与 public 成员（通常是属性） (XmlSerializer=xs)作为对
BinaryFormatter为何脆弱的讨论，请参阅此处。无法讨论哪个更大；
BinaryFormatter中的所有类型元数据都可以使其变得更大。XmlSerializer可以很好地与 gzip 等压缩一起工作。然而，我们可以利用各自的优势； 例如，Google 开源了自己的数据序列化格式“协议缓冲区”。 这是：
但重要的是，它是非常密集的数据（没有类型元数据、纯二进制表示、短标签、变长基7编码等技巧），并且处理起来非常高效（没有复杂的 xml 结构，没有与成员匹配的字符串等）。
我可能有点偏见； 我维护其中一个实现（包括几个适合 C#/.NET 的实现），但您会注意到我还没有维护
链接到任何具体实施； 该格式有其自身的优点;-p
Just to weigh in...
The obvious difference between the two is "binary vs xml", but it does go a lot deeper than that:
BinaryFormatter=bf) vs public members (typically properties) (XmlSerializer=xs)As a discussion of why
BinaryFormattercan be brittle, see here.It is impossible to discuss which is bigger; all the type metadata in
BinaryFormattercan make it bigger. AndXmlSerializercan work very with compression like gzip.However, it is possible to take the strengths of each; for example, Google have open-sourced their own data serialization format, "protocol buffers". This is:
But importantly, it is very dense data (no type metadata, pure binary representation, short tags, tricks like variant-length base-7 encoding), and very efficient to process (no complex xml structure, no strings to match to members, etc).
I might be a little biased; I maintain one of the implementations (including several suitable for C#/.NET), but you'll note I haven't
linked to any specific implementation; the format stands under its own merits ;-p