bczhc

@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 的合法性问题，在可能的未经授权传播上（也即盗版传播）。明面上道理是这样，话要打满些，但其实吧这玩意一般来说也没问题。