Java 使用 application/json 比 text/plain 的优势？

Advantages of using application/json over text/plain?

提问by stevebot

Is there any performance advantage of using content type application/json sending an object serialized to json over text/plain? I know many frameworks (like Spring) can map and serialize data based on the content type, but in general I find that this process is easy enough that it isn't a compelling reason to use application/json over text/plain for JSON objects.

使用内容类型 application/json 通过文本/纯文本发送序列化为 json 的对象是否有任何性能优势？我知道许多框架（如 Spring）可以根据内容类型映射和序列化数据，但总的来说，我发现这个过程很简单，因此对于 JSON 对象使用 application/json over text/plain 并不是一个令人信服的理由.

采纳答案by Stephen C

Let's assume that you are talking about using JSON versus a custom format (using MIME type text/plain) for passing structured data.

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

Performance may be broken down into different components; e.g.

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

• relative time taken to encode the content into the format,
• relative time taken to decode the format to give you the original content, and
• relative size of encoded content.

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

In theory, we can say that a hypothetical optimally designed and implemented custom format will be no slower or no less dense than JSON. (The "proof" is obvious. Choose an optimal implementation of JSON and make some minor change to the format that doesn't affect performance.)

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

In reality though, you have to compare performance of actual formats and actual implementations. The answer therefore that the performance really depends on how good a job you do of designing and implementing the format and its associated encoding/decoding software. Furthermore, it also depends on how you implement JSON. There are a number of server-side JSON libraries with different performance characteristics, as well as different ways of mapping data from / to "native" data structures.

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

This brings us to the real advantages of JSON (and XML) over custom formats.

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

• With JSON and XML, there are libraries available for any mainstream language you chose to use to assist in encoding and decoding content. With a custom format, you have to roll your own encoding / decoding for the client and server sides.

• With JSON and XML, there are standards that say what is well-formed that allow other people to implement encoders / decoders. With a custom format, you have to write the specification yourself if you want other people to be able to implement your format.

• JSON and XML have standard ways of dealing with issues like charset encoding and "meta" characters appearing in data. With a custom you have to understand and address these issues your self. (And if you don't, you are likely to get into difficulty down the track.)

• Ease of change. It is a relatively simple matter to evolve a JSON / XML based format. But with a custom format, you have (at least) got more work to do, and depending on your design choices, it could be very difficult.

• 对于 JSON 和 XML，您可以选择使用任何主流语言来辅助编码和解码内容的库。使用自定义格式，您必须为客户端和服务器端滚动自己的编码/解码。

• 对于 JSON 和 XML，有一些标准说明什么是格式良好的，允许其他人实现编码器/解码器。对于自定义格式，如果您希望其他人能够实现您的格式，您必须自己编写规范。

• JSON 和 XML 有处理字符集编码和数据中出现的“元”字符等问题的标准方法。对于自定义，您必须自己了解并解决这些问题。（如果你不这样做，你很可能会在赛道上遇到困难。）

• 易于更改。发展基于 JSON/XML 的格式是一件相对简单的事情。但是对于自定义格式，您（至少）有更多的工作要做，并且根据您的设计选择，这可能非常困难。

For most application, these issues matter far more than performance. And that's why JSON or XML are widely used.

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

FOLLOWUP

跟进

But what if instead you assume that I'm not using a custom implementation and compare sending JSON with a mime type of text/plain to that of mime type application/json?

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

Then the answer is that it makes almost noperformancedifference.

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

• You save 6 bytes in the HTTP request or response header because the mime type string is shorter, but this is insignificant for typical HTTP messages whose sizes are measured in thousands of bytes.
• Using a "text/plain" content type makes no difference to the work that needs to be done to encode / decode the request or response messages ... apart from the time taken to compare / copy 6 extra bytes, which is probably too small to measure.

• 您在 HTTP 请求或响应头中节省了 6 个字节，因为 MIME 类型字符串更短，但这对于大小以千字节为单位的典型 HTTP 消息来说无关紧要。
• 使用“文本/纯文本”内容类型对编码/解码请求或响应消息所需的工作没有区别......除了比较/复制 6 个额外字节所花费的时间，这可能太小了测量。

In addition, using an inaccurate MIME type is (arguably) a violation of the HTTP specs. If you do this:

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

• it is more likely that the receiver will mishandle the response; e.g. fail to decode it, or show it in a browser window, and

• you may break HTTP content type negotiation, assuming that your client or server uses it.

• 接收方更有可能错误处理响应；例如无法解码它，或在浏览器窗口中显示它，以及

• 您可能会破坏 HTTP 内容类型协商，假设您的客户端或服务器使用它。

In short, I can think of no goodreason to do this, and a few goodreasons not to do it.

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

回答by Peter Lawrey

JSon is basically a format of plain text. As such it can't be faster than the best plain text format. (It could be faster than a poorly chosen plain text format) JSon is used because it makes encoding and decoding easier and is fairly human readable for many types of data, esp complex ones.

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

If you are looking for an alternative to which you are using now, perhaps you could give some more details of the data you are sending and we can suggest alternatives.

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

回答by Alfred

JSON is probably going to be faster because of major optimizations(C code) to JSON-engine. For example V8's JSON.parse() is extremely fast.

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

回答by Vanchinathan Chandrasekaran

JSON will eventually become the widely accepted format along with xml. JSON's acceptance is growing pretty quickly, which makes it a smarter choice over text , keeping the future in mind.

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

回答by Soundpin

From other advantages strings JSon formatted are similar javascript Object declaration so they permit simpler and faster parsing.

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

JSon string: {name:value name2:value}

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

Very easy to tranform to javascript Object.

很容易转换为 javascript 对象。

回答by Ives.me

Here is the json.org description(LOL) and I couldn't agree more:

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

JSON: The Fat-Free Alternative to XML

JSON：XML 的无脂肪替代品

Here you find there are Json libraries for almost all languages.

在这里你会发现几乎所有语言都有 Json 库。

http://www.json.org/

http://www.json.org/

Json is so easy with Jquery http://api.jquery.com/jQuery.getJSON/

Json 使用 Jquery 非常简单http://api.jquery.com/jQuery.getJSON/

One of the best texts I've found about Json http://ascherconsulting.com/what/are/the/advantages/of/using/json/

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

Because JSON was designed for the purpose of serializing and unserializing data being sent to and from JavaScript applications, the advantages of using JSON relate to the advantages of JSON over other means of serialization. The most well-known means of serializing data for transmission to and from applications at present is XML. Yet, XML is a rather cumbersome means of serialization. First, the sender must encode the data to be serialized based on a document type definition that the recipient understands. Doing so creates a great deal of extra padding around the actual data no matter which DTD is used. So, the size of XML documents is often fairly large in comparison with the actual set of values they contain. Second, the recipient must receive the stream of XML and decode the data in order to then put that data into memory. In comparison, the serialization of data using JSON by the sender is relatively quick and compact because the structure of JSON reflects the structure of standard programming data types and the encoding mechanism adds only the minimum number of characters required to indicate the structure and value of the data. Once the recipient receives the JSON serialized data, then, the only processing needing to be done is to evaluate the text of the string using either JavaScript's built-in eval function or a compatible function in another language. The other standard comparison is YAML, which is able to serialize complex data sets without relying upon a DTD and needs a simpler parser to both read and write than XML. However, even the simplified YAML parsers generally require more time and generate larger serialized data streams than JSON.

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