如果您一直在 web 开发行业进行编码，那么您很可能非常熟悉 json。这是包罗万象的事实上的标准，从未受到挑战。它无处不在，你已经习惯了。您的所有 rest 调用都通过 json 传输数据。您知道该格式的局限性，并且接受它们。
还是必须这么做？
（注意：所有包和代码的链接都在文章的链接部分）
简史
我的背景是 java 和 javascript/typescript 世界，所以我已经学会了如何处理他们自己的怪癖。许多年前，我开始了一个业余爱好 web 项目（typescript/node），它有一个 json 无法很好解决的问题。
我想摆脱 restful 思维模式，在浏览器和服务器之间实现更轻松、基于消息的传输。为此，我真的很想利用 javascript 类型系统来区分消息。你知道，我们会拥有诸如 adddocument、getusers、givemeallyourmoney 等类。并且我不会拥有许多 http 端点，而是只有一个，并且消息将以更特别的方式从浏览器流向服务器并返回。
但是我并没有真正有一个优雅的解决方案来满足我的需求，因为 json 在序列化过程中会破坏所有类型信息。当然，我可以使用一些专用属性来传输类型，但这需要自定义处理，我只是觉得这不是我想要走的路线。我只是想要一个协议，它可以按原样获取我的对象，并以反序列化时完全相同的方式序列化它。它将保留所有类型信息，仅此而已。所以我需要一个替代方案。
有人可能会说 json 有很多替代品，例如 protocol buffers 或 messagepack。但这些替代方案的本质是它们都是二进制协议。即使当我搜索它们的使用信息时，web 开发也完全不存在。而且我个人觉得没有一个能满足我的要求。
因此，我开始了为自己创建更好的 json 的挑战。
cbot（基于字符的对象传输）协议简介
大约五年前，我通过创建协议的第一个版本开始了这段旅程。那时它还没有名字；我只是将其称为 ejs（增强型 json）。
通过逐步改进，我开发了第二次迭代。现在，有了第三次进化，我将其命名为 cbot，我终于觉得它已经足够成熟，可以介绍给其他可能感兴趣的人。
该协议的主要特点是什么？它们为何如此重要？
正如我之前提到的，该项目的最初火花是在序列化过程中保留类型的能力。但我很快意识到我还可以嵌入更多 json 无法嵌入的信息。
json 有一个坏习惯，就是不保证任何东西。您可以输入任何您喜欢的内容，并且通常必须相信您的 name 属性实际上包含一个字符串而不是布尔值数组。或者您在运行时检查所有内容以确保。当然，有库可以检查模型。但我再次问自己，为什么实际的协议实现不能做到这一点，以便我可以相信反序列化的就是我想要的东西？
此外，json 的原生类型非常有限。例如，json 有一个用于集合的数组。但 javascript 已经有了集合和映射。我也可以添加它们吗？那么日期呢？我曾多次在日期格式上遇到困难。也许您有一个带有时区的约会，也可能没有。它甚至打算拥有一个吗？你永远不会知道，因为 json 并没有真正告诉你任何事情。
所以本质上，我想以某种方式纠正这种缺点。
为什么不是二进制协议？
这是个好问题。第一个原因是，已经存在过多的二进制协议。那么为什么还要创建另一个呢？第二个问题是，如果有更好的替代方案，为什么他们没有在几年前接管 json？一定有充分的理由。
我的猜测很简单，使用 javascript 处理二进制数据并不那么容易。使用字符串更容易。而且 json 很容易被人类理解和查看。当然，浏览器有原生 json 支持。
由于 cbot 的目标是在浏览器环境中工作，因此创建字符协议会更清晰。
它看起来像什么？
本文并不是 cbot 的教程，因为这样的教程已经存在。然而，因为您很可能是一名开发人员/工程师，所以您至少需要对正在发生的事情有某种程度的了解。所以我为此目的制定了一个例子。在示例中，我使用 cbot 作为简单的 json 替代品。使用更高级的功能需要使用元模型，这在实际教程中也有讨论。
但无论如何，这是物体：
{ name: "john smith", age: 41, address: { street: "second avenue", postalcode: "1356-a", city: "yorkistan" }, isniceguy: true, hobbies: [ "playing cards", "shopping", "asking odd questions" ], favouritepoem: { title: "digital dreams", created: new date("2024-09-16t12:13:00"), content: "in the code, we drift and weave,n" + "a dance of data we perceive.n" + "with each keypress, a world unfolds,n" + "infinite stories, yet untold." }}
当该对象转换为 cbot 消息时，它看起来像这样：
112345abbea nameb jkjohn smitha !ageb !id41a "addressb "ea #streetb #jksecond avenuea $postalcodeb $jk1356-aa %cityb %jkyorkistanfa &isniceguyb &ieta 'hobbiesb 'cjkplaying cardsjkshoppingjkasking odd questionsda (favouritepoemb (ea )titleb )jkdigital dreamsa *createdb *ih2024-09-16t12:13:00.000+03:00a +contentb +jloin the code, we drift and weave,oa dance of data we perceive.owith each keypress, a world unfolds,ninfinite stories, yet untold.mff
cbot 格式主要是为了机器可读而设计的。它具有可预测且简单的语法，可以被视为一种小型汇编语言。每个命令都由换行符分隔，每行都以一个操作码开头，解释如何构造对象。
因为这种格式是要以编程方式读取的，所以按原样读取并没有任何意义。但是，它可以以反汇编格式可视化，这可以更好地解释内容：
MCSM 12345abbOBJB (plain) DEFN 0 name ASGV 0 (name) STRN SSTR John Smith DEFN 1 age ASGV 1 (age) NATV FLOAT64 41 DEFN 2 address ASGV 2 (address) OBJB (plain) DEFN 3 street ASGV 3 (street) STRN SSTR Second Avenue DEFN 4 postalCode ASGV 4 (postalCode) STRN SSTR 1356-A DEFN 5 city ASGV 5 (city) STRN SSTR Yorkistan OBJE DEFN 6 isNiceGuy ASGV 6 (isNiceGuy) NATV BOOLEAN TRUE DEFN 7 hobbies ASGV 7 (hobbies) ARRB STRN SSTR Playing cards STRN SSTR Shopping STRN SSTR Asking odd questions ARRE DEFN 8 favouritePoem ASGV 8 (favouritePoem) OBJB (plain) DEFN 9 title ASGV 9 (title) STRN SSTR Digital Dreams DEFN 10 created ASGV 10 (created) NATV ZONED_DATETIME 2024-09-16T12:13:00.000+03:00 DEFN 11 content ASGV 11 (content) STRN STBG STNL In the code, we drift and weave, STNL A dance of data we perceive. STNL With each keypress, a world unfolds, STPA Infinite stories, yet untold. STEN OBJEOBJE
在反汇编中，可以看到一些命令、一些解释和数据。以下是操作码的简要摘要：
mcsm 是一个模型校验和，用于验证消息是否被双方理解。objb / obje 表示对象的开始和结束defn / asgv 对意味着首先将索引分配给属性名称，然后 asgv 使用该索引将值分配给对象。因此，如果消息中再次遇到相同的属性名称，则不必重复。sstr sstr 表示一个简单的普通字符串natv float64 表示 64 位浮点数的本机值natv boolean true，你已经猜到了arrb / arre – 对表示数组的开头和结尾natv zoned_datetime 表示分区日期时间，这是 javascript date 的默认值strn、stbg、stnl、stpa 和 sten 是一组定义字符串生成器的指令。由于字符串可能包含换行符并且它们可以无限长，因此使用字符串构建器模式将字符串拆分为更易于管理的部分。
这是 typescript 独有的东西吗？
不，不是。
由于我的背景和用例，实现自然是从 javascript 端开始的。但由于 cbot 与语言无关，因此它也可以扩展到其他语言。事实上，已经有一个有效的 java 实现，基本上支持该协议能够执行的所有操作。
某处有规范吗？
有点。我发现创建一个合适的规范实际上很难做到。我确实尝试使用某种 ebnf 格式来创建一个，但我的第一个问题是这种格式没有单一的规范（讽刺）。只是对它的一堆解释。另外，即使我使用了其中一个版本，我也没有任何方法来实际验证规范的正确性。
因此，我决定创建一个 typescript 文件，其中包含作为类型和类的验证逻辑。我使用该规范文件来验证我的测试。因此，它成为验证规范。该规范文件是其他实现必须用作事实来源的主规范。
该项目目前的状况如何？
正如我现在所写的，我觉得对于大多数用例来说它的功能基本上是完整的。有一些功能需要更多的研究，例如元模型中的枚举、二进制类型支持和不可空属性支持。
然而，我真正需要的是反馈。我知道对于某些人来说，进行 json 替换完全是无稽之谈，而 typescript 闻起来就像放屁。但是那些真正认为 cbot 可以解决用例的人，我想知道它的表现如何，哪些支持被认为是重要的。
本质上，下一步只是获得一些建设性的反馈，以确保协议能够稳定到第一个实际版本。
链接
联系方式：sisujs@sisujs.figit：https://gitlab.com/sisujs/sisujs/
存储库
npm：https://www.npmjs.com/package/@sisujs/meta-cbotmvn：https://mvnrepository.com/artifact/fi.sisujs/cbot
文档
typescript 教程：https://gitlab.com/sisujs/sisujs/-/blob/main/docs/cbot/tutorial_ts.mdjava 教程：https://gitlab.com/sisujs/sisujs/-/blob/main/docs/cbot/tutorial_java.md类型文档：https://gitlab.com/sisujs/sisujs/-/blob/main/js/meta-cbot/typedoc/readme.mdjavadoc：https://www.javadoc.io/doc/fi.sisujs/cbot/latest/index.html
以上就是摆脱 JSON：Web 开发中数据传输的新方法的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1493186.html
微信扫一扫 
支付宝扫一扫 
