@duke807
我没看出你对 simd 或者其他数据传输格式有了解。你非要数据那我就跑一下。
以最常见的 twitter.json 作为测试数据 https://github.com/simdjson/simdjson/tree/master/jsonexamples

体积：相差并不大
json: 467KB
msgpack: 402KB

在手头 M1 上跑 simdjson 和 msgpack-c 来解析，循环 16 次
simd:dom: 759MB/s
simd:ondemand: 1604MB/s
msgpack-c: 948MB/s
msgpack 并没有明显优势，而且也没验证 UTF-8 编码。
另外如果 simdjson 在现代 x86 上跑的更快。

json 缺点一大堆，唯一最大的优点就是人类可读写，msgpack 并没有继承这个优点。

之前有段时间在 solidot 上看到过好几次凹语言的推荐，每次都要强调凹读 wa ，但我每次看到还是会下意识读成 ao 。

@duke807 看来你不明白 simd 是怎么工作的。。simd 在处理较长数据时才会优势显著，如果你把字符串拆分出来，再用 simd 校验每个字符串，就会因为需要额外对齐或者数据过短无法向量化导致性能甚至会下降的。

回头再来看看我们讨论的适用场景：如果你是对外的服务提供者，无论是为前后端还是客户端，那明智的选择是尽可能为`更多人`服务，用 json 是毫无疑问的。所谓小众格式说的并非是没人用，而是 json 已经是事实标准、占据统治地位，其他格式的支持程序、系统生态根本不在一个量级上。

如果你是给自己的系统选择数据传输格式，追修更高读写性能和更小流量，那还有 flatbuffer 和 capn proto 等所谓 0 解码耗时的 zero-copy 方案。选择 msgpack 更多的是那些过去 json 带来的惯性，并不是什么追新。

@duke807 接口方面，你不可能要求后端同学花费力气去专门为小众需求单独开发一个接口。而且即使对齐到 json 格式的话，支持多种格式也需要后端单独做开发和测试，这和运维同学改改 nginx 配置完全不是一个工作量。

我觉得性能方面你想当然了。simdjson 能用 simd 快速教研整个 json 的 UTF-8 编码，实际上现在解析速度也能达到 3GB/s ，甚至还能按需解析性能还会更高。msgpack 里面的字符串也是 UTF-8 的，但我没见有什么库愿意去写 simd 加速或者按需解析的。

如果你把应用范围限定在嵌入式，那和上面我们讨论的完全不是一回事儿了，性能又不是主要考虑的东西。如果你说没有 malloc ，那就算用 JSON 库也有很多允许自定义 allocator 或者自带 fixed memory allocation 功能的库，这完全没问题。

@duke807 如果你同时支持两种格式，那只能让功能向 json 对齐，msgpack 的额外功能就用不到，结果无非就是省些流量。如果再 gzip 一下，那两者连流量的差距都很小了，这只要在 nginx 配一下就行，对应用来说都是透明的。

如果说性能，正是因为 json 流行，现在各个语言都有一堆高度优化甚至 simd 加速的库，其他格式没这个待遇的。有特殊需求的，这里还有一堆二进制格式可选呢： https://en.wikipedia.org/wiki/Comparison_of_data-serialization_formats

如果服务仅限自己使用，那什么格式都无所谓，甚至自定义个私有格式也许在性能上更好。
如果你要给别人用，那当然要考虑最通用的，并不是每个人都有能力或者愿意去兼容其他更小众的格式。
何况 msgpack 在性能上并没有明显优势，不一定比得上 JSON 压缩+simdjson 。

在这个 json 已经是数据交换事实标准的情况下，你给别人提供服务用 msgpack ，那才是没眼光。

换小众浏览器，比如 Opera 、Brave 、Vivaldi 。但公司还是能记录你访问的域名和流量，只是公司一般不管罢了。
正派做法是不要再公司设备上做私人事情。。

https://i.imgur.com/EGG7YZE.png
老夫写代码就是一把梭 /拿起键盘就是干
感觉已经是历史了

我想起日本好几年前的那个概念《低欲望社会》
经济增长停滞后的急转直下的那种社会氛围，人们失去对未来的期望。存款增多、消费停滞，人们的欲望也逐渐降低。

@alne 你脑子是怎么转的？法规出来后大部分企业还是要尽量遵守的，除非你有自信你的公司能达到 pdd 无耻的程度而且还不被查。

你作为人来写程序不可能没 Bug
AI 生成也不可能保证准确和符合价值观

但是你写了 Bug 有人能帮你测试，而且 Bug 多了顶多绩效不好
意见稿那个要不符，可是能直接把你业务关停的，说不准还要罚钱

可以自己去提案啊，
这是准则： https://unicode.org/emoji/proposals.html
这是请求受理情况 (信息不太透明)： https://unicode.org/emoji/emoji-requests.html

我家当地的习俗是醋+蒜泥+香油，蒜泥捣的时候可以稍微撒点盐。
和同学出去吃饭，四川的同学喜欢辣椒+蒜蓉+醋。广东的同学就喜欢酱油。

说到这里我又想起了那个梗，吃饺子不沾酱油被关监狱一年多：
https://www.163.com/dy/article/I0N784A30552QOTX.html

现代版小马过河
老牛说，河水很浅，我过河完全没问题啊，别听别人瞎说。
松鼠说：这河根本过不了，亲测，那些说河水很浅的人不是蠢就是坏。
小马：反正每次都有人说过不了河，我来说一下我的经验吧...

让图片和文字出现在一条消息里这是在想什么。。这是要写电子邮件吗？

Anker 或者贝尔金，选个喜欢的样式就行。
充电头是个品牌货都问题不大，但我给被人推荐肯定不会推荐小米倍思之类的。

@DrLty @est 如果单纯提供 "压缩 /原图" 显然还是有用户不满意，指责"替用户选择"。如果真让用户选择，那应该提供 JPEG/PNG/TIFF/GIF/BMP/PDF/HEIF 格式选择，并且提供压缩质量调节、尺寸调节、是否保留元数据等选项。

但这些选项在自带的快捷指令里都可以做到。

截图肯定是要无损压缩，所以用 png 格式是正确的。
如果你在乎文件体积想要有损压缩，那可以建个快捷指令，从共享表单接收图像，然后转为 HEIF 或者 JPEG ，截图后点一下分享就有了。