json最大长度限制_自己实现一个类 JSON 数据结构

JSON，仅支持极少的数据类型，或者是为了跨平台和语言的兼容性，又或者是因为其他什么原因。总之，它虽然成为现在网络传输接口中最普遍的数据结构，但由于自身限制，在使用过程中它也给开发者带来了一些负担。诸如类型丢失，某些数据无法被序列化而丢失等等。开发者需要非常小心才能理解到自己需要在将对象序列化成 JSON 之前，下一些功夫，才能保证自己的数据被正确传输了。

例如，ES2015 之后引入的 Map 和 Set 类型，使用已经相当普遍，但虽如此，它们依旧没有实现序列化 JSON 的接口，如果尝试使用 JSON.stringify() 来序列化它们，则只会得到一个空对像。即使开发者有意将其在转换之前自己先把元素拷贝到一个标准对象上以便传输，在数据的接收端，依旧不会自动还原为原来的模样。在这个过程中，开发者面临着数据和类型丢失的双重问题。

BSON，一种继承了 JSON 的数据结构，被运用于 MongoDB 上，它革命性的引入了少量的“复合类型”来弥补 JSON 的不足，如 ObjectId, ISODate 等，但也仅仅是为了数据存储和比较的方便，因此并没有大胆地继续开拓其它类型。

我最近在一些个人的“小项目”中，主要是 IPC/TCP 通信上，大概是利用 NodeJS 的集群（cluster）来广播事件和传递数据，其中有一个是要实现一个基于“内存-文件”的集群存储器，用以在集群进程中同步和共享缓存数据。也就是在这个过程中想到了要开发一个新的数据结构来解决 JSON 玄而未决的问题。

当然这个新的数据结构并不只用来做数据保存，最重要的是它能够最大程度解决数据传输过程中丢失类型和状态的问题，并更多地应用在 IPC/RPC 传输上，来保证数据传输端和接收端的数据一致性。

我曾经做过两年的 PHP 开发，在 PHP 中有一对 serialize/unserialize 函数用来序列化和反序列化数据，并且它们支持自定义的数据类型，即开发者自己定义的实现序列化接口（__sleep 和 __wakeup）的类。这个给我很大灵感，几乎一开始我差点就设计成了类似它的数据结构。

但经过了慎重考量之后，我决定使用和 BSON 类似的方案，原因有二：

1. 格式最接近 JSON，且解析器将兼容 JSON/BSON 数据；

2. 支持数据文本格式化，从而支持更丰富的特性，如注释，因此解析器也将兼容 JSONC（JSON with comments）。

这样，数据不但简洁，而且易于阅读。

由于这个数据结构主要用于 IPC/TCP 通讯和数据存储上，为了尽量压缩其长度以减小带宽和磁盘容量，我决定将其设计为双引号可选，即对于支持可以直接作为 JS 对象属性的拉丁字符，不使用双引号。因此这个新的数据结构的模样将会和一个普通和 JS 对象字面量“一模一样”。并且为了使相似度高度还原，它还支持包括所有进制的数字字面量、支持所有 JS 引号的字符串，正则表达式字面量等。

这个新的数据结构，我将其取名为 FRON （/frʌn/，Feature-Rich Object Notation）。

hyurl/fron​github.com

下面是一些 FRON 基本数据类型表示法的示例：

/************************ Literal Types *************************/

除了内置支持的类型之外，FRON 允许使用者注册自定义的类型，从而支持更多类型；并且允许使用别名类型，来把一个新类型注解应用到一个现成的处理方案上，从而实现不同语言偏好上的兼容。另外，FRON 使用了一个内置的复合类型 Reference 来处理数据引用，同时解决了 JSON 引用的重复拷贝和不支持递归引用的问题。

目前 FRON 仅实现了 TypeScript/JavaScript 的 beta 版本，差强人意的是，JS 的运算效率还是跟不上，测试结果表明其序列化和反序列化速度距离 JSON 还有很大距离。为了防止阻塞线程，目前的方案是同时提供了异步版本的函数。虽然如此，在解析过程中依旧需要等待比较长的时间（相对于 JSON）才能够获得最后的结果。

因此，计划是未来使用 rust 这类高性能语言来编写另一个版本，并作为 NodeJS 插件引入，毕竟 IPC/RPC 通信还是要求高响应速度的，光异步处理还远远不够。So, let's keep on.