为什么 JSON 很重要？答案

【问题标题】：Why is JSON important?为什么 JSON 很重要？
【发布时间】：2009-04-29 07:50:06
【问题描述】：

我最近才听说 JSON（Javascript 对象表示法）。谁能解释为什么它被认为（某些网站/博客/等）很重要？我们已经有了 XML，为什么 JSON 更好（除了“原生于 Javascript”）？

编辑：嗯，主要答案主题似乎是“它更小”。但是，它允许跨域获取数据这一事实对我来说似乎很重要。或者这在实践中没有（还）很多使用吗？

【问题讨论】：

我听说他们要把 XML 重命名为 OML（Over Engineered Markup Language）
JSON 如何处理不同的字符编码（就像 XML 一样）。 JSON 表示中是否存在隐式字符编码？
允许从另一个域获取数据并不是 XML 或 JSON 格式所固有的特性。这是与浏览器相关的事情。
@Brian Agnew：“JSON 文本应以 Unicode 编码。”，参见 RFC 4627 (tools.ietf.org/html/rfc4627) 中的“3. 编码”，“因为 JSON 文本的前两个字符将始终如果是 ASCII 字符 [RFC0020]，则可以通过查看前四个中的空值模式来确定八位字节流是 UTF-8、UTF-16（BE 或 LE）还是 UTF-32（BE 或 LE）八位字节。[...]"

标签： javascript xml json dataformat

【解决方案1】：

XML 有几个缺点：

很重！
它提供了与 Javascript 对象模型不完全相同（但非常相似）的内容的分层表示。
Javascript 随处可用。无需任何外部解析器，您可以直接使用 JS 解释器处理 JSON。

显然，它并不是要完全取代 XML。对于基于 JS 的 Web 应用程序，它的优点可能很有用。

【讨论】：

“Javascript 无处不在”是什么意思？如果我将我的 Java 应用程序连接到 CouchDb 实例，我有本地可用的 XML 解析器，但没有 Javascript 解析器。
在这个意义上的任何地方都意味着“在每台计算机上（使用现代浏览器）。”
@Rabarberski：完全相同的对象模型也是一个巨大的优势，但有时可能会被低估。
@Mehrdad。请注意我上面的示例 - Java/CouchDb 不涉及浏览器
@Cheeso - eval() 也建议不要使用，因为它可能导致 XSS 攻击。

【解决方案2】：

JSON 通常比等效的 XML 小得多。较小的传输意味着更快的传输，从而带来更好的用户体验。

【讨论】：

我不同意 json 更小。 <person name='John Doe' tags='friend male'/> 是紧凑的 XML 格式。 44 个字符。紧凑的 json 为：{person:{"name":"John Doe","tag":["friend","male"]}} 52 个字符。有 25% 的差异，有利于 XML。 XML 可以更大，但不必如此。
我同意，因此我使用“一般”这个词。一旦有了复杂项目的数组，XML 就会比 JSON 大。当然，您对“一般”一词的误读不值得投反对票吗？
您的压缩 JSON 不正确，应该是 {"name":"John Doe","tag":["friend","male"]}。这使它有 45 个字符，仍然比 XML 大，但仅大 1 个字符。

【解决方案3】：

JSON 更加简洁。 XML：

<person>
    <name>John Doe</name>
    <tags>
        <tag>friend</tag>
        <tag>male</tag>
   </tags>
</person>

JSON：

{"name": "John Doe", "tags": ["friend", "male"]}

重叠功能也更少。例如，在 XML 中，选择使用元素（如上）与属性（<person name="John Doe">）之间存在矛盾。

【讨论】：

