JSON 的 Keyname 到底要不要加双引号？

[3dwelcome]

浏览器里用 eval()解析一个 json 对象，keyname 是可以不带双引号的，比如{a:123}是合法的。

然后同样是浏览器，用 JSON.parse()去解析一个 json 对象，就必须加双引号。否则直接报错！

规范就不能统一一下嘛，一声叹息。

[wdssmq]

@shintendo #18 2333 ，，有趣的灵魂，，

[yolee599]

JSON5 的 key 可以不用双引号

[jifengg]

{
"my name is":"jifengg"
}

想想这个 json 的 key 不加引号怎么写？

[dcsuibian]

OP 和那个后端都应该去补下 JSON 知识了。
1 、JSON 是来自于 JavaScript ，但是作为一种数据交换格式，严格了很多。
2 、C 语言中，双引号代表字符串，单引号代表字符，对其它语言影响很大。js 、python 这种高级语言没有 char 这种单字符类型的，单引号和双引号的效果才差不多。js object 的 keyname 本身也就是字符串，不带引号那是简写，像{"function":"sum"}这种时候就不合适了。所以 JSON 规范规定强制加双引号是个很正确的决定。
3 、后端数据，keyname 不带双引号？你们后端难道是拼接字符串给返回值的？拉出来打一顿
4 、JSON.stringify()和 JSON.parse()都不了解
有点超出我的想象了。。。

[Symo]

@wdssmq 人类阅读友好的应该是 TOML, YAML 的缩进在比较多之后很容易让人迷惑, 比如 k8s 的配置文件.

[wdssmq]

@Symo #24 好吧。。忘记这个了，想了想自己接触到的只有 git 的配置文件用了这种格式，，能自己选的话综合来说还是 yaml ，

data = [ ["delta", "phi"], [3.14] ]
temp_targets = { cpu = 79.5, case = 72.0 }

视觉上个人感觉还是缩进更舒服。。- -

[3dwelcome]

@dcsuibian 没那么多玄学，我只是用错函数了。把 JSON.parse()改成 JSON5.parse()，一切就都没问题了。

JSON.parse()这函数毕竟年代久远，不能苛求太多。

[Puteulanus]

用 eval 解析是真的牛逼。。

[DOLLOR]

考虑要兼容更多的平台环境，最好还是要加。

[dcsuibian]

@3dwelcome JSON5 不是 JSON 的新版本，没有得到官方的支持。实质上是另一个格式。JSON.parse()是浏览器自带的，打开控制台就能直接用，而 JSON5.parse()是第三方类库啊。而 JSON.parse()解析 JSON 没问题，那这个函数就是没问题的呀，也无所谓老不老。

JSON5 作为 JSON 的超集，你用 JSON5.parse()把普通 JSON 转成 JavaScript 值没问题，但除此各方面就感觉挺别扭。因为实际上你是用了一个 XML 和 JSON 之外的特殊传输格式。MIME 类型也应该是`application/json5`。

对应的 JSON5.stringify()的结果很可能无法被正常 JSON 解析器解析，在访问公共 API 的时候会出问题。如果你退化到使用 JSON.strinify()，又有什么理由不使用对应的 JSON.parse()呢

[iyaozhen]

你就不能看看官方文档嘛？
https://www.json.org/json-en.html

[3dwelcome]

@dcsuibian 前端 JSX 代码大多都是转译的，用个第三方库来扩展 JS 或者 JSON 能力，是很普遍的事情。

我一直觉得 tailwind css 最大的成功之处，就是语法没那么死板。用缩写 mx-5 来替代 margin-left 和 margin-right ，能少打很多代码，让程序可读性提高，变得清晰整洁。

我最好连 html/xml 都能把引号给去掉，比如<button id=great_button onclick=alert(很好很强大)>显示按钮</button>

[3dwelcome]

@iyaozhen 前端技术日新月异，json.org 上规范是 200x 年设立的，看 10 几年前的文档，显然没有足够的参考价值。

有扩展新的规范，比如 google 的 jsonnet ，都是可以直接写无引号的。

说说嘛前端需要不断创新，结果还是要拿十几年的老古董文件来压人。

[marcong95]

@3dwelcome #32 想要简化 html 的话，pug 了解一下。

我觉得你认为不加引号也应该是 JSON ，目测是看到 JSON 全称是 JavaScript Object Notation ，然而事实上 JSON 似乎已经成为了一个专有名词，只是因为源于 JS ，才叫的 JSON 。JavaScript Object Notation 跟 JavaScript Object 的区别就如同 Java 与 JavaScript 的区别一样大（优良传统了属于是

[icyalala]

@3dwelcome JSON 标准体现在它能脱离 JS ，在所有地方都能作为 "数据交换" 使用。
很多语言内置或流行三方库都支持 JSON 到原生 Object 的映射，各个数据库也都支持 JSON 导入导出或者 JSON 查询和 Patch ，甚至现在很多文件格式都直接基于 JSON 来定义。所有这些地方都是遵守那个 JSON 的标准。如果不遵守标准，那就不叫 JSON 了，这与创新无关。

另外，JSON 标准也在一直更新，最新的标准是 2017 年的 RFC 8259 ，但没有破坏标准兼容性。

[3dwelcome]

@icyalala 我个人觉得由于历史负担太重，JSON 标准官方就算想更新，也没办法更新。

有那么多的老的 json 解析库，是不可能所有都更新的。

[shintendo]

@3dwelcome
恰恰相反，JSON 不更新版本是最正确的决定，作为一个数据交换格式，你今天拿到前端发来的请求不需要问他这是 JSON 2.6 还是 JSON 5.8 还是 JSON X 写的，都要谢谢 DC 的这个决定。
你在主贴说着“规范就不能统一一下嘛，一声叹息”，别人告诉你 JSON 规范一直都是明确统一的，你又开始要创新要扩展要日新月异，全保定的理都让你占了。
至于什么 JSX tailwind ，属于是越说槽点越多了，建议及时止损。

[Nooooobycat]

先是分不清[]和{}，再然后是 OP 提到的后端疑似是拼接字符串返回 json 。。。现在程序员的水平可以这么低了吗

[keepeye]

你调用一下 JSON.stringfy() 观察一下不就知道了吗？你猜一下，不带引号的"json"能不能被其他语言解析

[dcsuibian]

@3dwelcome
我的意思是，这东西扩展了，那它就不是正宗 JSON 了，更准确地说，就不是 JSON 了。
tsconfig.json 用.json 作后缀，但能写注释和逗号，不是正宗的 JSON 。
就像 jsx 能用.js 后缀，但已经不是正宗的 js 了。

而相比于 jsx 这种，我认为使用 JSON 时更应该遵守标准，因为它作为一种独立于编程语言的格式。不是某个项目(tsconfig.json)、某个语言(js)特有的。JSON 标准的确定性是不可少的一个优点。大家只要明白是 JSON 就能处理，没那么多麻烦事，甚至不用说版本。

而且 JSON 其实是非常优秀、先进的格式，现在还是相当好用的。新的格式没有比它好多少，没有什么替换的必要。
主要问题就是有些人喜欢把它当配置文件用。（这点应该让 yaml 、toml 来说话）