作者归档:admin

用 FontForge 改造文泉驿等宽字体

之前,在 Burp Suite 中一直使用 Consolas 字体。自从某次所需的 JRE 版本升级后,字体 fallback 出现问题,汉字都变成了豆腐块,Char Sets 设置也不能解决。于是便不得不寻找新的字体方案。

在网上搜索到了一款 DIY 字体叫做 “Microsoft Yahei Mono”,是 “雅黑的中文部分” 和 “Consolas 的英文部分” 拼起来的缝合怪,虽然可以解决上述问题,但是非高分屏下看起来还是不太舒服。但发现,在 cmd 里替换 simsun 倒是挺合适的,无论高分、低分屏。

然后想到了著名的开源字体——文泉驿微米黑。

该字体包含了所有常用简体中文、繁体中文所需要的汉字 (最新版本包含超过 20932 个汉字,完整覆盖 GB2312/Big5 以及 GBK 标准字符集) 。该字体同时还包含了日文、韩文和其他几十种语言符号。以外,该字体还包含了高质量的 Droid Sans 拉丁符号和 Droid Sans Mono 等宽字体。

——文泉驿微米黑

在 Burp Suite 里使用文泉驿等宽微米黑,觉得舒服了很多,字体比较方正。但是很快发现了一个痛点——数字 0 和大写字母 O 实在是太像了。

于是想着能不能改造一下,把 0 的肚子里用斜杠撑起来以示区分呢?很快找到了利器 FontForge 。

FontForge 里,可以看出 0 和 O 确实太像了,小号字体下更是难区分

双击 “0” 进入单个字体编辑,先新建一个矩形,再用拖动工具拖动矩形的四个顶点,原字体中的四个定位锚点正合适落脚,如图。

保存以后,生成新的 ttf 文件,就可以投入使用了。

还有一个发现是,大概是由于 JDK 字体绘制系统不同的原因,不同 JDK(如 openJDK 和 oracleJDK)打开同一个 jar 应用程序,所能用的已安装字体也不同,比如 oracleJDK 就无法显示文泉驿等一些开源字体。

2024.8.22 更新:在笔记本 1080p 屏幕更换为 2.5K 高分屏后,找到了更好的字体方案:中文部分使用文泉驿和英文符号部分使用 JuliaMono 的糅合版,兼顾了英文字符优美、英文等宽、中文宽度=2 英文宽度等特点。此外发现 Maple 字体霞鹜字体也是很不错的,前者已经在各种命令行界面中使用。

Win10 20H2 内置账户重命名引起的 bug 全纪录

2020 年 10 月,按照 Win10 半年滚动更新的惯例,微软推出了 Windows 10 20H2 。谁能想到,这次更新隐藏了一个和我的使用习惯有关的 bug 。

在半年滚动更新后第一时间就进行升级这种操作这些年有过多次,感觉都挺稳,这次也应该不会有什么问题。于是给自己的工作电脑、家里的娱乐电脑都升了 20H2,升级完成后还非常自信地通过磁盘清理删掉了旧系统备份……

后来的偶然之间,进入 “本地用户和组” 之后立即出现了重大问题——“系统将在一分钟之后重新启动”,此时系统的关键功能包括重启或关机都不可用,只能等一分钟后自动重启。

类似于这样的提示

冷静下来一想,如果是 20H2 升级过程本身的固有问题,那么应该是个极其恶性的 bug,早就全网炸锅了吧?为什么只有我自己的几台升过级的 PC 出现了类似问题呢?(这个时候偏偏忘记了事件查看器)

从 “动了什么引起问题” 很容易想到自己有个习惯:把系统内置的 “Administrator” 账户通过组策略重命名为 “Admin” 以便局域网内共享访问。 Google 搜 “win10 20h2 Administrator rename crash” 等关键词,最终找到了这篇文章,是由于系统关键进程 lsass.exe 崩溃引起的强制重启。文章提到,通过事件查看器可以看到 lsass.exe 的崩溃记录。微软还事后诸葛亮说,在升级 20H2 前应该把系统内置账户 “Administrator” 和 “Guest” 都重命名回本来面目,已经升级的请赶快滚回回滚原来的版本。之后,Win10 易升的升级检查策略也作出了更新,检测到内置账户被重命名会拒绝升级。

后来,微软在这篇文章中阐明了问题产生的原因,大意是 Win10 20H2 升级程序如果遇到 Administrator 被重命名成别的,比如 Admin,(大概会错误地认为 Administrator 不存在)而创建新的 Administrator 账户,这个新的 Administrator 的 SID(安全标识符)和 RID 和原来的 Admin 是一模一样的,而 Windows 本地账户的 SID 原本的设计是独一无二的,以上情况会让 lsass.exe 懵逼继而崩溃,没有了安全大管家 lsass.exe 的 Windows 只能用给用户一分钟的时间然后强制重启。还记得震荡波病毒么?

问题定位了,那怎么解决这个问题?干等到 11 月的 patch Tuesday,微软发布了 KB4586781,结果竟然是屏蔽 “本地用户和组” 中的内容,感觉是临时措施保住 lsass.exe 不崩溃,而后一直都没有实际解决上述冲突问题。

我试了从系统其他任何地方,包括新的 Windows 设置界面、 powershell 、甚至 PE 的密码破解器等都动不了这俩 “Administrator 问题户”,无法解决这个问题。

微软的这篇文章后来更新了(如下图),说他们终于解决了这个问题,意思是在升级过程中不会再犯这个错误,易升的限制措施也随之取消了。然而已经出现问题的用户怎么办,咱也不知道,咱也不敢问。最后的最后怎么解决的?我重装了。

顺便,这里写错了。根据时间线不难得出 2020 年 10 月出的问题应该在 2021 年初解决,所以这里应该是 January 7, 2021,微软还真是越过越回去了。