忽略多余的空格，这大约是 44 个字符与 78 个字符，但请记住，任何单个子元素（如 name）都可以替换为属性（保存另外 7 个左右的字符）。
@Steve，什么时候可读性对数据交换格式很重要？
@Steve：对于人类来说格式正确（用于配置时会很理想），JSON 比 XML 更易于阅读且更紧凑。
我认为可读性非常重要，但您可以使用标签和换行符格式化 JSON 以匹配 xml。
我不同意 json 更小。 <person name='John Doe' tags='friend male'/> 是紧凑的 XML 格式。 44 个字符。紧凑的 json 为：{person:{"name":"John Doe","tag":["friend","male"]}} 52 个字符。有 25% 的差异，有利于 XML。 XML 可以更大，但不必如此。

【解决方案4】：

JSON 之所以流行，主要是因为它提供了一种绕过 Web 浏览器中使用的同源策略的方法，从而允许混搭。

假设您正在域 A 上编写 Web 服务。您无法从域 B 加载 XML 数据并对其进行解析，因为这样做的唯一方法是 XMLHttpRequest，而 XMLHttpRequest 最初受到同源限制只与包含页面相同域中的 URL 对话的策略。

事实证明，由于各种原因，您被允许跨来源请求

（作为练习留给读者的额外问题：为什么

当然，返回一个仅由对象字面量组成的

随着混搭的普及，人们意识到 JSON 通常是一种方便的数据交换格式，尤其是当 JavaScript 是通道的一端时。例如，JSON 在 Chromium 中被广泛使用，即使在 C++ 双方都使用的情况下也是如此。它只是表示简单数据的一种很好的轻量级方式，在许多语言中都存在良好的解析器。

有趣的是，使用

【讨论】：

我不明白这个起源故事。编写一个返回（未解析的）XML 文档的 JavaScript 函数很简单。您可以使用此 hack 来提供 XML，就像使用它来提供全新的序列化格式一样容易。
是的，你可以只返回一个 XML 字符串然后解析它。但是字符串必须在 JavaScript 字符串中小心地转义。人们发现自己在动态生成：returnData("<data foo=\"bar\">...</foo>") ... 并问自己，当他们可以直接返回对象和数组时，为什么还要麻烦。一旦你沿着这条路走下去，你就会意识到，在没有单独的解析阶段的情况下使用本机对象和数组通常只是一个更好的主意。但我认为混搭是 JSON 的起源，或者至少是几个主要原因之一。

【解决方案5】：

如果您使用 Javascript，那么 JSON 会容易得多。这是因为 JSON 可以直接评估为 Javascript 对象，这比 DOM 更容易使用。

从上面借用并稍微修改 XML 和 JSON

XML:

<person>
    <name>John Doe</name>
    <tag>friend</tag>
    <tag>male</tag>
</person>

JSON:

{ person: {"name": "John Doe", "tag": ["friend", "male"]} }

如果你想用 XML 获取第二个标签对象，你需要使用功能强大但冗长的 DOM api：

var tag2=xmlObj.getElementsByTagName("person")[0].getElementsByTagName("tag")[1];

而对于通过 JSON 传入的 Javascript 对象，您可以简单地使用：

var tag2=jsonObj.person.tag[1];

当然，Jquery 使 DOM 示例更加简单：

var tag2=$("person tag",xmlObj).get(1);

但是，JSON 只是“适合”Javascript 世界。如果您使用它一段时间，您会发现与涉及基于 XML 的数据相比，您的脑力开销要少得多。

以上所有示例都忽略了一个或多个节点可用、重复的可能性，或者该节点只有一个或没有子节点的可能性。但是，为了说明 JSON 的原生特性，要使用 jsonObj 执行此操作，您只需：

var tag2=(jsonObj.person && jsonObj.person.tags && jsonObj.person.tags.sort && jsonObj.person.tags.length==2 ? jsonObj.person.tags[1] : null);

（有些人可能不喜欢这么长的三进制，但它确实有效）。但是 XML 会（在我看来）更糟糕（我不认为你会想要采用三元方法，因为你会一直调用 dom 方法，这可能需要根据实现再次完成工作）：

var tag2=null;
var persons=xmlObj.getElementsByTagName("person");
if(persons.length==1) {
    var tags=persons[0].getElementsByTagName("tag");
    if(tags.length==2) { tag2=tags[1]; }
}

