使用 application/json 优于 text/plain 的优势？ [关闭]答案

【问题标题】：Advantages of using application/json over text/plain? [closed]使用 application/json 优于 text/plain 的优势？ [关闭]
【发布时间】：2011-05-20 01:00:48
【问题描述】：

使用内容类型 application/json 发送序列化为 json 的对象而不是 text/plain 有任何性能优势吗？

我知道许多框架（如 Spring）可以根据内容类型映射和序列化数据，但总的来说，我发现这个过程很简单，因此使用 application/json 而不是 text/plain 并不是一个令人信服的理由用于 JSON 对象。

例子：

xhr.setRequestHeader("Content-type","text/plain");
// or
xhr.setRequestHeader("Content-type","application/json");
xhr.send(JSON.stringify({"foo": "bar"}));

【问题讨论】：

你是说指定了哪种mime类型，还是说使用json？
两者。我可以使用纯文本内容类型或应用程序 json 内容类型发送对象的 json 表示。
我很失望，因为没有人回答为什么我会明确选择“application/json”而不是“text/plain”作为内容类型，尽管 json 本身实际上仍然是纯文本。毕竟我不会选择“application/html”或“application/css”吧？
@Gherman 当您尝试使用 text/plain 发送请求但出现错误时会使用它，但是当您尝试使用 application/json 时它奏效了。

标签： javascript java json xmlhttprequest httpwebrequest

【解决方案1】：

假设您正在讨论使用 JSON 与自定义格式（使用 MIME 类型 text/plain）来传递结构化数据。

性能可以分解为不同的组件；例如

将内容编码为格式所用的相对时间，
解码格式以提供原始内容所需的相对时间，以及
编码内容的相对大小。

理论上，我们可以说一个假设的优化设计和实现的自定义格式不会比 JSON 慢或密度不低。（“证明”很明显。选择 JSON 的最佳实现，并对不影响性能的格式进行一些小改动。）

但实际上，您必须比较实际格式和实际实现的性能。因此，性能实际上取决于您在设计和实现格式及其相关的编码/解码软件方面做得有多好。此外，它还取决于您如何实现 JSON。有许多具有不同性能特征的服务器端 JSON 库，以及将数据从 / 映射到“本机”数据结构的不同方式。

这让我们了解到 JSON（和 XML）相对于自定义格式的真正优势。

借助 JSON 和 XML，您可以使用任何主流语言的库来协助对内容进行编码和解码。使用自定义格式，您必须为客户端和服务器端滚动自己的编码/解码。
对于 JSON 和 XML，有一些标准说明什么是格式良好的，允许其他人实现编码器/解码器。使用自定义格式，如果您希望其他人能够实现您的格式，则必须自己编写规范。
JSON 和 XML 具有处理字符集编码和出现在数据中的“元”字符等问题的标准方法。对于习惯，您必须自己了解和解决这些问题。（如果你不这样做，你很可能会遇到困难。）
易于更改。演化基于 JSON/XML 的格式是一件相对简单的事情。但是使用自定义格式，您（至少）还有更多工作要做，而且根据您的设计选择，这可能会非常困难。

对于大多数应用程序，这些问题远比性能更重要。这就是 JSON 或 XML 被广泛使用的原因。

跟进

但是，如果您假设我没有使用自定义实现，并将发送带有 mime 类型 text/plain 的 JSON 与 mime 类型 application/json 进行比较，该怎么办？

那么答案是它几乎没有 性能差异。

您在 HTTP 请求或响应标头中节省了 6 个字节，因为 mime 类型字符串较短，但这对于大小以数千字节为单位的典型 HTTP 消息来说是微不足道的。
使用“text/plain”内容类型对编码/解码请求或响应消息所需的工作没有任何影响...除了比较/复制 6 个额外字节所花费的时间，即可能太小而无法测量。

此外，使用不准确的 MIME 类型（可以说）违反了 HTTP 规范。如果你这样做：

接收者更有可能错误地处理响应；例如无法解码，或在浏览器窗口中显示，并且
假设您的客户端或服务器使用它，您可能会中断 HTTP 内容类型协商。

