PowerJSON - 由 JSON 改进的数据交换格式。

2019-10-15 14:35:13 +08:00
 18510047382

PowerJSON

Powerjson 是由 JSON 改进而成的数据交换格式，它将 JSON 支持了部分 JavaScript 语法，使其更加高效可用，并且解决了许多 JSON 历史遗留下来的问题。

它支持 单引号字符串, 多行字符串, 注释, 运算符, 导入文件, 导入其它 PJSON 文件 等。

Simple Demo

{
    // 字符串
    helloText: 'hello world',
    MultiLineText: `
        Welcome
        to
        PowerJSON!
    `,

    // 文件和导入
    myFile: new File('./file.txt'),
    importPJSONFile: new PJSON('./index2.pjson'),
    getFile: new GET('http://cn.powerjson.org'),

    // 运算符
    tenDaySeconds: 60 * 60 * 24 * 10

    // 这里是注释！
    /* 注释 2 */
}

生态系统

聊天室

为什么不加入我们的在线 PowerJSON CN Gitter 聊天室？

仓库

PowerJSON 在 Github / Gitee / NPM 上托管仓库。

兼容性

PowerJSON 支持所有兼容 ES6 的 浏览器 / js 运行时。

浏览器:

Node.js:

文档

访问 powerjson.org 查看我们的在线实例和 教程！

变更日志

每次发行版的细节和变更记录请访问 Github 上的 发行日志。

协议

MIT

Copyright (c) 2019-present, Yingxuan (Bill) Dong

9171 次点击
所在节点    JavaScript
101 条回复
mcfog
2019-10-15 17:17:38 +08:00
@FrankHB 抱歉基本没看懂你在说啥，如果你觉得 toml 还不够好，可以举一些你觉得比 toml 优秀的方案来让大家学习一下么？
q4336431
2019-10-15 17:19:15 +08:00
为啥不用 yaml 呢
markgor
2019-10-15 17:23:43 +08:00
@18510047382
可能大家遇到的需求並不相同，或者並不在同一個頻道對答。
老實說我關注的只是數據交換這一塊，你可以看回我之前的回復，都是基於這一塊出發的。
另你所說的字符入庫，的確是可以這麼幹，而且這麼幹絕對能把 DBA 干死。
最後，我沒有任何不支持“新”事物的觀點，也知道並非所有新東西一發生周圍市場就能豐富起來。
但我覺得最直觀的就是
1、我為什麼要把 JSON 換成 PJSON ；
2、我換成 PJSON 後我是能縮短或增便了什麼；
3、我把現成項目改用 PJSON 後需要多少時間；

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

你所說的“这里键盘侠太多了，我十分反感这种人”，裡面應該包含我吧。
我不知道是因為我的提問字眼太尖銳了讓你難入耳還是怎樣，
真心希望你能把我回復從頭看一次，我的著重點是“數據交換”，我看完你所有介紹及回復你都沒說到交換時候如何便捷或特點。
337136897
2019-10-15 17:26:14 +08:00
好像很吵。。。
但是好好的 json 被搞得那么复杂。。。也是醉了
duanxianze
2019-10-15 17:44:24 +08:00
虽然很炫酷 但说实话并没有解决痛点，例如注释，运算符本就不该是 json 应该包含的东西，json 是用来传输的，越精简越好
youxiachai
2019-10-15 17:48:46 +08:00
为啥不用 pb.....
pb 现在也可以直接转 json....注释什么的写在 pb 上就好...
还可以多语言协作....
FrankHB
2019-10-15 17:51:39 +08:00
@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 杂交的）。所以你要好的就自己搞自己的生态，要流行就别多想了。
renothing
2019-10-15 17:57:45 +08:00
太鸡肋。。。小的 json 不需要注释，命名就能看出作用。而大的 json 都是靠代码自动生成。。。注释自然到代码里去了。。
whileFalse
2019-10-15 18:09:07 +08:00
其他都还好，扯淡的是那个读文件功能。一个包含文件引用的 PJSON 被传输到别的地方，或者目录变更，或者分发到其他后端实例上时，解析直接报错，那不废了么。

YAML 了解一下吧，支持多行字符串和注释，支持很多高级功能，扩展也容易。
ai277014717
2019-10-15 18:24:48 +08:00
json 的主要问题不是类型和注释吗？搞这么复杂。直接用 js 多好。
hang333
2019-10-15 18:26:10 +08:00
即将引进一堆安全漏洞
locoz
2019-10-15 18:36:21 +08:00
单引号字符串、多行字符串、注释，这几个挺好的，如果喜欢拿 JSON 这种格式的方式写配置文件的话，有这种功能会很舒服（虽然实际上注释能被部分 JSON 解析器自动忽略）。
然后运算符、导入文件、导入其它 PJSON 文件这几个功能...怎么说呢...用途比较小吧？某些场景下确实会很方便，但是毕竟比较冷门，平时这种东西就是增加不稳定性的...
repus911
2019-10-15 18:38:14 +08:00
好样的，我等一个 Go/ruby/python/php...的实现
18510047382
2019-10-15 19:04:53 +08:00
@markgor 不好意思，这里面确实是我的失误，写成了数据交换格式，实际上 pjson 还是更加适合做配置文件的。
下面回答下你的几个问题：
1. 将 json 换成 pjson 可以允许注释、多行字符串等等的存在，让你更方便书写
2. 你换成 pjson 之后，里面的 new file 可以允许你方便地引用其他文件、new import 可以允许你导入其它配置文件，这个作为配置文件应该很好用
3. 将现有项目改成 pjson 几乎不需要时间，pjson 完全支持全部的 json 语法，另外你也可以用 pjson 解释器来解析 json 文件
祝你好运！
18510047382
2019-10-15 19:05:29 +08:00
@duanxianze 嗯，我这个作为配置文件是很好用的
18510047382
2019-10-15 19:06:14 +08:00
@locoz new file，new import 作为配置文件很好用，如果你需要传输的话可以不使用这几个功能，单纯使用字符串、注释即可！
Jirajine
2019-10-15 19:06:22 +08:00
@18510047382 版权问题不太清楚，不过这属于模块的实现吧，很多用 json 作为配置文件的软件是支持注释的，这是否构成侵权？

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

所以还是不建议改名，或者同时也兼容传入.json 文件的解析。
18510047382
2019-10-15 19:06:58 +08:00
@whileFalse 读取文件的功能是作为配置文件使用的 :)
18510047382
2019-10-15 19:09:21 +08:00
@Jirajine 嗯，pjson 解析器一直都是支持解析.json 文件的，同时你的意思应该是说把 powerjson 解析器模块化吧？这个我们在未来会实现的
shunia
2019-10-15 19:10:28 +08:00
js 生态圈里好多 json 都支持注释了，虽然都是 IDE 级别的实现。
另外前端生态圈也慢慢的退出 json 配置优先的情景了，基本都是 js 配置优先。


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


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

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

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

这是一个专为移动设备优化的页面（即为了让你能够在 Google 搜索结果里秒开这个页面），如果你希望参与 V2EX 社区的讨论，你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/609525

V2EX 是创意工作者们的社区，是一个分享自己正在做的有趣事物、交流想法，可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX