数据交换不仅仅要考虑 JS，没有其他语言很难用上，而且你这种语法在很多语言里根本无法实现

@blanu 为什么语法在别的语言就无法实现？请你详细说说

@18510047382 人家的意思应该是没有看起来那么好吧？

@Hanggi 我其实感觉这里面的语法都是通用的，注释、new、字符串等等等在许多语言的书写方式都是一样的

JSON 支持文件导入有什么鬼用？你给大家解释一下

看了下楼主的发帖纪录…造轮爱好者啊…

我再 chrome 的 console 了下：
console.log({
// cmd 123123
helloText:'abcdefg',
mlText:"asdf\nasdf",
/*testtest*/
abc:123,
tst:1*2*3*4
});

返回：
abc: 123
helloText: "abcdefg"
mlText: "asdfasdf"
tst: 24
__proto__: Object


什需要用 PJSON ?

我直接用 JSON 他不香哦
----------------------------------
然後看到你的交，
也看了你的文和明，
但未找到具怎。
所以想你交的候他是怎交？




另外，最的一，

在 JS ，我 var a={xxx:123}就是 JSON 象了，直接 ajax 就提交去後端了，
在 php 我使用 json_encode(array);就能出 JSON 象，JS 直接就能使用了，
在 C#我引用 fastJson 就可以了。

如果替成 PJSON，我而言是化了哪呢？

@telung 实现模块化

术业有专攻，json 就是用来存储数据的，何必多此一举在里面搞编程语言支持呢？

json 不就为了简单吗？搞这么复杂。。。

@markgor 首先 JSON 是不支持 comment、运算符等等的，你所使用的是 Javascript 对象，并不是严格的 JSON，推荐你看看 json.org 的一些规范，如果你用你把你刚才 object 转换成字符串，再用 JSON.parse 解析会解析不了的。
JSON.parse(`
{
// cmd 123123
helloText:'abcdefg',
mlText:"asdf\nasdf",
/*testtest*/
abc:123,
tst:1*2*3*4
}
`)
直接报错：VM75:3 Uncaught SyntaxError: Unexpected token / in JSON at position 3
at JSON.parse (<anonymous>)
at <anonymous>:1:6

另外你说的 ajax 提交是不能直接提交 Javascript Object 的，他需要使用 JSON.stringify 转换成字符串才能通过 GET、POST 请求发送，而你刚才的那些代码是没办法转换成 json 字符串的

@dyllen 推荐你先掌握一下注释等等的重要性，这对个人来说不写注释可能没什么，但是对团队来说注释是非常重要的，而 json 不支持注释等等内容，对团队协作是非常不方便的

@hiluxi 推荐你也先掌握一下注释等等对团队协作的重要性

没有 get 到痛点，所以也无法知道是否变得更好用了。

挺好的，支持这种创新，虽然不一定有卵用。

@angusun json 还有什么另外的痛点吗？除了 PSON 改进的这些内容

JSON 是不支持 comment、运算符等等的，你所使用的是 Javascript 对象
如果你用你把你刚才 object 转换成字符串，再用 JSON.parse 解析会解析不了的。
PJSON 是不是也是 JS 象？
PJSON.parse(PJSON.stringify({
/*asdfasdf*/

a:1
}));

果是什？


另外你说的 ajax 提交是不能直接提交 Javascript Object 的，他需要使用 JSON.stringify 转换成字符串才能通过 GET、POST 请求发送，而你刚才的那些代码是没办法转换成 json 字符串的

var a = {
// cmd 123123
helloText:'abcdefg',
mlText:"asdf\nasdf",
/*testtest*/
abc:123,
tst:1*2*3*4
};
var b= JSON.parse(a);

ajax 提交 b 可以了吧？
但是 PJSON 是可以化哪一步呢？

有各言 JSON 的支持和支持你也可以上 json.org 看看。
如果成 PJSON,支持是有...？


最後一，
文中 PJSON 最害是加入了算支持，
可以把 JS 的算精度修下？

PJSON.stringify({a:0.1+0.1+0.1});
"{"a":0.30000000000000004}"

@markgor pjson 简化的是 parse 的步骤，是通过字符串解析成对象的步骤，而你说的都是 stringify 的东西，这些东西并没有必要简化啊。

另外推荐你先学好基础，你的：

var a = {
// cmd 123123
helloText:'abcdefg',
mlText:"asdf\nasdf",
/*testtest*/
abc:123,
tst:1*2*3*4
};
var b= JSON.parse(a);

执行之后报错：

VM199:1 Uncaught SyntaxError: Unexpected token o in JSON at position 1
at JSON.parse (<anonymous>)
at <anonymous>:9:13

应该是 var b = JSON. stringify(a)

@blackcurrant 试试就知道了嘛

@18510047382 简化的是 parse 的步骤，parse 哪化了，
另外可以不要避重就，回答下。

看完你的文和你所的西，
我是真的不知道究竟能我少什工作？
或者是不知道哪地方可以使用它？
你可以考上面人的回，
你可以明的出使用上它，在哪些地方是方便了？或者例也好啊

等等，大家的 JSON 都不是机器生成的么？
为啥我都是 obj to json_str // json_str to obj

@markgor PJSON 解析器是基于 Javascript 的，该如何修复 js 的计算精度呢？

@18510047382 那为啥需要注释？
难道 JSON 需要自己手动写？
注释不应该用在生成 obj 的代码里面吗？

@18510047382
引用自百度出的：
们要把需要计算的数字乘以 10 的 n 次幂，换算成计算机能够精确识别的整数，然后再除以 10 的 n 次幂，大部分编程语言都是这样处理精度差异的，我们就借用过来处理一下 JS 中的浮点数精度误差。

@markgor json 的 parse 加不了 comment、operator、file data 等等，所以这就是 pjson 的特殊之处。
另外 pjson 的用处主要就是在 node.js 方面的，browser 如果你需要解析 jsonstr 可以使用 pjson。

@imdong 我不知道你究竟见过 .json 文件没有，当 json 作为配置文件来使用的时候，你怎么通过 Javascript 生成呢？

@markgor 你说的精度处理也不错，之后考虑加入一下

@imdong Node.js 的配置文件是手的。

@18510047382
真的，我大家看完一大堆西，
都不知道究竟用替成 JSON 後能或助到我什西，
我得你比好。

另外我不知道人什用 JSON，
我知道的就是我自己什用 JSON。

就如上面所，
因 PHP 直接用 JSON_ENCODE(array|object)它就返回了 JSON
JS 只要是 ajax 置了 JSON 型就自解析出 JS 象。
成.NET,JAVA 也是如此，只是它需要加第三方包。
然後中的象就像你所的，它於 string 型。那 PJSON 候是否也是 STRING 型呢？

作为“交换格式”可能不容易普及，作为预处理器可能有用

这轮子不香，下一个。

数据和代码耦合，很容易出现安全漏洞

导入文件啥的真没有必要，而且这种其它语言也不好支持

你可以参考 Node 社区常用的做法，比如需要导入文件 /计算之类的场合可以写成.js 模块，并导出一个最终 JSON，不比你这种做法妥当且灵活得多啊

去掉了导入的话和常用的 json5 之类的就没区别了，所以这个轮子真没必要

起码楼上说的有一个问题需要解决：各种常用语言的支持库。

json 本身不是为了压缩或者序列化对象使用的么。。这么搞把它反而复杂化了。。况且除了感觉对于前端有用，后端就太鸡肋了，也不知道有没有 XSS 的风险

配置文件，Node 系直接用 .js ，其他系用 YAML。

数据交换（ API ），根本不需要这么复杂的功能。

结论：毫无意义。

new 可以去掉吧，感觉多余。
二进制数据支持么？

试试 jsonnet 呗
http://www.lihaoyi.com/post/BuildyourownProgrammingLanguagewithScala.html 这里还有个简单的 scala 怎么实现教程

额..一时语塞不知道怎么说
请问您的 powerJson 目前支持哪些语言呢？如果只支持 js 的话，我为什么不用.js 呢

@love json5 是 es5 的 json，而 powerjson 有部分 es6 的语法，包括多行字符串等等，更主要的是维护的都是中国人，中文随时可以提 issue，另外这个导入文件的功能把他变成一个模块我觉得挺不错的，之后看看能不能实现 :)

@markgor 我现在都不知道你到底在问什么，pjson 解析器能把 pjson 的特殊语法转换成纯 js 对象，pjson 主要就是针对配置文件使用的，pjson 就是给.json 文件提供一些例如注释之类的功能。pjson 文件传输的时候只需要传输 pjson 字符串就行了啊，然后你在接收端使用 pjson.parse 解析，这也有问题？另外我觉得我已经和你说的够多了，再有问题我也不会回复了。

@czjxy881 这个都是我们自己写的解析器，并没有 eval 或 new function 之类的东西，安全性应该还是有保障的，不过现在还是 alpha 版本，不推荐生产环境使用

@Jirajine 这个之后也会解决的，我们会慢慢实现

@zhybb2010 json 是传输数据使用的，如果你喜欢简单的 json 也是可以的，powerjson 就是在 json 的语法基础上扩展的，所以并不代表你必须要使用 powerjson 语法。

@cheneydog new 的话是为了更符合 js 语法。另外二进制目前还不支持，之后考虑添加

@ipwx 我不知道你在哪里得出来的这个结论，你说的“数据交换（ API ），根本不需要这么复杂的功能”可以解释一下为什么不需要吗？

@zhuangzhuang1988 感谢你的 scala 教程，另外 jsonnet 是一个 json 模板引擎，并不是编程语言啊

@pkoukk 现在因为还是 alpha 版本，所以只支持 js，不过之后会支持更多的语言

数据交换和配置管理是非常不一样的两类需求，数据交换优先的是机器可读和性能，可选的是人类可读，没用的是容易编写，因为数据交换的主要场景是从内存 serialize 而不是手写。而配置管理重要的易编写和人类可读，机器可读其次，性能基本没用除非烂到不可理喻。

你说了是数据交换格式，然而你的 feature list 里面大于 json5 的部分基本都和数据交换无关，而是配置管理的需求，这些需求对于数据交换来说都是无用的复杂性而已（ client 发了个 pjson 给 server，结果 server 还要再请求远程文件才能获取完整结构？安全性和性能都完蛋，更别说 include 本地其他文件了）

看你一直在说注释重要和手写配置，那么反过来说如果你的项目目的是配置管理，那 json 就根本不是一个好的（不如说是最糟糕的）学习对象，建议看（学）看（习） toml 这种更现代的配置语言

还有，我讨厌这种回复每楼说你不懂其实我的东西很牛逼的楼主，如果楼主你回复我请做好被无视的心理准备

@18510047382 恩，处理库，ide 的高亮语法检查格式化插件等有了之后换过来用还是不错的，既然完全兼容 json，并解决了配置文件注释这样的痛点，不妨不要改扩展名，直接用 json 好了。

可以用 base64 加入二进制文件支持？

还有我也支持把 new 去掉，键值对的关系这样搞得莫名其妙。

@mcfog 是的，这里手误写成了数据交换格式，实际上是数据格式，不好意思。（另外我也不是这种 “回复每楼说你不懂其实我的东西很牛逼” 的人，只是这里键盘侠太多了，我十分反感这种人，但是你正常提意见还是没有问题的）

@Jirajine 嗯嗯，json 这名字人家是有版权的，咱就别用了。另外二进制功能我们慢慢实现，new 的话到时候发布正式版了再去解决。

这种只能用来单向传输的（并且只能传给支持 js 的环境），欢迎使用 eval 大法，抛开安全性，不仅支持注释，不仅支持运算，还支持传输函数哟，甚至直接调用函数的函数的函数的运算，说白了上就等同于一个 js 文件，另外用函数包裹一下用来支持序列化；浏览器支持：IE6+

觉得蛮好玩，就手撸了一段 js 代码，就是不知道有没有什么实用价值



附无格式可 copy 代码：
Serialize：
``` Javascript
data=function(){
return {a:/abc//*正则*/,b:Math.pow(2,8)/*指数运算*/,c:[4,5,6]}
};
/*stringify*/(data).toString()
```
Deserialize:
``` Javascript
data="function(){\nreturn {a:/abc//*正则*/,b:Math.pow(2,8)/*指数运算*/,c:[4,5,6]}\n}";
/*parse*/eval("EvalTemp=("+data+");EvalTemp");
```

@18510047382
我现在都不知道你到底在问什么，pjson 解析器能把 pjson 的特殊语法转换成纯 js 对象，pjson 主要就是针对配置文件使用的，pjson 就是给.json 文件提供一些例如注释之类的功能。pjson 文件传输的时候只需要传输 pjson 字符串就行了啊，然后你在接收端使用 pjson.parse 解析，这也有问题？另外我觉得我已经和你说的够多了，再有问题我也不会回复了。

你是得交就是用 NODE.JS 取配置？
你我不懂你前端的思。
源要是手死，要是取值，
排除手死的，哪支持 PJSON 格式？是需要成 JSON 入？
的：
後端->前端
使用 JSON 前：
把後端的象或成 JSON 前端，前端直接解析就成了前端的象 /。大家方便。

