问题描述
Microsoft 警告不要使用 BinaryFormatter（他们写道，没有办法使反序列化安全）。
应用程序应尽快停止使用 BinaryFormatter， 即使他们相信他们正在处理的数据是值得信赖的。
我不想使用基于 XML 或 Json 的解决方案（它们指的是这些）。我担心文件大小和保留对象图。
如果我要编写自己的方法来遍历我的对象图并将对象转换为二进制是否可以安全地进行，或者是否有特定的从二进制转换使其本质上比文本更危险的方法？
解决方法
是否有 BinaryFormatter 的二进制（非 XML 和非 JSON）替代方案？
感觉这个问题会导致更多基于意见的答案。
我确信有很多库，但也许最著名的替代方案是 Protocol Buffers (protobuf)。它是一个 Google 库，因此得到了大量的开发和关注。然而，并非所有人都同意使用 protobuf 进行通用二进制序列化是最好的做法。
如果您想了解更多信息，请在 dotnet 的 github 上关注此 discussion about BinaryFormatter；它讨论了 BinaryFormatter 的一般问题，以及使用 protobuf 作为替代方案。
我可以创建自己的安全二进制序列化系统吗？
是的。也就是说，真正的问题应该是：“我花时间这样做是否值得？”
请参阅此链接以了解 BinaryFormatter 的放松计划：
https://github.com/dotnet/designs/pull/141/commits/bd0a0661f9d248ed31a354d27ad026efd6719690
在最底部你会发现：
为什么不让 BinaryFormatter 对于不受信任的有效负载安全？
BinaryFormatter 协议通过指定一个
对象的原始实例字段。换句话说，整个点
BinaryFormatter 是绕过对象的典型构造函数并
使用私有反射将实例字段设置为
通过电线进来。以这种方式绕过构造函数意味着
对象不能执行任何验证或以其他方式保证
满足其内部不变量。这样做的后果之一是
即使对于看似无害的类型，BinaryFormatter 也是不安全的
例如 Exception 或 List<T> 或 Dictionary<TKey,TValue>，
与 T、TKey 或 TValue 的实际类型无关。
将反序列化限制为允许的类型列表不会
解决这个问题。
安全问题不在于二进制序列化作为一个概念；问题在于 BinaryFormatter 的实现方式。
如果需要，您可以设计一个安全的二进制反序列化系统。如果您发送的消息很少，并且您可以严格控制反序列化的类型，那么构建一个安全系统可能不需要太多努力。
但是，对于一个足够灵活以处理许多不同用例（例如，可以反序列化的许多不同类型）的系统，您可能会发现构建足够的安全检查需要付出很多努力。
FWIW，使用提供相同广泛实用程序（用例）的安全系统，您可能永远无法达到 BinaryFormatter 的性能水平，因为 BinaryFormatter 的速度（部分）来自于 几乎没有安全功能。您可能使用一个有针对性的小型系统来达到这样的性能水平，该系统的用例集很窄。