跳过解释awtrix是什么的部分。
奇怪为什么没有固件没有实现中文，也没有支持中文的插件。
最初怀疑开发者只是为了省事..和这个东西确实太小众，只在视频up主之间吹捧所以真正懂技术的玩的不多
于是琢磨自己来实现——最基础的部分，在屏幕上显示出汉字。思路如下
失败原因一句话总结：
第二步进行不下去，要找到8px还能清晰显示的汉字失败.. 最小清晰显示的宋体尺寸实测 12px左右。
8px的常见字体PS中的模拟效果，常见的几种系统字体，辨识度很差
支持汉字的 lametrie 显示效果我找到其他up开箱的实测片段发现...emmm 也是有点惨不忍睹的
或许我找到比较好的缩小TTF像素化显示的字体或算法后，会继续尝试也说不定。暂时搁一边了。
P.S. 到手之前非常期待，上手5分钟一阵抽搐之后..顿觉索然无味...这就是人生吧
越忙越见鬼，遇到奇怪的东西，实在吊诡。
php和mysql和phpmyadmin都未曾改动或升级，已使用一年有多。
今天登录 phpmyadmin 账号管理页面顶部提示
You do not have privileges to manipulate with the users!
看首页右侧登录信息，确认是 root账号没错，不过显示的是 root@ 而不是 root@localhost
（截图不能重现）
注销重新登录无效；
重启 LNMP服务无效；
换浏览器登录无效；
尝试根据一些别人的文章去修改设置，也没有得到预期的效果（更糟了，部分库变得不能访问，还好有备份赶紧还原）。
ssh上服务器用命令行进mysql 执行账号操作，被提示 grant 操作不支持
The MySQL server is running with the --skip-grant-tables option so it cannot execute this statement
又查了一下别人的解决办法，用下面的命令解决（但似乎无关）
mysql> flush privileges;
后来发现更诡异的事情，视乎我用错误的账号和密码都可以登录.
额——
于是去查看最初的备忘，发现这个数据库的初始密码确实不是常用的，也无从考究最初是谁部署的
用正确的密码登录...发现一切都好了
难道问题只是因为浏览器的cookie登录，导致的权限问题？ 不得而知
法克！讨厌这种绕了一大圈问题消失了而不是解决了的便秘感。
先扔参考文链接
windows直接上传带文件名带中文的文件到linux, linux 系统的字符编码默认是utf-8。
文件名的中文部分会显示乱码，且在把文件名 print 出来时 一定概率会触发 一个 UnicodeEncodeError 异常 提示 surrogates not allowed
def bad_filename(filename):
return repr(filename)[1:-1]
try:
print(filename)
except UnicodeEncodeError:
print(bad_filename(filename))
对异常文件处理可以根据自己需要制定策略，例如 os.rename 过滤掉汉字部分，或 更彻底用 uuid.uuid1() 赋予新文件名。
先声明，这不是教学也没有自称是最正统王道的做法。只是适用于我当前项目的情况。
背景：一个后台的守护进程，会对导入的批量文件进行轮询及列队处理。
这些目标文件可能有各种预期外的格式、数据类型不正确导致py崩溃中途退出。造成了队列堵塞
当发现堵塞时，手动去运行脚本可以查看到有问题的关键文件。但想找个办法让遇到问题是能跳过不阻塞队列，但保留错误信息到日志以便追查处理。
以下是我的处理办法。核心是用 try/exception 和 logging 捕获异常写入自定义日志文件。
import logging
# 设置输出错误日志
logging.basicConfig(filename='pyerr.log', filemode='w')
# 扫描待处理的目录，查找 docx文件
filelist = os.listdir(scan_path)
for dfile in filelist:
if dfile[-5:].lower() == ".docx":
try:
imp_result = mod_doc.import_db(scan_path+dfile) #这步是容易出现异常的导入复杂操作
# 导出处理结果的业务逻辑 略
except: #把异常写入日志文件
s = traceback.format_exc()
logging.error(dfile+'\n'+s)
else:
print("non docx file, skip:"+dfile)
仅作备忘，有关异常处理和日志处理的用法这里不展开说明。
业务逻辑中处理完毕的文档会被转移归档保存，所以剩下在目录里的则是异常的文件。
如想避免异常文件每轮的轮询仍被执行, 可以转移到特定文件夹并修改 logging.basicConfig 的 filemode 改为 'a' 使多个异常文档的错误信息不会被覆盖。
接连处理了微软坑爹的windows补丁、意外而来的流氓软件。蓝屏问题解决了，但显卡驱动崩了的状况还是接二连三。
怀疑是不是还有其他补丁的冲突问题，更新最新驱动 和 还原远古驱动，问题依旧。
一筹莫展之时发现显卡到了70°C 就会崩，心都吓凉了不会是硬件问题吧...拆机检查，风扇竟然一直不转！
网友给了线索如果用微星的显卡超频工具（小飞机）调整过风扇转速有可能会导致驱动升级后风扇不转!!!
一经测试果真如此，重新设置自定义转速后温度压下来了，满载57°C !没有再出现驱动崩溃的状况
（准确的说可能是因为温度骤升GPU自我保护直接罢工）
所以一切都是后台更新驱动的锅吗...