JSON序列化和反序列化

问题描述
在3Dflow中，gxsolver和gxcap在读写binary的.gcap文件的时候，会统一使用同一binary接口。由于当前的gcap的binary接口严格按照顺序进行读写，导致对gcap中字段的任何删减，都会造成solver对.gcap的解析失败，程序崩溃。

解决方案
使用结构化的数据传输协议，以key-value形式读写.gcap数据，消除数据之间的耦合性，取代原来顺序读写的形式，同时在写时进行序列化（或加密），之后转换成字节序列，读时进行反序列化（或解密）。

方案比较
主流的结构化的数据传输协议有：

• JSON
• Protobuf
• Boost
  虽然protobuf在序列化和反序列的速度领先于JSON, 而序列化以后的内存占用有少于JSON。但是JSON的开发友好程度远超protobuf，代码可读性好且易于维护，二次开发的成本低，在不追求极致的性能要求下，JSON是首选。

方案简述
以key-value的形式，对gcap对象赋值。做key值判断，来满足前后向兼容。

库的选择
库的选择上主要考虑 接口的易用程度、引入开发的成本、是否可商用和性能。
这里我们选择了c++下非常主流的nlohmann/json。

• 接口的易用程度？
  十分好用，现代C++网格，用起来相当简洁。
• 引入开发的成本？
  只需包含一个头文件即可调用接口，低成本开发。
• 是否可商用？
  MIT协议授权开源，可商用，可做修改。
• 性能？
  关于28个开源的C++ JSON库的评测，可以看到在内存使用上还是序列化反序列化的速度上，nlohmann/json都有着中等偏上的表现。

数据加密
可使用库里的bson格式，对接口进行二次封装，将序列化的json转成字节序列，或者可考虑使用其他的加密算法，目前来看不是十分必要。

问题隐患

• 查找key值接口的效率，频繁查找是否会对性能产生影响
• 读写大JSON是否会对内存和效率有较大影响
• 对结构体等复杂类型的支持？是否需要对接口做封装