成 PJSON 後：
後端：到找言的解析，有，然後口中念念叨叨地不知道著什模仿著 JS 源理。
前端：找到了，在每使用的地方加下再使用再解析回的 JS。
：看著中的注和未算的固定字公式陷入了沉思，奈地看下控中的 Netflow 和示器下面放著的使用情，不禁地思考起，前端的子永都是那，且鼓。

最後，回不回是您的利，不看了下你 github 上的所有子，面 issue 都是空白的，不回我您不得空聊冷？

@xiangyuecn Eval 安全性不高，另外我们未来还会开发 Java、Python 等其他版本的编译器

@markgor 你怎么样认为随你好吧？你见过新东西一发生态就这么丰富的？

@markgor 算了，我好好地和你说吧：
1. PJSON 入库可以直接当做字符串入库
2. 后端语言的 Node.js 已经有对应的 PJSON 解析器了，Java、Python 等等的其他语言我们现在也正在开发。
另外如果你觉得我们做的不好，那你至少给出点建议吧。

我还以为那个男人换了个马甲回来了

注释和运算符功能有些用处，其他功能比较特殊，使用频次不高，应该不常用；其实注释功能在当前的 json 上，也可以用另一种机智的方式实现，就是加一组用于注释的 key: value = =

@mcfog 关于你所谓的对数据交换的主要场景的理解，基本是不靠谱的。
任何足够成功的二进制中立的语言中间表示，特别是捆绑了标准内部和外部表示的方案，都算是你的理解的反例，如 LLVM IR 和 FASL(Lispwork's Fast Load format) 。而没有标准内部表示但比较容易实现的更通用的格式，如 XML 和 S-expression，也可以构成反例。
从实现功能上来讲，serialize 比起 marshall 来讲基本是伪需求。造成 serialize 算是个事儿的历史原因主要是，使用 ALGOL-like 这样的传统命令式语言的用户很少能想清楚先天就能 serialize 的格式该怎么设计，历史上一路上都在从实现开始试错而不会去先排除根本困难，所以传统上才会过分强调这个问题；然而对成熟的、一开始搞清楚什么应该是从被交换的数据里剔除出去的方案，这里根本就不应该有什么原则难度。Marshall 才真正涉及一些和结构以及具体目标语言的语义相关的麻烦事。
配置管理跟数据交换来讲，与其说是非常不一样，不如说是根本不算是应该在一个层次上实现支持的功能。配置管理是更高层的应用。（和数据交换同级别的应用是直接的可编程性，但这在非同像性的(homoiconic) 语言的时候基本没什么意义。）配置管理的基本表达就是可编程的数据，它也可以被交换；反过来可交换的数据就不一定需要能被可交换的外部格式表达。所以这个问题的结论上我倒是没什么根本不同的意见LZ 的设计基本意义上不大。
不过 TOML 这类 DSL 还是算了吧，随便都能糊，没人用就没人权。

@lcvs 对，但是这种 key: value 形式的注释容易让人当成字段解析

楼主造轮子精神我很佩服,但很明显是不会成为数据传输规范的,也不会有太多人认可

@iRiven #51 json pstd

搞这么复杂，我为啥不用 XML ？为了解决 XML 的复杂性，搞出的 JSON，然后一个轮回又回去了？？

个人感觉语法可以和 sql 结合一下，楼上有人说的很对，大部分数据都是查数据库，如果 json 有数据查询和数据校验功能，肯定强很多。

@danielmiao pjson 只是提供更多选择，你并非必须使用 pjson 提供的语法

@3dwelcome 可以的，未来可以支持一下 SQL :)

@FrankHB 抱歉基本没看懂你在说啥，如果你觉得 toml 还不够好，可以举一些你觉得比 toml 优秀的方案来让大家学习一下么？

为啥不用 yaml 呢

@18510047382
可能大家遇到的需求不相同，或者不在同一道答。
老我注的只是交一，你可以看回我之前的回，都是基於一出的。
另你所的字符入，的是可以，而且能把 DBA 干死。
最後，我有任何不支持“新”事物的，也知道非所有新西一生周市就能富起。
但我得最直的就是
1、我什要把 JSON 成 PJSON ；
2、我成 PJSON 後我是能短或增便了什；
3、我把成目改用 PJSON 後需要多少；

