- 主题:定义了一套极简主义的二进制json格式 nbJSON
nbJSON: nano binary JSON
https://zhuanlan.zhihu.com/p/670846500
极简例子放在最前:
"[{ name 张三 age 18 }
{ photoBytes 256(\x00...\xFF) }]"
不使用 冒号: 引号''"" 空白和换行 转义符\
不定义各种长度整型浮点型, 不关心 big/little-endian
只有一种原子,utf8字符串或字节数组 例如:
5(hello)
256(\x00...\xff) 实际占用 3长度+2括号+256=261字节
json 因为盲目抄 c/java, 用转义符描述二进制,占用 400%空间
base64是 133%空间且不能用二进制编辑器可读
本方案直接存二进制,是100%空间
使用长度前缀,避免转义符,前缀也是可读十进制,
括号用于增强可读性,校验纠错
跟JSON一样的数组和关联数组,例如:
[{4(key1)6(value1)4(key2)6(value2)}{5(bytes)3(\x01\x02\x03)}]
相当于json的 [{"key1":"value1", "key2":"value2"}, {"bytes":"\x01\x02\x03"}]
可以在()括号之外加空白, 增强可读性, 例如:
[{ 4(key1)6(value1) 4(key2)6(value2)}
{ 5(bytes)3(\x01\x02\x03) } ]
允许在无需转义时省略长度前缀, 甚至省略长度前缀和括号
[{ key1 value1 key2 value2 }
{ bytes 256(\x00...\xFF) }]
现有的 schemafull 的protobuf,msgpack比较麻烦,
schemaless 的 UBJSON BJdata 半可读, 但数据类型也很复杂,几十种之多, 还要操心 big-enddian 之类的
--
修改:ABCDEFGHJKLM FROM 111.201.28.*
FROM 123.113.97.*
binary, 极简, schemaless, 可读, 省空间(相对于base64)
【 在 ble 的大作中提到: 】
json 能有这么多人用，就是因为他的可读性好，yaml 之所以会取代 json，就是因为不要括号，你这占了哪一点优点呢？如果要最小空间，一堆的序列化方案可用啊。
【 在 ABCDEFGHJKLM 的大作中提到: 】
:
: 不使用 冒号: 引号''"" 空白和换行 转义符\
:
: 只有一种原子,utf8字符串或字节数组 例如:
: 5(hello)
#发自zSMTH-v-@钛星
--
修改:ABCDEFGHJKLM FROM 123.113.97.*
FROM 123.113.97.*
BSON BJSON 都定义了过多的 JSON不存在的东西， regular expressions, JavaScript code blocks 等； 没有保持 JSON 的 simplicity
【 在 milksea 的大作中提到: 】
Mongodb的bson不就干这个的？
【 在 ABCDEFGHJKLM 的大作中提到: 】
:
https://zhuanlan.zhihu.com/p/670846500:
: 不使用 冒号: 引号''"" 空白和换行 转义符\
: ...................
--
FROM 123.113.97.*
扩充了,允许在无歧义的情况下省略长度前缀和括号,
[{ key1 value1 key2 value2 }
{ bytes 256(\x00...\xFF) }]
现在够可读了吗
【 在 speedboy2998 的大作中提到: 】
没看出可读
【 在 ABCDEFGHJKLM 的大作中提到: 】
: binary, 极简, schemaless, 可读, 省空间(相对于base64)
: json 能有这么多人用，就是因为他的可读性好，yaml 之所以会取代 json，就是因为不要括号，你这占了哪一点优点呢？如果要最小空间，一堆的序列化方案可用啊。
:
: ...................
--
FROM 123.113.97.*
省掉冒号,引号,逗号,转义符, 支持二进制
【 在 speedboy2998 的大作中提到: 】
对不起，没觉得针对 JSON 有任何优势。
【 在 ABCDEFGHJKLM 的大作中提到: 】
: 扩充了,允许在无歧义的情况下省略长度前缀和括号,
: [{ key1 value1 key2 value2 }
: { bytes 256(\x00...\xFF) }]
: ...................
--
修改:ABCDEFGHJKLM FROM 123.113.97.*
FROM 123.113.97.*
改key的话自己注意不用特殊字符就可以省略长度和括号
改value的话, 原来json也要用程序来处理转义(或者binary的base64编码)的问题, 现在用程序处理长度前缀, 是一样的
二进制json方案,我这个是唯一可手写拼串和解码, 可以不用库的, 其他方案都太复杂
【 在 foliver 的大作中提到: 】
json能够流行就是在于它一眼就可读，手写也很方便，如果不追求可读，那就有很多替代方案。
你可以看似简化，但是它违反了第一眼可读可写原则，举个例子，改个字段还要考虑同步修改长度，就这一点就不可行。
【 在 ABCDEFGHJKLM 的大作中提到: 】
: 省掉冒号,引号,逗号,转义符, 支持二进制
:
: 【 在 speedboy2998 的大作中提到: 】
: ...................
--来自微微水木3.5.14
--
修改:ABCDEFGHJKLM FROM 123.113.97.*
FROM 123.113.97.*
看完啊, 最下面的最简例子
[{ key1 value1 key2 value2 }
{ bytes 256(\x00...\xFF) }]
json 因为盲目抄 c/java, 用转义符描述二进制,占用 400%空间
base64是 133%空间且不能用二进制编辑器可读
本方案直接存二进制,是100%空间
【 在 gokiller 的大作中提到: 】
[{4(key1)6(value1)4(key2)6(value2)}{5(bytes)3(\x01\x02\x03)}]
相当于json的 [{"key1":"value1", "key2":"value2"}, {"bytes":"\x01\x02\x03"}]
会有正常人觉得上一行可读性比下一行好吗？
--
修改:ABCDEFGHJKLM FROM 123.113.97.*
FROM 123.113.97.*