@kuanat 感谢回复。又测试了手上的 MIUI 13 和 HyperOS ，发现两者对此有不同行为。我做了一些测试。

当按下 Alt 时 onKeyDown 中可以接收到 Alt 事件（如果长按了还会有一连串），但对于 HyperOS ，当按下后续字母时，会有那个字母按键的事件，但对于 MIUI 13 ，则是表现为那串 Alt 事件戛然而止，无后续的字母按键。

另外，才发现 HyperOS 其实同样是处理 compose key 的，以 Alt+S 为例，当系统接收到 Alt+S 时就会上屏`ß`，但尽管如此，不影响 IME 中获取到 Alt 后续的 S 事件，且只有在 IME 不拦截（ onKeyDown 返回`false`）时才会上屏`ß`。反之，HyperOS 中无论 IME 是否拦截，则都会上屏`ß`。拦截无效，显然可以合理怀疑这是 MIUI 13 的 bug 。

在 MIUI 13 中是能找到“实体键盘布局”一选项，但当我选到了其他的布局时，compose key 倒没了（比如按 Alt+S 不会上屏`ß`了），但 IME 中仍然接收不到 Alt 修饰的按键。

那两个文件不需要 root 也可以由 adb 拉取，我看了下内容，左 ALT 的处理正常，如下：

```console
~/keyboard/miui13/keylayout ❯ rg -i 'KEY 56' 17:55:17
qwerty.kl
97:key 56 ALT_LEFT

Vendor_046d_Product_c532.kl
81:key 56 ALT_RIGHT

Vendor_22b8_Product_093d.kl
73:key 56 ALT_LEFT

Vendor_05ac_Product_0239.kl
78:key 56 ALT_LEFT

Vendor_18d1_Product_5018.kl
78:key 56 ALT_LEFT

Generic.kl
78:key 56 ALT_LEFT
```

对于“S”键的处理则都有在被 Alt 修饰时上屏`ß`（`\u00df`）：

```console
~/keyboard/miui13/keychars ❯ rg -i 'KEY S ' --after-context=5 17:57:07
qwerty2.kcm
183:key S {
184- label: 'S'
185- number: '7'
186- base: 's'
187- shift, capslock: 'S'
188- alt: '\u00df'

qwerty.kcm
186:key S {
187- label: 'S'
188- number: '7'
189- base: 's'
190- shift, capslock: 'S'
191- alt: '4'

Generic.kcm
140:key S {
141- label: 'S'
142- base: 's'
143- shift, capslock: 'S'
144- alt: '\u00df'
145-}

Vendor_18d1_Product_5018.kcm
140:key S {
141- label: 'S'
142- base: 's'
143- shift, capslock: 'S'
144- alt: '\u00df'
145-}

Virtual.kcm
137:key S {
138- label: 'S'
139- base: 's'
140- shift, capslock: 'S'
141- alt: '\u00df'
142-}
```

MIUI 13 和 HyperOS 对于这些定义大差不差。没看出有什么大的不妥。顺便说下，MIUI 13 对于 Ctrl 在 IME 中也是获取不到后续按键的。似乎是 MIUI 13 直接一整个把至少这俩修饰键的处理全放在系统中拦截了（哪怕 Alt+某个 key 是完全没有 compose 行为的），就导致了 IME 看不到一点。

其实重点不是这个省略号，而是这个省略号仅仅被 JB HTTP 错误地替换成问号之后，Bilibili API 反而调用成功。此时的 SESSDATA 依然是一个不完整的、没有展开完的值。

就我拿 GitHub Gist+Lepton 当笔记吗

出生时间似乎本就不是期望被篡改的，cp -a 和 rsync -a 的默认行为也都只是保留 mtime ，一般也用这个当作文件创建时间了，当然前提就是后面不去修改它。

还有文件名/文件夹名里直接放日期也不失为一种解决方法呀，很多情况也就这么干。

参考 https://unix.stackexchange.com/questions/719533/copy-a-file-and-preserve-its-creation-date 看它的问题第一条评论和第一个回答

@tyzrj766 没，哈哈。对我也不算太影响，只是好奇这玩意引起的原因，我也向 Mozilla （ bugzilla 编号 1933410 ）和小米社区都反馈了。

更新：找到了更新的字体配置及位置。

