关于 json 的写法问题，有一点不太理解？

为了通用。别的语言

@buxudashi 我觉得是为了偷懒，既然 Javascript 语言能顺利解析 keyname, 没理由别的语言不可以。

把 json 当成手写配置文件，平白无故多了要打那么多双引号，还不能用单引号替代，就不太开心。

{keyname:123} 这个难道不是 js 对象吗，一个是对象一个 string

"Javascript 里，可以这样写 {keyname:123}"

没有理解，上文的并不是 JSON ，而是 object 。

JS 也要引号，没有引号，你在中间加个空格试试

@eason1874 空格是特殊情况，这个加引号完全能理解。

日常大部分键名也没有空格，不做兼容，手打很累啊。

上面那个是 JS 的 Object……

"Javascript 里，可以这样写 {keyname:123}"这并不是一个 json ，而是一个 object 。而"{"keyname":123}"这样的 json ，js 也是需要调用函数解析才能成为一个 object

@tool2d #2 为了简明易解析，这样才能轻易地被大多数编程语言接受。

还有哪个复杂一点的数据格式可以放到名片上？

js 的 object 中, 你写的 key 是会被转成 string 的.
就像你输入 1 2 这种数字, 也可以用来做键名(虽然正经人不会写这种玩意, 但真的是符合语法的), 但是它会被隐式转换成 string.

没有引号的话，

{

prettyPrint: 114514

}

里面的 keyname 到底是 "prettyPrint" 呢，还是 "\n\n prettyPrint"

key 可以带其他字符，如空格，-@#%～等

@tool2d #6 我觉得要反过来理解，不是 JSON 多此一举，而是 JS 提供了语法糖，允许你在部分场景省略引号

json 不仅仅是手打，也可能是服务端返回的，根据业务逻辑，key 多种多样

想想不这么写会导致什么后果:

假设 json 为{k1:123, k2:456}，那么请问 k1 的值应该是 123 还是“123, k2:456”？

总不能学 Python 按照缩进来区分层级结构吧，如果真学 Python ，网络传输的时候会花更多的时间去排版而且容易出错，那还不如继续用 xml ，就没必要推广 JSON 了。

要想区分不同的 key 和 value ，最简单的办法就是设立分隔符：双引号到下一个冒号之前为 key ，冒号到下一个逗号或者括号为 value 。（然后 value 带双引号的再转换为 string ）

（只是个人推测，楼主可以去看看 JSON.parse （）的源码实现方式

Objects 章节第一段中: A name is a string
https://www.rfc-editor.org/rfc/rfc7159#section-4

String 章节第一段中: A string begins and ends with quotation marks.
https://www.rfc-editor.org/rfc/rfc7159#section-7

@tool2d js 的 object 跟 JSON 不一样，JSON 相当于字符串了，一个字符串没有经过 parse 也不能当 obj 直接用的。

@eason1874 "不是 JSON 多此一举，而是 JS 提供了语法糖，允许你在部分场景省略引号"

JS 是鸡，JSON 是蛋。

应该是先有 Javascript 语法糖, 后有 JSON 。

设计理念应该是越来越先进才是，没想到会退化。

想做肯定是可以做的，参考 json5 ，key 就没有双引号，
只能说是 json 一开始为了满足 key 是 string ，为了通用，设计出来就是带双引号的，后面不能改了，

按照同样的逻辑，JS 里还可以加注释、还可以单引号、还可以结尾逗号，还可以 nan/inf 等等...
如果你要这些，可以去看看 https://json5.org/

JSON 格式的流行，一大优势就是简单。至于强制引号，是因为 JS 中有大量保留关键字，比如 do ，if 。这样某些情况下必须要有引号，所以作者决定干脆强制引号，这样还更简单。

我在修改机场订阅文件(yaml 格式)的时候遇到个实际的问题

格式大致如下

password: !!str 12345678901234456

其中 !!str 是一个 tag, 表示后面这串字符是一个字符串, 而不是 数字

在我的 clash 如果去除这个 tag 会将那串字符识别为 float 并报错

上面的例子相当于:
password: "12345678901234456"

@icyalala SO 的相关问题，还有原作者回答的视频： https://stackoverflow.com/questions/2067974/in-json-why-is-each-name-quoted

@tool2d #18 json 又不是 Javascript++，哪来什么先进，压根就不是一类东西，
Javascript 是编程语言，变量名不允许特殊符号，
json 的 key 是字符串，允许各种符号，最简单通用安全稳定的表示字符串的做法就是双引号和转义，

@tool2d #18 你搞错了，作为一个为传输编码设计得数据结构来说，写法方便并不重要，都是计算机编码解码的需要啥手写方便，最重要的是需要在任何语言和场景下通用简洁无歧义且尽可能高效，就楼上说的，如果可以省略引号那么处理起来就多狠很多情况需要处理，比如 key 就是引号或者其他特殊字符，作为传输编码的数据结构来说，除了增加编解码复杂度和速度外这样的价值在哪

此外每个语言都有最方便写 map 的数据结构然后转化为 json ，也就是最符合本语言规范的语法糖，JSON 不止是 Javascript 的 JSON ，JSON 能得到如此大范围使用是因为其可以非法方便的用于不同场景不同流程不同语言间传递数据，毕竟只有 Javascript 用着方便毛用没有，而且你确定 Javascript 的这个法糖不是一个坑，只是一开始没设计好然后又不好改所以也就将错就错了

问就是 by design

只能说就是这么设计的

@icyalala 好像 JSON5 完美解决我也提到的这一些痛点。

看来还是有大佬会改革，灭掉引号的。

大哥你在说啥，这明明是 js 的设计问题啊。

谁告诉你字典的 key 只能是 string 了，我 bool ，int 没有面子的么？

@tool2d
js 可以 1 +"1" -> '11'

别的语言就不行, 快来喷其他语言啊

建议你把精力放在更开阔的地方

规定遵守便是，别问为什么

去看了看 JSON5 的 github 主页

github 上的介绍：JSON5 is an extension to the popular JSON file format
重点：is an extension

github 上的介绍：Formally, the JSON5 Data Interchange Format is a superset of JSON
重点：superset

本质上还是 json ，其实这也是个语法糖

比起少写引号我更想加点注释

啊，我每次都是在 json 里像写 js 一样的写，不加双引号，让格式化程序帮我加