40

我使用二进制序列化(BinaryFormatter)作为一种临时机制,将状态信息存储在文件中,用于相对复杂的(游戏)对象结构;这些文件比我预期的要大得多,而且我的数据结构包括递归引用 - 所以我想知道 BinaryFormatter 是否实际上存储了相同对象的多个副本,或者我的基本“对象和值的数量我应该有“算术太离谱了,或者过大的大小是从哪里来的。

搜索堆栈溢出我能够找到微软二进制远程格式的规范:http: //msdn.microsoft.com/en-us/library/cc236844 (PROT.10).aspx

我找不到任何现有的查看器,使您能够“窥视”二进制格式化程序输出文件的内容 - 获取文件中不同对象类型的对象计数和总字节数等;

我觉得这一定是我的“google-fu”让我失望了(我所拥有的很少)——有人能帮忙吗?这一定是以前做过的吧??


更新:我找不到它并且没有得到答案,所以我把一些相对较快的东西放在一起(链接到下面的可下载项目);我可以确认 BinaryFormatter 不存储同一个对象的多个副本,但它确实将大量元数据打印到流中。如果您需要高效的存储,请构建您自己的自定义序列化方法。

4

4 回答 4

123

因为我决定写这篇文章的人可能会感兴趣,关于序列化 .NET 对象的二进制格式是什么样的以及我们如何正确解释它?

我的所有研究都基于.NET Remoting: Binary Format Data Structure规范。



示例类:

为了有一个工作示例,我创建了一个名为的简单类A,它包含 2 个属性,一个字符串和一个整数值,它们被称为SomeStringand SomeValue

A看起来像这样:

[Serializable()]
public class A
{
    public string SomeString
    {
        get;
        set;
    }

    public int SomeValue
    {
        get;
        set;
    }
}

对于序列化,我BinaryFormatter当然使用了:

BinaryFormatter bf = new BinaryFormatter();
StreamWriter sw = new StreamWriter("test.txt");
bf.Serialize(sw.BaseStream, new A() { SomeString = "abc", SomeValue = 123 });
sw.Close();

可以看出,我传递了一个A包含abc123作为值的类的新实例。



示例结果数据:

如果我们在十六进制编辑器中查看序列化结果,我们会得到如下内容:

示例结果数据



让我们解释一下示例结果数据:

根据上述规范(这里是 PDF 的直接链接:[MS-NRBF].pdf),流中的每条记录都由RecordTypeEnumeration. 部分2.1.2.1 RecordTypeNumeration指出:

此枚举标识记录的类型。每条记录(MemberPrimitiveUnTyped 除外)都以记录类型枚举开头。枚举的大小是一个字节。



序列化标头记录:

所以如果我们回顾我们得到的数据,我们可以开始解释第一个字节:

SerializationHeaderRecord_RecordTypeEnumeration

2.1.2.1 RecordTypeEnumeration值 中所述,0标识在SerializationHeaderRecord中指定2.6.1 SerializationHeaderRecord

SerializationHeaderRecord 记录必须是二进制序列化中的第一条记录。该记录具有格式的主要版本和次要版本以及顶部对象和标题的 ID。

它包括:

  • RecordTypeEnum (1 字节)
  • RootId(4 字节)
  • HeaderId(4 字节)
  • 主要版本(4 字节)
  • 次要版本(4 个字节)



有了这些知识,我们可以解释包含 17 个字节的记录:

SerializationHeaderRecord_Complete

00代表我们的RecordTypeEnumeration情况SerializationHeaderRecord

01 00 00 00代表RootId

如果序列化流中既没有 BinaryMethodCall 也没有 BinaryMethodReturn 记录,则该字段的值必须包含序列化流中包含的 Class、Array 或 BinaryObjectString 记录的 ObjectId。

所以在我们的例子中,这应该是ObjectId带有值的1(因为数据是使用 little-endian 序列化的),我们希望能再次看到它;-)

FF FF FF FF代表HeaderId

01 00 00 00代表MajorVersion

00 00 00 00表示MinorVersion



BinaryLibrary:

如指定的那样,每条记录必须以RecordTypeEnumeration. 当最后一个记录完成时,我们必须假设一个新的记录开始了。

让我们解释下一个字节:

BinaryLibraryRecord_RecordTypeEnumeration

如我们所见,在我们的示例中,SerializationHeaderRecord它后面是BinaryLibrary记录:

BinaryLibrary 记录将 INT32 ID(如 [MS-DTYP] 第 2.2.22 节中指定)与库名称相关联。这允许其他记录通过使用 ID 来引用图书馆名称。当有多个记录引用同一个库名称时,这种方法会减小连线大小。

它包括:

  • RecordTypeEnum (1 字节)
  • 库 ID(4 个字节)
  • LibraryName(可变字节数(即 a LengthPrefixedString))



2.1.1.6 LengthPrefixedString...中所述

LengthPrefixedString 表示一个字符串值。该字符串以 UTF-8 编码字符串的长度为前缀(以字节为单位)。长度编码在一个可变长度字段中,最小为 1 个字节,最大为 5 个字节。为了最小化线路尺寸,长度被编码为可变长度字段。

在我们的简单示例中,长度始终使用 编码1 byte。有了这些知识,我们可以继续解释流中的字节:

BinaryLibraryRecord_RecordTypeEnumeration_LibraryId

0C表示RecordTypeEnumeration标识BinaryLibrary记录的。

02 00 00 00代表我们的LibraryId情况2



现在LengthPrefixedString如下:

BinaryLibraryRecord_RecordTypeEnumeration_LibraryId_LibraryName

42LengthPrefixedString表示包含 的的长度信息LibraryName

在我们的例子中,(十进制 66)的长度信息42告诉我们,我们需要读取接下来的 66 个字节并将它们解释为LibraryName.

如前所述,字符串是经过UTF-8编码的,因此上面字节的结果将类似于:_WorkSpace_, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null



ClassWithMembersAndTypes:

同样,记录是完整的,所以我们解释RecordTypeEnumeration下一个:

ClassWithMembersAndTypesRecord_RecordTypeEnumeration

05标识一条ClassWithMembersAndTypes记录。部分2.3.2.1 ClassWithMembersAndTypes指出:

ClassWithMembersAndTypes 记录是最详细的 Class 记录。它包含有关成员的元数据,包括成员的名称和远程处理类型。它还包含一个引用类的库名称的库 ID。

它包括:

  • RecordTypeEnum (1 字节)
  • ClassInfo(可变字节数)
  • MemberTypeInfo(可变字节数)
  • 库 ID(4 个字节)



类信息:

