为什么 JSON 中要使用逗号？

2025/04/05

碰巧的是，我已经写过一篇关于为什么逗号不好的文章。除了逗号可能值得重新思考并用其他东西代替之外，我们没有得出任何具体的结论。

在所有可以减少逗号的语言和格式中……有一种格式绝对突出。 从某种意义上说……在这种格式中，逗号不仅仅是一些错误的设计决策导致挥之不去的不良影响，而是一种精心设计的折磨工具，显然只为了让你的生活更加糟糕。

那就是 JSON。

JSON 源自一种编程语言的数组和字典字面量，这种语言以 10 天 内设计完成（然后突然接管了互联网）而闻名。JSON 已经变得无处不在；它的简单性是 XML 的神秘复杂性、许多二进制格式的不可读性，以及 S-Expressions 的……嗯……奇怪的异域风情的绝佳替代品。 格式真的很简单！ 看：

{
 "name": "小明 (xiǎo míng)"
 "age": 25
 "isStudent": true
 "grades": null
 "contact": {
  "email": "xiaoming@example.com"
  "phone": "123-456-7890"
  "address": {
   "street": "123 Main St"
   "city": "Beijing"
   "zipCode": "100000"
  }
 }
 "interests": ["编程 (biānchéng)" "reading" "travel"]
 "achievements": [
  {
   "title": "First Place"
   "year": 2022
   "details": {
    "competition": "Coding Challenge"
    "score": 98.5
   }
  }
  {
   "title": "Second Place"
   "year": 2023
   "details": {
    "competition": "Math 学习 (xuéxí)"
    "score": 95.2
   }
  }
 ]
 "favoriteNumbers": [7 42 99]
 "personalQuote": "学习 (xuéxí) is a lifelong journey!"
 "generatedBy": "Claude Sonnet 3.7"
}
     

现在……你注意到什么了吗？ 我们……可能摆脱了……某些东西。

与 Syntax is Overrated 中的推测不同……上面的代码框不仅仅是有点暗示我们可以做出一些改变。 不，上面这个，是一个真正可用的文件格式。

你拿到 JSON，然后扔掉逗号。

想想看！ 列表已经有空格分隔的元素。 字典呢？ 消耗一个键，期望一个“:”，消耗值。 继续。 仍然容易解析。

从这个角度来看，添加逗号感觉像是一个邪恶的计划，会产生更多的语法错误，而没有任何明显的好处。

公平地说，单行字典可能不太容易阅读：

{"key1": "value1" "key2": "value2"}

……但是你仍然可以使用冒号轻松找到哪些是键，哪些是值。 另外，为什么不添加可选逗号？ 基本上把它当作空白字符来处理！ （……就像 JavaScript 中行尾分号是可选的一样！）

为什么没有其他人...

碰巧的是，原始 JSON 格式中逗号的问题引起了很多人的注意。 事实上，有一种新的格式（……修正案？）叫做 JSON5，旨在修复……其中的一些问题。

遗憾的是，他们的野心不够大。

具体来说，JSON5 允许使用尾随逗号，其方式与其他编程语言使用分号的方式类似。 因此，不必在每个元素之后，除了最后一个 插入一个无用的分隔符（如果您要移动/比较行，这非常烦人），现在您可以遵循更简单的规则：在每个元素之后插入无用的分隔符。 这更好。

  {
   "title": "Second Place",
   "year": 2023,
   "details": {
    "competition": "Math",
    "score": 95.2,
   },
  },
     

然而。

这篇文章中出现汉字并非巧合，因为没有什么是巧合； 这应计入“利用 AI 系统的奇怪副作用”之下。 以后可能会有更多关于这方面的文章。

……作者：Simon Safar (simon@simonsafar.com)； 另请参见：GitHub。（注意：在此处放置各种链接。）