序列化与反序列化

定义

序列化：将对象或数据结构转换成约定格式数据的过程。
反序列化：将约定格式的数据转换成对象或数据结构的过程。

  通常我们将这种“约定格式的数据”称之为序列化协议。根据协议的特点序列化协议可以细分为文本序列化协议（以下简称文本协议）和二进制序列化协议（以下简称二进制协议）。文本协议是指序列化的数据肉眼可以阅读，比如XML协议，而二进制协议序列化的数据不便于阅读，比如Java中标准的Serializable协议。序列化协议主要应用于两个方面，第一：数据网络传输；第二：数据持久化。在当今这个纷繁复杂的世界上，每一个程序、每一个系统都会有数据的持久化过程以及系统与系统之间都会有数据往来，互通有无。

应用

数据网络传输

  数据网络传输是一个比较宽泛的概念，我们首先得理清楚序列化协议在其中指哪一块的内容。简单点讲，数据网络传输分为传输协议和序列化协议。传输协议是针对传输方式的，序列化协议是针对传输内容的。常用的传输协议有HTTP、TCP/IP等；常用的序列化协议有JSON、XML等。举个例子，武汉的小明要到广州出差，他从飞机、高铁和自驾等多种交通工具中选择了乘坐高铁。于是他到火车站买了一张武汉到广州的火车票，车票上给他分配是12车09A号。于是他上车，按照自己的座位号入座前往广州。高铁就是传输协议的一种，车辆内部乘客有序的入座就是序列化协议的一种。同样是高铁，里面可以按照各种顺序排列乘客；同一种传输协议可以承载不同的序列化数据。
  现有两个进程，一个是程序A另一个是程序B，程序A中有一个对象User，现要把这个User数据数据传给程序B使用。为了实现这个需求，A、B之间需确定一个序列化协议，比如JSON；确定一个传输协议，比如HTTP。然后A实例化一个姓名为张三、年龄为18的User并将其序列化为JSON格式的数据。接着A通过HTTP协议将JSON格式的数据传给B，B再将这个数据按照JSON协议反序列化User对象。
  下面是Java语言的一个简单描述：

public class User{   private String userName;   private int userAge;   public Use(String userName,int userAge)   {     this.userName=userName;     this.userAge=userAge;   }  // 其他方法略}

然后将其序列化成Json格式的数据，任何

{   "userName":"张三",   "userAge":18}

数据持久化

  数据持久化是指程序运行过程中产生的数据不可能永远保存在内存当中，需要输出保存到文件或数据库中，便于数据长期使用。最常见的数据持久化为数据库持久化和文件持久化。

数据库持久化

  简单点说，程序将对象（或结构体）数据存入数据库，将其转换成表中的一行记录就是一个序列化过程；程序从数据库表中读出记录，将其转换成一个对象（或结构体）数据就是一个反序列化的过程。在这个数据的存储和读取过程中，序列化协议可以宏观地理解为表中的一个个字段的定义，程序按照这个规则，将对象（或结构体）输出，又按照这个规则读取，前后毫无差错。因此，其他的程序只要知道了这个序列化协议均可反序列化成具体的对象（或结构体）。
  对于关系型数据库而言，他们都是统一的序列化协议，底层都是同一个模式库、表、字段的定义。然而，近来文档型数据库比较流行，他们的序列化协议就不一样了，比如MongoDB采用的是JSON文档型的。

文件持久化

  和数据库持久化类似，文件也是序列化协议的产物。文件按照不同的序列化协议将数据长期存储在磁盘上。通常情况下，他有一种特殊的标识即文件扩展名，比如.json、.xml、.csv、.sql等。通过文件扩展名一般可以确定这个文件采用什么序列化协议，按照协议读取文件即可反序列化其中的数据。

选取原则

  序列化协议如此之多，而且每种有有利有弊，在实际生产过程中我们只能按照系统要求，折中考虑。下面列出几个序列化协议的原则：
* 通用性
  序列化协议一方面要能摆脱语言、平台的束缚；另一方面要在业界耳熟能详应用广泛。比如Java标准的对象序列化实现就不是这一条的好榜样，你要一个C程序员将Java标准序列化实现的数据反序列化成对应结构体是一个很蛋疼的事情。相反，JSON就是一个很好的序列化协议，至少在这一条上算得上是佼佼者了。
* 可调式性/可读性
  序列化协议要能方便开发过程中的调试。做过二进制协议开发的同学一定深有体会，肉眼基本不可辨别序列化后的数据，需要借助一些第三方的工具一点点分析。相对于二进制协议，文本协议就比较和蔼可亲了。
* 稳定性
  协议要能够经得住时间的考验。一般情况下采用公开流行的协议是不存在这个问题的，因为他们都被成千上万的应用检验过了。特别要小心的是自定义协议，举个反例，比如自定义一个类似于Java标准序列化协议的协议，由于当前业务没有涉及到对象和对象之间的继承关系，所以协议制定者没有考虑对象继承的情况。但是随着业务的发展，系统中出现了继承关系的实体类，某个同事不小心将这种对象的实例序列化，结果可想而知。协议不够成熟，所以自定义协议需要考虑的因数很多。如果自己不是大牛，建议不要自定义序列化协议。
* 可扩展性
  和稳定性差不多，满足通用性条件的协议基本不会出现这个问题。问题还是会出现在自定义协议上。协议的成熟是一个漫长的过程，要经过不断的测试。比如稳定性中出现的那个问题，协议将继承关系的序列化加入，升级之后就能解决问题。但是要做到兼容以前的版本就不那么容易了。协议的制定者也不是圣人，不可能考虑得那么周全，但是一定要有一套可扩展的方案，这样协议才能存活下来，慢慢迭代成稳定版本。
* 性能
  说道性能问题，无非就是时间和空间的博弈。序列化结果数据的大小，直接影响网络传输的带宽和磁盘存储的空间。序列化和反序列化过程所消耗的时间长短，影响系统的性能。几种常用的协议性能的比较网上有很多，这里就不详细介绍了。