2.3.1.1 ClassInfo记录所述,包括:

  • 对象 ID(4 个字节)
  • 名称(可变字节数(又是 a LengthPrefixedString))
  • 成员计数(4 字节)
  • MemberNames(这是一个LengthPrefixedString's 的序列,其中项目的数量必须等于MemberCount字段中指定的值。)



回到原始数据,一步一步:

ClassWithMembersAndTypesRecord_RecordTypeEnumeration_ClassInfo_ObjectId

01 00 00 00代表ObjectId. 我们已经看到了这个,它被指定RootIdSerializationHeaderRecord.

ClassWithMembersAndTypesRecord_RecordTypeEnumeration_ClassInfo_ObjectId_Name

0F 53 74 61 63 6B 4F 76 65 72 46 6C 6F 77 2E 41表示Name使用 a 表示的类的LengthPrefixedString。如前所述,在我们的示例中,字符串的长度定义为 1 个字节,因此第一个字节0F指定必须使用 UTF-8 读取和解码 15 个字节。结果看起来像这样:StackOverFlow.A- 很明显我用作StackOverFlow命名空间的名称。

ClassWithMembersAndTypesRecord_RecordTypeEnumeration_ClassInfo_ObjectId_Name_MemberCount

02 00 00 00代表MemberCount,它告诉我们 2 个成员,都用LengthPrefixedString's 代表将跟随。

第一位成员姓名: ClassWithMembersAndTypesRecord_MemberNameOne

1B 3C 53 6F 6D 65 53 74 72 69 6E 67 3E 6B 5F 5F 42 61 63 6B 69 6E 67 46 69 65 6C 64代表第一个MemberName1B再次是字符串的长度,长度为 27 个字节,结果如下<SomeString>k__BackingField

第二位成员姓名: ClassWithMembersAndTypesRecord_MemberNameTwo

1A 3C 53 6F 6D 65 56 61 6C 75 65 3E 6B 5F 5F 42 61 63 6B 69 6E 67 46 69 65 6C 64表示第二个MemberName1A指定字符串的长度为 26 个字节。结果是这样的:<SomeValue>k__BackingField.



成员类型信息:

之后ClassInfo如下MemberTypeInfo

部分2.3.1.2 - MemberTypeInfo指出,该结构包含:

  • BinaryTypeEnums(长度可变)

表示正在传输的成员类型的 BinaryTypeEnumeration 值序列。阵列必须:

  • 具有与 ClassInfo 结构的 MemberNames 字段相同数量的项目。

  • 进行排序,使 BinaryTypeEnumeration 对应于 ClassInfo 结构的 MemberNames 字段中的成员名称。

  • AdditionalInfos(长度可变),取决于BinaryTpeEnum附加信息可能存在也可能不存在。

| BinaryTypeEnum | AdditionalInfos |
|----------------+--------------------------|
| Primitive | PrimitiveTypeEnumeration |
| String | None |

所以考虑到这一点,我们几乎就在那里......我们期望 2 个BinaryTypeEnumeration值(因为我们在 2 个成员中有 2 个成员MemberNames)。



再次,回到完整MemberTypeInfo记录的原始数据:

ClassWithMembersAndTypesRecord_MemberTypeInfo

01表示BinaryTypeEnumeration第一个成员的 ,根据2.1.2.2 BinaryTypeEnumeration我们可以预期的 a String,它使用 a 表示LengthPrefixedString

00表示BinaryTypeEnumeration第二个成员的 ,同样,根据规范,它是Primitive. 如上所述,Primitive's 后面是附加信息,在本例中为 a PrimitiveTypeEnumeration。这就是为什么我们需要读取下一个字节,即08,将其与表中所述的表相匹配,2.1.2.3 PrimitiveTypeEnumeration并惊讶地发现我们可以预期一个Int32由 4 个字节表示的字节,如其他一些关于基本数据类型的文档中所述。



图书馆编号:

以下之后MemerTypeInfoLibraryId用4个字节表示:

ClassWithMembersAndTypesRecord_LibraryId

02 00 00 00表示LibraryId哪个是 2。



价值:

如中所述2.3 Class Records

类成员的值必须序列化为该记录之后的记录,如第 2.7 节所述。记录的顺序必须与 ClassInfo(第 2.3.1.1 节)结构中指定的 MemberNames 的顺序相匹配。

这就是为什么我们现在可以期待成员的价值观。

让我们看看最后几个字节:

BinaryObjectStringRecord_RecordTypeEnumeration

06标识一个BinaryObjectString. 它代表我们SomeString财产的价值(<SomeString>k__BackingField准确地说)。

2.5.7 BinaryObjectString它包含:

  • RecordTypeEnum (1 字节)
  • 对象 ID(4 个字节)
  • 值(可变长度,表示为 a LengthPrefixedString



所以知道这一点,我们可以清楚地识别出

BinaryObjectStringRecord_RecordTypeEnumeration_ObjectId_MemberOneValue

03 00 00 00代表ObjectId.

03 61 62 63表示Value其中03是字符串本身的长度,61 62 63是转换为的内容字节abc

希望您能记得还有第二个成员,一个Int32. 知道Int32是用 4 个字节表示的,我们可以得出结论,

BinaryObjectStringRecord_RecordTypeEnumeration_ObjectId_MemberOneValue_MemberTwoValue

必须是Value我们的第二个成员。7B十六进制等于123十进制,这似乎适合我们的示例代码。

所以这里是完整的ClassWithMembersAndTypes记录: ClassWithMembersAndTypesRecord_Complete



留言结束:

MessageEnd_RecordTypeEnumeration

最后一个字节0B代表MessageEnd记录。

于 2015-05-11T19:57:55.060 回答
7

Vasiliy 是对的,因为我最终需要实现自己的格式化程序/序列化过程,以更好地处理版本控制并输出更紧凑的流(压缩之前)。

但是,我确实想了解流中发生的事情,所以我写了一个(相对)快速的类来做我想要的:

  • 通过流解析其方式,构建对象名称、计数和大小的集合
  • 完成后,输出它发现的内容的快速摘要 - 流中的类、计数和总大小

把它放在像 codeproject 这样可见的地方对我来说还不够用,所以我只是将项目转储到我网站上的一个 zip 文件中:http ://www.architectshack.com/BinarySerializationAnalysis.ashx

在我的具体情况下,问题是双重的:

  • BinaryFormatter 非常冗长(这是已知的,我只是没有意识到程度)
  • 我在课堂上确实遇到了问题,结果发现我存储了我不想要的对象

希望这可以在某个时候帮助某人!


更新:Ian Wright 与我联系,说明原始代码存在问题,当源对象包含“十进制”值时它崩溃了。现在已经更正了,我利用这个机会将代码移动到 GitHub 并给它一个(许可的,BSD)许可证。

于 2010-06-19T18:21:03.077 回答
5

我们的应用程序运行大量数据。它可能需要 1-2 GB 的 RAM,就像您的游戏一样。我们遇到了相同的“存储相同对象的多个副本”的问题。二进制序列化也存储了太多的元数据。首次实现时,序列化文件大约需要 1-2 GB。现在我设法降低了价值 - 50-100 MB。我们做了什么。

简短的回答 - 不要使用 .Net 二进制序列化,创建自己的二进制序列化机制。我们有自己的 BinaryFormatter 类和 ISerializable 接口(有两个方法 Serialize、Deserialize)。

同一对象不应被序列化多次。我们保存它的唯一 ID 并从缓存中恢复对象。

如果你问,我可以分享一些代码。

编辑:看来你是对的。请参阅以下代码 - 它证明我错了。

[Serializable]
public class Item
{
    public string Data { get; set; }
}

[Serializable]
public class ItemHolder
{
    public Item Item1 { get; set; }

    public Item Item2 { get; set; }
}

public class Program
{
    public static void Main(params string[] args)
    {
        {
            Item item0 = new Item() { Data = "0000000000" };
            ItemHolder holderOneInstance = new ItemHolder() { Item1 = item0, Item2 = item0 };

            var fs0 = File.Create("temp-file0.txt");
            var formatter0 = new BinaryFormatter();
            formatter0.Serialize(fs0, holderOneInstance);
            fs0.Close();
            Console.WriteLine("One instance: " + new FileInfo(fs0.Name).Length); // 335
            //File.Delete(fs0.Name);
        }

        {
            Item item1 = new Item() { Data = "1111111111" };
            Item item2 = new Item() { Data = "2222222222" };
            ItemHolder holderTwoInstances = new ItemHolder() { Item1 = item1, Item2 = item2 };

            var fs1 = File.Create("temp-file1.txt");
            var formatter1 = new BinaryFormatter();
            formatter1.Serialize(fs1, holderTwoInstances);
            fs1.Close();
            Console.WriteLine("Two instances: " + new FileInfo(fs1.Name).Length); // 360
            //File.Delete(fs1.Name);
        }
    }
}

看起来像BinaryFormatter使用 object.Equals 来查找相同的对象。

你有没有看过生成的文件?如果您从代码示例中打开“temp-file0.txt”和“temp-file1.txt”,您会看到它有很多元数据。这就是为什么我建议您创建自己的序列化机制。

很抱歉让你感到困惑。

于 2010-06-16T10:34:38.633 回答
-1

也许您可以在调试模式下运行程序并尝试添加控制点。

如果由于游戏的大小或其他依赖项而无法做到这一点,您始终可以编写一个简单/小型的应用程序,其中包含反序列化代码并从那里的调试模式中窥视。

于 2010-06-16T10:35:22.500 回答