【施工中。。】【造轮子】字节序的配置文件序列化和反序列化，推导以及实现(unity c#)

序列化和反序列化，推导以及实现(unity c#)"/>

【施工中。。】【造轮子】字节序的配置文件序列化和反序列化，推导以及实现(unity c#)

百度一下很多描述，下面先描述一下一些关键点。
字节序的优势，因为没有了关键字，所以体积非常小，并且等于是默认加密了。
字节序也是Google Protocol Buffer的基础理论。

1. 在程序层面上来说 字节=byte。字节序其实就是一串byte，其实就是byte数组。其实按照名字，顾名思义，就有一个有顺序的字节数组。
2. 然后大家都知道一般认为byte是最小单位。那么short占用2个byte，int占用4个byte，以此类推。那其实一个byte数组，实际上可以表示任何数据类型。
3. 对于配置文件来说，常规做法会用excel，行列形式。每行都是唯一ID，加上后面的列的信息，每一列的含义其实是一样的。

如果一个配置文件的样子是：

那一般我们对应的代码里会是：

public class MonsterItem
{public int nID = 0;public string strModel = null;public int nDamage = 0;
}public Dictionary<int, MonsterItem> dic;

那么如果要序列化这么个结构，那么就可以理解成:

1. int nID = 4个byte
2. string strModel = char[字符串长度] = byte[字符串长度]
3. int nDamage = 4个byte

• 如果我假设这个字符串，长度是8，那么其实 4+8+4， 16个byte就能表示一行配置数据。
  但是这里有一个注意点，string在一串byte里面，我们不知道多长，就没办法解析出正确的string。所以保存string的时候，需要带上string长度，和网络数据包的包头一样的概念，长度一般习惯性会用ushort类型，就是2个字节，当然更具项目，也可以是byte，可能你的字符串不需要特别长。
• 所以一行数据的长度就是 4+ （2+8） + 4， 18个字节。
  那到这里其实就可以得出结论了，如果你用json，xml，或者其他的一些明文配置文件格式，根本没法达到这种程度，因为会存在标志符，或者关键字。
• 单行的数据长度已知道，那只要重复行。组装成字符串数组。其实就是我们的配置文件的序列化了。只需要把这一串byte写进文本，那一个压缩的配置文件就完成了。其实对应写入，对应解析的轮廓也很清晰了，剩下就是实现了。