只用 linux

同样关注

因为平时已经被 wx 一直强奸，所以非常反感，能不用就不用。

更正：但是不是使用串口信号线

看数据速度
速度不快用普通 usb 转 串口 就可以
但是必是使用串口信号线
而是使用 CTS RTS 之类的线做 IO

我在那个帖子说的是主要指令集操作的位数来算的

不过一般看一个指针所占空间也是没问题的

linux 发行版的尽头是 gentoo
特别是当有需要编译源码的需求

@OrdinaryMan

如果 CPU 是 8 位的，那么数据通道固定是 8 根线没错

但如果 CPU 是 32 位的，那么数据通道固定是 32 根线，也就是同时可读写 4 个字节
如果您只想读其中一个字节，我上面说了，要通过类似 byteenable 这样的 mask 信号，自己选择要读写哪个字节
此时，32 根线（或者说 4 个字节），只有其中选中的字节会参与读写，没选中的字节（或位）被忽略掉而已

@OrdinaryMan #25 没问题

主要和 CPU 内部总线有关

内部总线又和 CPU 架构有关

CPU 所使用的指令集，如果默认支持的是 32 位操作，譬如 ADD 加法指令（操作的寄存器也是 32 位），那么 CPU 就是 32 位

类似的，现在还在市面上的 CPU 可以是 8 位 16 位 32 位 64 位

既然 32 位 CPU 一个指令可以操作 32 位，那么内存默认也就按照 32 位加载数据了，这样最方便
（如果加载的数据不是 32 位对齐的，低端 CPU 会直接异常出错，譬如 cortex-m0+，高端一点的 cpu 则会分两次加载，叫做支持非对齐访问）

如果想看细节，可以看我这个 CPU 外设的接口：

https://github.com/dukelec/cdbus#interface

这个是 8 位的接口，数据块大小是 256 字节，所以 地址线是 [4:0] 共 5 根线，数据则是 8 根线，对应一个字节

而这个外设也有 32 位的接口的版本：

https://github.com/dukelec/cdbus/tree/32-bit#interface

32 位的版本，可以直接访问多个连续的数据块，所以地址线没变少，要留意的是 _mm_byteenable 信号，当需要读写 32 位其中的部分的时候，通过 byteenable 选中要操作的字节，至于是否支持非对齐访问，那是上面总线的事

@icyalala 辛苦了

我不觉得 json 的人类可读可写能算多大的优点
举例：doc 文档的裸数据不需要人类可读可写，但依然可以很方便的人工读写

设计产品架构的时候，以 msgpack 为主，可以不受 json 不能传输二进制的限制，可以设计出更简洁的 api 接口

如果是 json ，要传二进制，要纠结用 base64 还是 单独开一个 api ，单独开 api 的话用户验证又要单独搞一套机制，url 也要搞老长一串

而且要先上传文件，再在 json 里面填文件 url 地址，对方收到 json 之后，又要单独下载这些文件，很多时候都是些不大不小的文件

我 2018 年入的海神 ocw-s3400
过了 5 年多，更新的一样，从来不用充电，也不用对时间，一秒不差的感觉真好

既然选择了 rust ，就不要怕麻烦

@icyalala
跟你说 simd 是因为你在意这个
你可以试试 simdjson 和 msgpack ，看看到底哪个性能更好，用数据说话
对 msgpack 来说，我根本就不认为是个事，你非要拿 msgpack 不需要的东西来説事

如果是我提供服务，我会以 msgpack 为主做架构设计，单独外挂 json 给喜欢用 json 的人

至于生态，用 msgpack 是缺少什么了吗？你倒是说说呀

至于其它通讯格式，我当然知道它们的存在，我也知道它们是怎么死的，我一开始就不看好它们，无论是 xml 还是 protobuf

选择 msgpack 是因为它拥有 json 的绝大部份优点，保持简洁的同时，扩展性比 json 好很多，而且很类似，平替很方便

2023 年了，支持 ipv6 吗？

@icyalala
那是因为 msgpack 反序例化根本就不需要先整体解析 utf8 字串，因为 msgpack 本身就不是字符串格式

其中包含的一些字符串格式的内容，使用各环境自带的 utf8 编解码工具即可，譬如浏览器你怎么用 simdjson ？

至于你原本需要用 simdjson 的环境，你如果不满意现有 msgpack 库的 string 数据的转码速度，你直接把 utf8 转码函数替换一下就行了，搜 utf8 simd 库即可，会找到更多比 simdjson 更好的库，因为 utf8 的使用面可比 json 大多了，各环境的 utf8 编解码应该都已经用的就是 simd 加速过了的。


使用 msgpack 最大的好处是简单、扩展性好、通用性好，譬如要搞一个上传 图片 的 API ，和其它 API 一起共用一个 url 就行，而且除了 get/post 接口，还可以用于 websocket：

{ "user": "xxxxx", "auth": "tmp_password", "cmd": "upload_img", "image": 图片数据 }


我不是让后端费力开发一个小众接口，而是产品一开始就要选择简单、扩展性好、通用性好的 msgpack 。

至于它是否小众，你可以看一下其他坛友的回覆，很多大厂到在用。

互联网前后端不是最喜欢造轮子、脚手架和追新的吗？怎么到 msgpack 这样真正有意义的东西上，就各种排斥了呢？

当然如何选择是你的事，反正有人喜欢堆屎山也不会影响到我。

协议虽有很多，但 msgpack 是最简单、最接近 json 的格式，对开发者来説，换一下 序列化 和 反序列化 两个函数名就行了

@icyalala 不，我説了 msgpack 可以简化接口，因为可以传二进制，同一种 api 就可以传输图片文件

同时支持的时候，如果客户选择使用 json ，那么就只能麻烦一些用单独的文件上传下载 api ，由客户自行选择，服务器架构不用往 json 靠

对于文本解析，再怎么加速都没 msgpack 这样的二进制格式效率高

而且，现在很多嵌入式设备，mcu 解析 json 更是亦常的麻烦，譬如在没有 malloc 可用的环境，而此时 msgpack 解析则轻松省事

（对于 ram 很小的 mcu ，需要无损压缩数据的话，压缩格式我会选择 lz4 ，而不选 zip 类，因为前者对 mcu 来说轻量很多）

@duke807 狗狗都不用

想节省流量，使用 msgpack 的时候，key 名用短一点即可