`/product/etc/fonts_customization.xml`
```xml
<family customizationType="new-named-family" name="miclock-beihaibei-sc-regular">
<font weight="500" style="normal" postScriptName="BeihaibeiSC-Regular">BeihaibeiSC-Regular.ttf</font>
<family customizationType="new-named-family" name="miclock-beihaibei-tc-regular">
<font weight="500" style="normal" postScriptName="BeihaibeiTC-Regular">BeihaibeiTC-Regular.ttf</font>
...
<font weight="400" style="normal" postScriptName="LogoSCUnboundedSans-Regular">DelaGothicOne.otf</font>
```

文件分别是：`/product/fonts/BeihaibeiSC-Regular.ttf`和`/product/fonts/DelaGothicOne.otf`。

最简单的把 btrfs 里快照挂载到`/`上就可以实现了。还能做到 grub 里按 e 键随意决定进哪个子卷。不过 efi 分区不知能不能是 btrfs ，一般还是多留几个内核镜像，只要有一个能进系统就能修……

搜下 (linux) block-level incremental backup 吧，应该有解决方案的。据我知道的 Btrfs 的 send 不是 block-level 而是 file extent-based 。

@MFWT CD 的话应该还好，抓轨，像是某些加密 DVD 和蓝光的，rip 起来可能就不太方便了。关于合法性我也不太清楚国内有什么要求，这玩意不同国家倒是有不同规则，比如某些地方认为 rip 就是禁止的，有些是，在合法取得物理材料情况下，使用 rip 方案仅作为个人的一种数字归档，是可接受的。主要这里考虑帮别人 rip 的合法性问题，在可能的未经授权传播上（也即盗版传播）。明面上道理是这样，话要打满些，但其实吧这玩意一般来说也没问题。

时代发展真快啊，记得以前电脑都自带光驱。如果真能接到需求也是好的，算是助人了。再不如，升级下，买可打印盘来定制封面，或提供蓝光刻录。顺便一提如果有人要让做 ripping 的，最好不要做，商业光学存储分发材料翻录会有合法性问题。

谢谢大家回复。不退不换倒是，不过还不是认为就是那人纯自己不会用嘛……用不了算了退就退吧这么想。

这件事其实是发生在舍友身上的，让闲鱼客服介入了，但还要物流红章，这显然搞不到，在学校，根本也不会面签，更不可能面前上机测试了。也不知后面怎么掰扯。

是不是如果录了全程视频，从拆箱到上机到发出异常声音，就是铁证据了。可惜这次大意了收到这退货件也没录……

硬盘还是之前那块，没被换。所以我才纳闷，机械盘，还是张空气盘，它怎么自己坏的，那么脆弱吗😂

因为 base64 广泛啊，multipart 里就能用它。而且 64 是 2 整数次方能方便编解码，重新对二进制位分隔就好了。而且其他的 binary-to-text 编码也有，base58 ，base62 base85 base91 等。你说 base32 ，咋不直接用 base16 ，就直接是十六进制咯。最后，base64url 也是事实上的规范。

光盘确实靠谱，我家也有好多我爸那时刻的盘（ DVD 加减 R ，CD-R ），视频啊照片啊电子书啥的，十几年前二十几年前的内容都保存完好。回答问题，如果可以两者都备份，为何不都采用呢？我个人硬盘、蓝光备份都有，有的说自刻盘比压制盘要容易腐朽，有的说蓝光比 DVD 要容易腐朽，但我不管反正就只管搞。（ btw 蓝光要冷备可以看看 M-DISC ）

数据安全性永远不是只寄托在介质安全上的，而是冗余。最后，个人观点，无论如何网盘备份也应纳入考虑方案之一，不应放弃，就当是一种 last resort 好了，毕竟是对个人来说最省事便宜的异地备份方案，安全性可以加密。我很多资料，以前可没那么重视数据安全，要是放硬盘那老老早都消失不知去哪了，而偏偏那时在网盘有存，这不就得以保留了。

发言者是一个 patch 提交者，旁边站的是 Kent ，写 bcachefs 的那个。我看完了，感觉也不太算是吵架吧，就是下面提问题和质疑，上面回答。只是 25:29 那个确实能听出来对 rust 抱有些敌意。

Kent Overstreet ，bcachefs 里的那个？！

应该是盗 cookie 。这么看，感觉个人电脑安全性真的好弱，不知道 windows 和 macos 是怎么样的，反正我的 linux x11 ，任意一个软件，普通用户就能拿到浏览器的 cookie ，参考 yt-dlp 的`--cookies-from-browser firefox`参数。再加上上面看到的一个评论，如果病毒软件内置个代理，直接用你电脑 ip ，更无敌。看来最好的办法还得是自己不要乱运行不明软件