我不是和你缸，看了你回人的信息也大概清楚。（#44 手误写成了数据交换格式，实际上是数据格式，不好意思。（另外我也不是这种 “回复每楼说你不懂其实我的东西很牛逼” 的人，只是这里键盘侠太多了，我十分反感这种人，但是你正常提意见还是没有问题的））

你所的“这里键盘侠太多了，我十分反感这种人”，面包含我吧。
我不知道是因我的提字眼太尖了你入耳是怎，
真心希望你能把我回看一次，我的著重是“交”，我看完你所有介及回你都到交候如何便捷或特。

好像很吵。。。
但是好好的 json 被搞得那么复杂。。。也是醉了

虽然很炫酷 但说实话并没有解决痛点，例如注释，运算符本就不该是 json 应该包含的东西，json 是用来传输的，越精简越好

为啥不用 pb.....
pb 现在也可以直接转 json....注释什么的写在 pb 上就好...
还可以多语言协作....

@mcfog 你所谓好不好，是看应用场景而定的。这本身没什么问题：大部分人用某个语言解决配置问题，就只是把配置当 DSL 的代码来用。这种情况的前提是，别人替你把资源准备好了，告诉你足够靠谱，只管用就行。
但是要考虑更一般的情形就不是这么一回事了。没什么 DSL 能 hold 住各种不同的需求，整体上要造不同 DSL 的轮子方案数量都会爆炸。还可能有一坨方案的实现都根本不值得信任，搞不好需要自己实现整个“生态”的时候。最极端的情况下，编程语言我都需要自己造轮子，一个只能用于配置的 DSL ？写 spec 和实现都就是增加工作量。
考虑一下 JSON 的流行，本身就有这个背景。Javascript 的设计是否干净得配得上被当成一个通用程序语言不说，好歹很多人就是拿它当通用语言来用的。JSON 作为 Javascript 的缩水版，并不需要很多单独的设计，只要附加一些约定一个 spec 就出来了。这里 Javascript + JSON 就显然比 Javascript + TOML 或者其它什么别的省事。考虑实现，Javascript 和 JSON 本身语法非常接近，所以很多设施都能够方便地复用。这进一步形成正反馈，让用户有很多途径找到可用的使用的 JSON 的解决方案。这里，有个足够流行的爹（ Javascript ）就是 JSON 先天强势的主要理由，并不需要 JSON 自己的设计就有多“好”。（当然，JSON 的设计如果烂到让人受不了那肯定也是会在流行上减分的，但至少现在没到这个地步。）
相比之下，TOML 并没那么个好爹。TOML 本身的设计，溯源起来基本也就反映了 .INI ，并没什么很抓人眼球的创新。容易手写和不太难阅读是它的优势，但也仅止于此，能达到这个水平的其它的备胎多得是。要说包装结构化数据使其便于被可编程地处理，连 JSON 其实都打不过，所以它也就只能作为配置 DSL 来生存。TOML 的流行（如果算流行的话）主要是近些年 Cargo 之类的项目实际被广泛使用也并不是因为它的设计有先进，只是恰好在这类项目中被人认为足够合适而已这至少需要偶然到接触到它的人找不到其它更好的方案（挺难的）。尽管如此，仅在手写配置这个领域中想跟 JSON 竞争流行性，仍然是想多了。（手写 JSON 起码还没像 XML 那么容易烦躁到忍不了。）
考虑到 DSL 脱离具体领域无法互相比较，真正凭自己的设计算得上“好”的格式就不可能只能当 DSL。这部分其实 JSON 也不太够格，因为它的爹仍然有很大的领域局限性，脱离群众基础没什么现成的解决方案想自己从头造，一样分分钟缩卵。考虑通用性，这里有候选资格的大概只有 XML 和 S-expression，两者至少技术上都足够作为一系列通用编程语言的语法基础，也有不止一个例子。不过前者的祖辈(SGML) 历史包袱实在太混乱了，也没发展出个能把事情做干净的直系长辈和儿子（基于 XML 的编程语言实用上几乎全止步于 DSL ）；后者的历史太乱，到处是精神祖宗和孙子，然而就没什么直接标准化成功的方案（最像样的可能还是跟 XML 杂交的）。所以你要好的就自己搞自己的生态，要流行就别多想了。

太鸡肋。。。小的 json 不需要注释，命名就能看出作用。而大的 json 都是靠代码自动生成。。。注释自然到代码里去了。。

json 的主要问题不是类型和注释吗？搞这么复杂。直接用 js 多好。

即将引进一堆安全漏洞

单引号字符串、多行字符串、注释，这几个挺好的，如果喜欢拿 JSON 这种格式的方式写配置文件的话，有这种功能会很舒服（虽然实际上注释能被部分 JSON 解析器自动忽略）。
然后运算符、导入文件、导入其它 PJSON 文件这几个功能...怎么说呢...用途比较小吧？某些场景下确实会很方便，但是毕竟比较冷门，平时这种东西就是增加不稳定性的...

好样的，我等一个 Go/ruby/python/php...的实现

@markgor 不好意思，这里面确实是我的失误，写成了数据交换格式，实际上 pjson 还是更加适合做配置文件的。
下面回答下你的几个问题：
1. 将 json 换成 pjson 可以允许注释、多行字符串等等的存在，让你更方便书写
2. 你换成 pjson 之后，里面的 new file 可以允许你方便地引用其他文件、new import 可以允许你导入其它配置文件，这个作为配置文件应该很好用
3. 将现有项目改成 pjson 几乎不需要时间，pjson 完全支持全部的 json 语法，另外你也可以用 pjson 解释器来解析 json 文件
祝你好运！

@duanxianze 嗯，我这个作为配置文件是很好用的

@locoz new file，new import 作为配置文件很好用，如果你需要传输的话可以不使用这几个功能，单纯使用字符串、注释即可！

@18510047382 版权问题不太清楚，不过这属于模块的实现吧，很多用 json 作为配置文件的软件是支持注释的，这是否构成侵权？

我的意思是作为原 json 的超集完全向下兼容，将 json 模块换成你的以后觉得不好的不需要的特性完全可以不用，而你这些增强主要是解决配置文件的痛点，我知道 json 当配置文件不是最好，但确实很广泛。

所以还是不建议改名，或者同时也兼容传入.json 文件的解析。

@whileFalse 读取文件的功能是作为配置文件使用的 :)

@Jirajine 嗯，pjson 解析器一直都是支持解析.json 文件的，同时你的意思应该是说把 powerjson 解析器模块化吧？这个我们在未来会实现的

js 生态圈里好多 json 都支持注释了，虽然都是 IDE 级别的实现。
另外前端生态圈也慢慢的退出 json 配置优先的情景了，基本都是 js 配置优先。


我觉得做中间件还稍微有点意义-提供成一个解析 pjson 格式的中间件，作为一个 bridge 用。


手写的话，我永远也不会选择这么复杂的 json 语法的，我用 js 它不香吗？。。。

如果非要是配置文件，yaml 之类的它不香吗？。。。

如果数据传输，额外增加了传输的数据量吧，而且还要在前后端各增加一个库，有点多余的其实。

JSON5 呢

@18510047382 应该说是作为各语言标准 json 模块的增强的替代品，传到 pypi，npm 等官方源上，并且实现的时候尽量兼容原 json 库的调用方式，方法命名，参数等。

@Jirajine 对，主要还是看中了 json 的格式

无论好与坏，如果没有单元测试的话，没人敢用。

这也 80 多个回复了，为什么没人 star 呢，开发者你想过没有

关键是推动各个语言去支持吧

数据格式交换，想弹性我就 选择 xml 了，况且现在 grpc 等 rpc 框架一大把 都已经对交换数据做了处理

没用

为了造轮子而造轮子

反正我是不愿意把汤勺用锤子锤扁成锅铲来炒菜，这样煮的饭会更香吗？

xml + xslt 不好用么...

这样很不安全吧。访问任意文件，对任意网站发请求？挖洞人应该非常喜欢这个的（

json5 的概念扩充化，如楼上所言，存在安全问题的。

使用场景在哪里?
作为数据传输的话，噪音太多。

我看到了 注释这个用处。 但是问题在于生态， 什么时候各种语言的标准库支持了就算是成了。

这个得有个有权势的机构推动才行

张口就来的标准 不发表评论

我想到了 https://msgpack.org/
It's like JSON. but fast and small.

看了下 用来写配置的话还是可以的

处理的某个需要特殊处理的字段，比如引入 json/4+3 计算，那就特殊处理呗，为啥还加个依赖
单引号就是找麻烦，标准就是标准，都去执行就行了，偏要加个单引号，没事找事么
想法不错

楼主这个轮子看起来更像是对标 yml 这类，而不是 json。在用于数据交换的这一点上，轻量和简洁我觉得更为重要，楼主的这个不太符合。