JSON适合大数据传输吗？跨语言JSON数据传输需要注意什么？

01-16

1、JSON是否适合大数据量的传输？
目前是用商定好的协议，以二进制流的方式传输到对方，对方再根据协议从二进制流中解析出数据。这种方式的坏处特别明显，第一就是经常出错，经常因为双方没有协商清楚，或者因为协议变更没有及时通知到各方等而出现错误，以及因为没有详细的协议文档（以头文件定义的结构体当作文档了），所以新人很难上手。所以现在想用通用的成熟的协议来代替我们自己的协议，开发和维护都比较好。
但是还有有几个疑惑，希望大家能帮忙回答和分析一下：
1、JSON适合大数据传输吗？我们目前是CS模式，未来还有BS模式，服务器和客户端之间的数据大部分每一帧都不大，但是有个功能客户端请求波形数据，这个数据就比较大，最糟糕的可能达到20多万点（目前每个点是4字节二进制流）。
2、数据传输 JSON数据比二进制流数据是不是体积大很多？

3、客户端（c#)和服务端(c)使用的是不同的语言开发,那么两边用不同的JSON解析库，会有什么问题吗？
4、都知道JSON因为是字符型的所以体积才大，那有没有二进制型的JSON呢
另外如果JSON不适合大数据量传输，那么我们就考虑将数据二进制序列化，然后传输到对方再反序列化。这里又又几个疑惑了：
1、客户端和服务端用的语言不同，两边用的是不同的序列化库会不会反序列出来的结果就不一样了。
2、如果我的对象里面带有指针，指向别的数据，那么这个对象二进制序列化，那指针指向的内容能序列化大到数据流当中吗？
反序列之后，指针指向的内容还在吗？

JSON 和 XML 一样在异构应用种可以很方便的传输数据，而 JSON 由于比 XML 更小更轻量所以在 Web 应用种更加流行。

但是随着应用层协议变的复杂，一般也会使用 JSON Schema 进行约束。

如果不是做开放平台，而只是前后的交互，可以试试 Protocol Buffer。

20多万点，一个4字节，

80万字节，800，000字节，800k左右，对吧。

这个数据量问题不大，json加gzip压缩可以的。

接口格式选用json，传输前可以约定压缩一下。

这个量级应该没什么问题。

json和语言无关，非常适合异构。

最简单的就是5分钟生成一个json 直接测试时长能否接受。

谢邀！JSON 作为一种更轻、更友好的 Web services客户端的格式（多采用浏览器的形式或访问 REST风格 Web服务的Ajax应用程序的形式）引起了 Web 服务供应商的注意。作为使用者，JSON的一些优点和不足还是值得大家注意的，以便在开发项目中合理利用。

JSON剖析：优点和不足

对于JSON，首先要明白JSON和XML一样也是一种简单文本格式。相对于XML，它更加易读、更便于肉眼检查。在语法的层面上，JSON与其他格式的区别是在于分隔数据的字符，JSON中的分隔符限于单引号、小括号、中括号、大括号、冒号和逗号，乍看上去，使用JSON的数据分隔符的优点可能并不那么明显，但存在一个根本性的缘由：它们简化了数据访问。使用这些数据分隔符时， JavaScript引擎对数据结构（如字符串、数组、对象）的内部表示恰好与这些符号相同。

这将开创一条比DOM技术更为便捷的数据访问途径。下面列举几个JavaScript代码片段来说明这一过程，这些代码片段会访问先前的JSON代码片段中的信息：

访问JSON中的名称： addressbook.name

访问JSON中的地址： addressbook.address.street

访问JSON中的电话号码第一位：addressbook.address.phoneNumbers[0]

如果您具备DOM编程经验，就能很快地看出区别；新手可以参看 Document Object Model 的这一外部资源，这里提供了关于数据导航的实例。

JSON的另一个优点是它的非冗长性。在XML中，打开和关闭标记是必需的，这样才能满足标记的依从性；而在JSON中，所有这些要求只需通过一个简单的括号即可满足。在包含有数以百计字段的数据交换中，传统的XML标记将会延长数据交换时间。目前还没有正式的研究表明JSON比XML有更高的线上传输效率；人们只是通过简单的字节数比较发现，对于等效的JSON和XML有效负载，前者总是小于后者。至于它们之间的差距有多大，特别是在新的XML压缩格式下它们的差距有多大，有待进一步的研究。

此外，JSON受到了擅长不同编程语言的开发人员的青睐。这是因为无论在Haskell中或 Lisp中，还是在更为主流的C#和PHP中，开发都可以方便地生成JSON。

很多事物都具有两面性，JSON亦然。JSON的非冗长性也不例外，为此JSON丢失了XML具有的一些特性。命名空间允许不同上下文中的相同的信息段彼此混合，然而，显然在JSON中已经找不到了命名空间。JSON与XML的另一个差别是属性的差异，由于JSON采用冒号赋值，这将导致当XML转化为JSON时，在标识符（XML CDATA）与实际属性值之间很难区分谁应该被当作文本考虑。

另外，JSON片段的创建和验证过程比一般的XML稍显复杂。从这一点来看，XML在开发工具方面领先于JSON。以上就是笔者为大家总结的几点关于JSON的有点与不足，由于写作匆忙，还请读者包涵。

来来来，你们谁来解析一个 200MiB 的 JSON。代码不崩算我输。

1.BSON,好像mongodb有用。（网上有bson空位置太多，浪费字节较多的描述）

2.Google Protocol buffer，[ http://npmjs.org](https://www.npmjs.com/package/protobufjs)上有包。比自己拼接typedArray省心多了。

我做过：websocket传输图片的坐标和颜色信息给浏览器。

用png工具包读取图片raw信息，得到typedArray，想要附加点标识信息再传给浏览器。

用json传给前端，好像40倍图片大小。

拼接typedArray，在浏览器上截取TypedArray，可以按原图数据量得到传输。

用protocol buffer，几乎跟自己手动拼接typedArray一样。

所以，说到大量，我认为json不合适。

BSON？BSON (Binary JSON) Serialization

为什么不用 protocol buffer？

google protobuf 听说做通信协议不错

[Msgpack](MessagePack: It"s like JSON. but fast and small.)

不适合，我们大数据传输都是tab分割的csv文件，压缩后传输