Jquery（未经测试）：

var tag2=$("person:only-child tag:nth-child(1)",xmlObj).get(0);

【讨论】：

【解决方案6】：

这些网页可能会有所帮助：

【讨论】：

来自第二个链接“如果数据格式为 XML，则 Ajax 仅限于从 Ajax 应用程序所在的同一域（网站）获取数据。如果数据格式为 JSON，则 Ajax可以跨域旅行”这不对吧？
布莱恩，我认为你是对的。建议第二个链接被视为可疑 - 它似乎只是在其任务中回答了问题，即使它未能在某些地方实现它。
部分正确。我相信使用 JSONp 您可以在 Firefox 中跨域旅行。

【解决方案7】：

这取决于你要做什么。这里有很多答案更喜欢 JSON 而不是 XML。如果你仔细观察，差别不大。

如果你有一棵对象树，你只会得到一个 javascript 对象树。如果您看一下使用 OOP 样式访问的压力，而不是回头看您。假设您有一个在树中构造的 A、B、C 类型的对象。您可以轻松地将它们序列化为 JSON。如果你把它们读回来，你只会得到一个 javascript 对象树。要重建您的 A、B、C，您必须手动将值填充到手动创建的对象中，或者进行一些黑客操作。听起来像是解析 XML 和创建对象？嗯，是的:)

如今，只有最新的浏览器提供对 JSON 的原生支持。要支持更多浏览器，您有两个选择：a）您在 javascript 中加载一个 json 解析器来帮助您解析。那么，这听起来有多胖？我经常看到的另一个选项是 eval。您可以对 JSON 字符串执行 eval() 来获取对象。但这引入了一系列全新的安全问题。指定了 JSON，因此它不能包含函数。如果您不检查对象的功能，有人可以轻松地向您发送正在执行的代码。

所以这可能取决于您更喜欢什么：JSON 或 XML。最大的区别可能是访问事物的方式，无论是脚本标签 XMLHTTPRequest ......我会决定使用什么。在我看来，如果浏览器中对 XPATH 有适当的支持，我通常会决定使用 XML。但时尚是针对 json 并在 javascript 中加载额外的 json 解析器。

如果您无法决定并且您知道您需要一些真正强大的东西，您就必须看看 YAML。阅读有关 YAML 的内容非常有趣，可以更深入地了解该主题。但这真的取决于你想要做什么。

【讨论】：

【解决方案8】：

JSON 是一种在 Javascript 对象中序列化数据的方法。语法取自语言，因此处理 Javascript 的开发人员应该熟悉它，并且 - 作为对象的字符串化 - 它是一种在浏览器内进行交互的更自然的序列化方法，而不是成熟的 XML 衍生产品（包含所有暗示的任意设计决策）。

它轻巧直观。

【讨论】：

【解决方案9】：

JSON 是一种基于文本的对象序列化格式，它比 XML 更轻量级，并且直接与 JavaScript 的对象模型集成。这就是它的大部分优势。

它的缺点（与 XML 相比）大致是：可用工具较少（忘记标准验证和/或转换，更不用说大多数编辑器中的语法突出显示或格式检查），不太可能是人类可读的（JSON 和 XML 的可读性存在巨大差异，因此这必然是一个模糊的陈述），与 JavaScript 的紧密集成导致与其他环境的集成不那么紧密。

【讨论】：

【解决方案10】：

并不是说它更好，而是它可以将许多东西捆绑在一起，从而无需手动解析即可实现无缝数据传输！

例如 javascript -> C# web 服务 -> javascript

【讨论】：

考虑到即使在 JavaScript 中，JSON 通常也不会被评估，而是出于安全原因进行解析，因此我认为这不算作一个论点。
@Benedikt Eger - 有一个新的 eval 替代品即将到来，它将评估 JSON 而没有 eval 的风险。另外，如果 JSON 来自受信任的来源，它通常会被评估。