简而言之，我想不出这样做的好理由¹，以及不这样做的一些好理由。

^{1 - 一般情况下。显然，会有边缘情况......}

【讨论】：

但是，如果您假设我没有使用自定义实现，并将发送带有 mime 类型 text/plain 的 JSON 与 mime 类型 application/json 进行比较，该怎么办？
我注意到谷歌以 txt 格式的 JSON 格式提供自动完成建议。我想知道他们从中获得了什么
可能它会阻止某些浏览器在有害的上下文中“呈现”JSON。当乘以数十亿个请求时，可能节省 6 字节非常重要。可能他们获得的很少/什么都没有......
当我意识到 Amazon AWS SNS 使用“text/plain”作为 HTTPS 主题订阅者的内容类型时，我想知道这一点。 “他们为什么不将其作为应用程序/json 发送？” 6 个字节就是 6 个字节，虽然大概只是遗留问题。
每条消息节省 6 个字节对于每年处理大量小型 HTTP 请求/响应的服务来说可能是一项重大节省。我猜他们测量了它，并认为这是值得的......对于他们的应用程序。我不知道。问他们。

【解决方案2】：

JSON 基本上是一种纯文本格式。因此，它不能比最好的纯文本格式更快。（它可能比选择不当的纯文本格式更快）使用 JSon 是因为它使编码和解码更容易，并且对于许多类型的数据（尤其是复杂的数据）具有相当的人类可读性。

如果您正在寻找您现在正在使用的替代方案，也许您可以提供更多关于您正在发送的数据的详细信息，我们可以建议替代方案。

【讨论】：

我不是在寻找替代品，就像你说的，json是纯文本的格式，所以可以作为纯文本发送。我只是不相信这两种做法是否更有效。

【解决方案3】：

JSON 最终将与 xml 一起成为被广泛接受的格式。 JSON 的接受度正在迅速增长，这使它成为比 text 更明智的选择，同时牢记未来。

【讨论】：

【解决方案4】：

这是 json.org 的描述（LOL），我完全同意：

JSON：XML 的无脂肪替代方案

在这里您可以找到几乎所有语言的 Json 库。

http://www.json.org/

Jquery 让 Json 变得如此简单http://api.jquery.com/jQuery.getJSON/

我发现的关于 Json http://ascherconsulting.com/what/are/the/advantages/of/using/json/ 的最佳文本之一

因为 JSON 是为序列化的目的和反序列化发送到和的数据从 JavaScript 应用程序，使用 JSON 的优势与 JSON相对于其他方式的优势序列化。最知名的序列化数据的方法与应用程序之间的传输目前是XML。然而，XML 是一种比较麻烦的方法序列化。首先，发件人必须对要序列化的数据进行编码在文档类型定义上收件人明白。这样做创建大量额外的填充围绕实际数据，无论哪个使用 DTD。所以，XML 的大小文件通常相当大与实际设置的比较它们包含的值。二、接收者必须接收流 XML 和解码数据，以便然后将该数据放入内存。在比较，数据的序列化发件人使用 JSON 是相对的快速而紧凑，因为 JSON 的结构反映了标准编程数据的结构类型和编码机制添加只有最少的字符数需要指明结构和数据的价值。一旦收件人接收 JSON 序列化数据，然后，唯一需要的处理要做的是评估文本使用 JavaScript 的字符串内置 eval 函数或兼容的以另一种语言运行。这其他标准比较是 YAML，能够序列化复杂的不依赖 DTD 的数据集并且需要一个更简单的解析器读写比XML。然而，甚至简化的 YAML 解析器通常需要更多的时间和生成更大的序列化数据流而不是 JSON。

【讨论】：

【解决方案5】：

由于对 JSON 引擎的主要优化（C 代码），JSON 可能会更快。例如 V8 的 JSON.parse() 非常快。

【讨论】：

【解决方案6】：

从其他优点来看，JSON 格式的字符串类似于 javascript 对象声明，因此它们允许更简单和更快的解析。

JSON 字符串：{name:value name2:value}

很容易转换为 javascript 对象。

【讨论】：