如果 JSON 支持二进制数据…这里暂名为 UDN ：
基本规则：
JSON仅存在 6 种数据类型，而 UDN 扩展到了 8 种：
- 1. 空类型(null)：
null - 2. 布尔类型(Bool):
true或false - 3. 64位整数(I64):
512i- 以
i结尾，最多19位有效数字
- 以
- 4. 64位浮点数(F64):
-12.81f- 以
f结尾，可用e/E科学计数法，最多17位有效数字，科学计数法最多4位（十进制）
- 以
- 5. 字符串(String):
"this is a string"- 转义字符仅包含
\"\\，其余字符保持原样。
- 转义字符仅包含
- 6. 映射(Map):
{ String: UDN, ... }- 类似 JSON 中的 Object，是键值对，键是字符串，值是任意UDN类型
- 允许最后一个键值对后面存在
,，这是可选的，但建议添加,保证风格一致
- 7. 数组(Vec):
[ UDN, ... ]- 类似 JSON 中的 Array ，可以内涵多个 UDN 元素，也可以是空数组
- 允许最后一个元素后存在
,，这是可选的，但建议添加,保证风格一致
- 8. 二进制数据(Binary):
(size:data)size是一个十进制无符号整数，表示后续二进制数据的字节长度data是二进制数据，必须紧贴:以避免数据访问错误- 由于给定了数据长度，可以直接从开始位置连续读取
size个字节 - 比如
(5:012Aa)反序列化后应该是[48, 49, 50, 65, 97]（0的ASCII码是48） - 注意：二进制数据部分可能无法正常可视化。
例：
{
"name": "例子\" 字符串",
"list": [
-517i,
51.21561123f
-251.51e-11f
true,
false,
null,
],
"data": (5:xxxx),
}优势：
一、直接提供了二进制类型，而无需将数据转 base64 编码后转字符串，可依据 size 快速读取内容。
二、JSON 的 Number 不限制长度，但多数编程语言并不支持过长的整数。这里将 Number 类型拆分成了整数和浮点数，并限制了二进制位数为 64 位。这样可以避免单一类型（浮点数）存储整数时的精度缺失问题。此外，整数的序列化反序列化远快于浮点数。
三、易于解析。大部分类型的首字符是不同的，解析时可以根据首字符判断数UDN的数据类型。整数和浮点数虽然首字符可能重合，但后缀不同，依然可以快速解析。字符串格式限制了转义字符的类型，减少了解析需要判断的内容，加快了速度。
四、映射和数组的最后一个子元素末尾的 ,是可选的 ，这降低了反序列化和序列化的设计难度，也让用户更容易使用。（参考算法题，结果有多行输出，每行输出多个元素并以空格分隔，但每行最后一个元素后不能有空格，这就会需要恶心的特判）
缺点：
一、使用 i/f 后缀。这两个后缀显著降低了反序列化难度，但用户手写时确实较为繁琐。
二、由于存在二进制数据，此格式有时可能无法正常的可视化输出（当使用了二进制数据结构时），因为像 Rust 等语言的字符串类型要求内部字符必须有效。
最后：
此格式的序列化和反序列化器的实现非常简单（甚至比 JSON 更容易，虽然 UDN 类型更多，但少了许多特判分支），迷枵仅用一个晚上就通过 Rust 实现了。
另外，这依然不支持注释。像 CMake 中的 # 单行注释是可以有的，但会影响解析速度。