> for (level = 0, p = argv[1]; *p; p++)

这个处理方法是不对的，一个 char 代表「 UTF-8 编码序列中的一个字节」，不存在任何和文本相关的含义。尽管 UTF-8 有一些和 ASCII 兼容的假设，但存在很多 corner case （就像主帖提到的），所以不可靠。

如果是高级语言，要枚举字符应当先枚举 Unicode 码点（ runes ）。

用 mbtowc 转换其实也有问题。wc 指的是「空终止宽字符串」，它不等于 runes 。例如，Windows 上它代指的是经过 UTF-16LE [1] 编码的字符串，对高位字符也需要用多字节的 surrogate pairs 来占位。Linux 上可能是 UTF-32 ，但也不一定。总之，一般建议避免使用 wchar_t 。

言而总之，如果你想枚举 UTF-8 字符串中的字符，最合规的做法是要么依赖 ICU 、utf-8 这样的字符处理库，要么用 C11 里的 mbrtoc32 （ mb -> UTF-32 ）。

[1] https://learn.microsoft.com/en-us/cpp/cpp/char-wchar-t-char16-t-char32-t

1. 太慢，有 3-5s 延迟，体感比 cursor tab 慢两三倍
2. 建议不积极。比如经常改了一个变量名，明明后面有三处在使用变量，它只提示你修改第二处的名称，其他两处不管了

@zapan 确实弃坑了，我回来用 Mihomo Party 好久了。Sing-box 搭服务器不错，做客户端有点受罪。

找了一下，貌似有个 fork 是活跃维护的： https://github.com/bernard-xu/nekoray

@w568w 补：不过我同意的一点是，在 Android （ View ）开发里我确实见到了对 MVVM 最丑陋、最臃肿、最复杂的实现。以至于这么自然顺畅的思想，在一部分 Android 开发眼中是需要专门学习的艰深理论。

@lisongeee MVVM 是一种「设计范式」，Reactive 是实现这个设计范式的一种「工具」。两者不冲突。

ui 就是 view ，f 就是 view model ，state 就是 model 。

MVVM 里：v 绑定 vm ，vm 更新 m 。m 变化通知 vm ，vm 计算变化通知 v 刷新。
正如 reactive UI 里：ui 绑定 f ，f 更新 state 。state 更新通知 f ，f 计算新值通知 ui 刷新。

看起来他们根本不打算花人力支持 X11 下的 DPI 缩放： https://github.com/flutter/flutter/issues/65517

不过 Wayland 上是正常的。

@shunia 倒是可以做一个类似 iOS 那样自定义语音快捷指令的平台

这个前端做的还不错啊，即使放在「前端模仿 Windows 桌面」这类项目里也是一流的交互体验了。

> clash 删库跑路了，谁知道怎么回事

都快一年了……楼主多久没上网了解信息了？

> 我感觉 Flclash 比 clash for windows 好用

再看看 Verge 和 Mihomo Party 吧

@hanguofu 这是另一个话题了。我需求的前提就是假设用的是有语音助手的国产 ROM 。

没有语音助手的话，那多半是第三方 ROM 。这种情况下先看看语音唤醒 DSP 是否支持，如果支持的话直接刷 Google Assistant 就行了；否则就只能自己用第三方的语音助手了，比如小爱同学 App 。

几乎所有现代音视频处理的基石。你用网页、用电脑、用手机看任何来源的视频，基本都无法避开 ffmpeg 。

ffmpeg 对闭源引用相当容忍了，但依然有 99% 的商业巨头甚至不愿意高抬贵手在他们的软件里留下一行致谢给 ffmpeg ，以至于会默默无闻到有人像楼主一样来发帖问，这就是现实。

---

一些轶闻：

1. ffmpeg 曾经维护了一个「开源耻辱柱」，用来记录所有那些无偿使用 ffmpeg 且无视开源协议的商业软件。后来这个列表实在太长且难以维护，于是就弃置了。

2. 你发的这幅图应该是修改过的，原图是 xkcd 的漫画，说的是另一个软件：image magick 。如果你没听说过它：它是几乎所有具备图像处理功能软件的基石。

@SeleiXi #3 方向反了，你这就好像看到 Win7 有安全漏洞，不用 Win10 ，去用 Win98 了 https://i.imgur.com/XKj1Tkx.png 同楼上推荐 Mihomo Party

@gigishy 提高可靠性到百年是加钱能解决的问题，但这要看愿意付出多少对应的成本。

只考虑单一技术方案肯定是不可行的。磁带也只能保存 30 年左右。就目前的科技水平，还是考虑每 10 年挪一个地方储存最安全。

我想到的一些措施：

软件的：

1. Parchive 添加奇偶校验恢复记录
2. 机械硬盘组 RAIDZ
3. 至少上两个云服务，里面至少一个企业级服务，例如 Amazon S3/Backblaze B2/Onedrive/iCloud…，Amazon 、阿里云、腾讯云都有冰川深度储存，价格相对比较低。

硬件的：

1. 光盘可以看看 M-DISC 蓝光，声称可保存一千年
2. NAS 加 UPS 防断电，监控健康度。机械硬盘 10 年是下限，在此期间内若坏了属产品质量问题
3. 歪点子：有一些有公众历史意义的文件（例如家族族谱、百年前的个人记录），可捐一份给当地博物馆或图书馆，或者打印成胶片储存

> 尝试过光盘、磁带、机械硬盘（包括 nas ）（都有过丢失数据的惨痛经历）

想听听你的光盘和磁带是怎么丢数据的。保存不善？

@okakuyang

> 现实中很多人都不知道安卓边缘返回的手势这个操作

？？？我满头问号，请问你活在哪个平行世界？

口口声声「理性讨论」「不要上升人身攻击」，然而自己把「方向反了」上升到「不跟手」，继而滑坡到「不优雅」。这个「不优雅」和「真正优秀的交互」是谁来定义的？你吗？

那我也来定义一个：真正优雅的交互，应当是便利且容易学习的，而不是为了所谓的一致性增加交互成本。综上，我认为 iOS 所谓的“随处放返回，一会左上角一会右滑”特性，并不是一种优雅的设计。

反驳观点没有价值，因为全是不客观的定义和推断

@yiyiniu 就按照上面日志的 Flutter fix 里写的操作啊。先看看你的 Gradle 是什么版本，然后对照 Compatibility Matrix 看看需要什么 Java 版本。Java 21 只有 Gradle 8.4 以后才支持，要么升级 Gradle ，要么降级 Java