二进制序列化本质上是不安全的吗？
Is binary serialization inherently unsafe?
Microsoft 警告不要使用 BinaryFormatter（他们写道没有办法使反序列化安全）。
Applications should stop using BinaryFormatter as soon as possible,
even if they believe the data they're processing to be trustworthy.
我不想使用基于 XML 或 Json 的解决方案（它们是他们指的是）。我担心文件大小和保留对象图。
如果我要编写自己的方法来遍历我的对象图并将对象转换为二进制文件，这是否可以安全地进行，或者是从二进制文件转换而来的某些特定的东西使得文本在本质上更加危险？
是否有 BinaryFormatter 的二进制（非 XML 和非 JSON）替代品？
感觉这个问题会引出更多基于意见的答案。
我敢肯定那里有很多库，但也许最著名的替代方案是 Protocol Buffers (protobuf)。它是一个 Google 库，因此得到了大量的开发和关注。然而，并不是每个人都同意使用 protobuf 进行通用二进制序列化是最好的做法。
如果您想了解更多信息，请在 github 上关注此 discussion about BinaryFormatter for dotnet；它讨论了 BinaryFormatter 的一般问题，以及使用 protobuf 作为替代方案。
我可以创建自己的安全二进制序列化系统吗？
是的。也就是说，真正的问题应该是：'is it worth my time to do so?'
有关 BinaryFormatter 的结束计划，请参阅此 link：
https://github.com/dotnet/designs/pull/141/commits/bd0a0661f9d248ed31a354d27ad026efd6719690
在最底部你会发现：
Why not make BinaryFormatter safe for untrusted payloads?
The BinaryFormatter protocol works by specifying the values of an
object's raw instance fields. In other words, the entire point of
BinaryFormatter is to bypass an object's typical constructor and to
use private reflection to set the instance fields to the contents that
came in over the wire. Bypassing the constructor in this fashion means
that the object cannot perform any validation or otherwise guarantee
that its internal invariants are satisfied. One consequence of this is
that BinaryFormatter is unsafe even for seemingly innocuous types
such as Exception or List<T> or Dictionary<TKey, TValue>,
regardless of the actual types of T, TKey, or TValue.
Restricting deserialization to a list of allowed types will not
resolve this issue.
安全问题不在于二进制序列化这个概念；问题在于 BinaryFormatter 的实施方式。
如果需要，您可以设计一个安全的二进制反序列化系统。如果您发送的消息很少，并且您可以严格控制反序列化的类型，那么构建一个安全系统也许不会太费力。
但是，对于一个足够灵活的系统来处理许多不同的用例（例如，可以反序列化的许多不同类型），您可能会发现构建足够的安全检查需要付出很多努力。
FWIW，您可能永远无法使用提供相同广泛实用程序（用例）的安全系统达到 BinaryFormatter 的性能水平，因为 BinaryFormatter 的速度（部分）来自 几乎没有安全功能 。您 可能 通过具有少量用例的有针对性的小型系统来达到这样的性能水平。
Microsoft 警告不要使用 BinaryFormatter（他们写道没有办法使反序列化安全）。
Applications should stop using BinaryFormatter as soon as possible, even if they believe the data they're processing to be trustworthy.
我不想使用基于 XML 或 Json 的解决方案（它们是他们指的是）。我担心文件大小和保留对象图。
如果我要编写自己的方法来遍历我的对象图并将对象转换为二进制文件，这是否可以安全地进行，或者是从二进制文件转换而来的某些特定的东西使得文本在本质上更加危险？
是否有 BinaryFormatter 的二进制（非 XML 和非 JSON）替代品？
感觉这个问题会引出更多基于意见的答案。
我敢肯定那里有很多库，但也许最著名的替代方案是 Protocol Buffers (protobuf)。它是一个 Google 库，因此得到了大量的开发和关注。然而，并不是每个人都同意使用 protobuf 进行通用二进制序列化是最好的做法。
如果您想了解更多信息，请在 github 上关注此 discussion about BinaryFormatter for dotnet；它讨论了 BinaryFormatter 的一般问题，以及使用 protobuf 作为替代方案。
我可以创建自己的安全二进制序列化系统吗？
是的。也就是说，真正的问题应该是：'is it worth my time to do so?'
有关 BinaryFormatter 的结束计划，请参阅此 link：
https://github.com/dotnet/designs/pull/141/commits/bd0a0661f9d248ed31a354d27ad026efd6719690
在最底部你会发现：
Why not make
BinaryFormattersafe for untrusted payloads?The
BinaryFormatterprotocol works by specifying the values of an object's raw instance fields. In other words, the entire point ofBinaryFormatteris to bypass an object's typical constructor and to use private reflection to set the instance fields to the contents that came in over the wire. Bypassing the constructor in this fashion means that the object cannot perform any validation or otherwise guarantee that its internal invariants are satisfied. One consequence of this is thatBinaryFormatteris unsafe even for seemingly innocuous types such asExceptionorList<T>orDictionary<TKey, TValue>, regardless of the actual types of T, TKey, or TValue. Restricting deserialization to a list of allowed types will not resolve this issue.
安全问题不在于二进制序列化这个概念；问题在于 BinaryFormatter 的实施方式。
如果需要，您可以设计一个安全的二进制反序列化系统。如果您发送的消息很少，并且您可以严格控制反序列化的类型，那么构建一个安全系统也许不会太费力。
但是，对于一个足够灵活的系统来处理许多不同的用例（例如，可以反序列化的许多不同类型），您可能会发现构建足够的安全检查需要付出很多努力。
FWIW，您可能永远无法使用提供相同广泛实用程序（用例）的安全系统达到 BinaryFormatter 的性能水平，因为 BinaryFormatter 的速度（部分）来自 几乎没有安全功能 。您 可能 通过具有少量用例的有针对性的小型系统来达到这样的性能水平。