稳定了,解决传输途径不畅的心路历程:AHK操作微信群第3集

微信图片_20220512152526

1.前情回顾

为……我写了个AHK脚本,每天在微信群里问同学们“你情绪稳定不”,同学们帮助我一起测试,也调侃我。调试的过程虽然不漫长但是曲折,值得一讲的故事写成了两篇博客。一篇是《写个脚本,问候你今天情绪稳定不》[https://zhuanlan.zhihu.com/p/488537616],介绍了如何用AHK脚本自动化定时向微信群发送消息,需要应@尽@。另一篇是《情绪稳定不稳定的心路历程 - AHK监听微信群回复》[https://zhuanlan.zhihu.com/p/496703430],介绍读取微信群中同学们的稳定回应,然后用正则表达式匹配找到不稳定或沉默的同学。image1在第二篇中报告了,当时有个相当对付的解决手法,活儿干得有点脏。背景是AHK操作在微信中选择聊天记录,复制到剪贴板。然后在AHK中按名单列表通过正则表达式匹配获取稳定不稳定。在这样的技术背景下,发现正则表达式匹配有问题,谁都能匹配到,无论他发言是不是“稳定”,并且匹配到的偏移量总是整个剪贴板文本字符串的最开头,索引下标是1。然而,保持同一个剪贴板的内容,贴到浏览器里,通过在线的 pcre online 工具匹配,没毛病,匹配的发言和位置都正确。又,把剪贴板粘到记事本里,再复制回剪贴板,也没毛病。 image2

如下图所示,从AHK操作微信得到的同一剪贴板,到正则表达式匹配,有毛病;过记事本,再到正则表达式匹配,没毛病;通过浏览器使用 PCRE regex online工具匹配正则表达式,也没毛病。

当时解决这一故障的手段挺对付,用AHK打开个记事本,把剪贴板粘到记事本里,再全选、复制到剪贴板中。对从记事本 过 过一遍的剪贴板做正则表达式匹配,达到了想要的效果。

然后终究是不优雅,意难平。

2.心路历程

故事的最终结局是 问题解决了,仅一行代码。难点是在哪里,加入一行什么代码。有趣的部分是定位故障的原因,就像侦探小说一样,到底谁是坏人不重要,重要的是寻找坏人的过程和论证、揭示的严密性。

那行代码在本文最后,接下来是过程。

2.1 验证性实验

要想解决问题,先要知道原因。不知道原理的实验,就是瞎试。瞎试的实验,说得好听一点,可以叫做“探索性实验”。这改改,那捅咕一下,看看会发生什么。婴幼儿和小猫对这类活动乐此不疲,借此认识世界。然而这不是干活的路子,因为一爪子下去是毫无反应还是天崩地裂,我也没谱。干活得有计划,至少要有预期。不然,就是纯玩儿了。

干活什么样呢。我们事先就知道一共就这么四五种方法,哪种方法有什么优缺点也知道,这个活有什么需要也知道。优缺点和需要匹配一下,就知道哪个方法最适合当前需求。解决问题也差不多。造成这个症状的可能一共就那么四五种,挨个试一下,有可能的话探测一下这四五种可能原因的特有现象,有哪个现象就是哪种原因。这是“验证性实验”。

严格地说,应该使用“证伪性实验”。所有的实验都不是为了验证你猜测的可能原因是符合事实的,而是尽可能设计刁钻的实验试图推翻猜测,如果没推翻,那么就可以暂时认为也许、大概、差不多就是这个原因,或者最不坏的就选它了。当然,证伪性实验的第一步与验证性实验相同,就是要先验地知道有哪些可能的原因。所谓”不重不漏”中的“不漏”在这里特别重要。如果你事先没想到,实验是万万什么也发现不了的,因为干活的成年人不探索。

微信图片_20220512152529

2.2 猜测-剪贴板里的不是文本

这就是瞎猜的,并非从知识体系中回忆起“此类情形有如下三种可能”这样的问答题。如果猜测正确,即剪贴板里不是文本,而是包括文本、格式,以及图像等在内的一些东西(也许不止富文本),就能解释为什么通过记事本以后能好使。事实上,我正是从记事本是纯文本想到了这种可能,也就是记事本与AHK得到的剪贴板的区别是什么,区别是记事本是纯文本的。

验证实验的话,第二篇博客的解决方案就是了。你看,好使,通过记事本把剪贴板转换为纯文本好使了,因此剪贴板原来并非纯文本就是问题的原因。

这个逻辑是错误的,“不重不漏”中有漏。漏了什么呢,把剪贴板转换为纯文本固然使症状消失了,A方法使症状消失,A方法就是原因么?用酒精擦身子能退烧,皮肤缺酒精是发烧(或不退烧)的原因么?喝咖啡心情好,缺咖啡是抑郁的原因么?

攻击的实验是这样的,不少博客说 “Clipboard := Clipboard”,这样一行AHK代码,或者类似的代码,可能把剪贴板转换为纯文本。我加了这行代码,不好使,经过记事本转化就好使。我们还可以补充猜测,这行代码不好使,博客不可信。但是,AHK官方手册中文英都这么说。手册也烂?有时候是这样,那么——有人可能接着想到的是如何解决呢,联系手册作者……但是故障现象这么漫长,而且是微信这种特定场景下,怎么描述呢。

接下来不是解决,而是分析原因。既然怀疑“把剪贴板转换为纯文本”可能不是原因,那么就该设计实验验证这一假说了。

微信图片_20220512152528

2.3 剪贴板里到底是什么

这是个验证性实验,探测(不是探索)一下剪贴板里到底是什么,什么格式,什么内容。我需要的是剪贴板内容查看工具。

找了几个,没有好的。在 sandboxie 中试了一下,有要要弹出广告,有的要安装服务,有的要常驻内存、修改启动项。Codeproject老牌好工具聚集地,要求注册。我的账号忘了,注册超时。

看不到。

2.4 穷人的必要技能,手动

 没有工具,创造工具吧。如果不能做到剪贴板“在线”时查看,那么,输出来。

image3

类似于电路的探针,在不干扰系统运行的情况下,我把剪贴板通过“写文件”操作,写到文件系统中。然后使用第三方查看工具看文件。

写出来了,写了两种。一种是 clipAll,AHK手册说是带格式的。文件内容是二进制,看不懂,得查MSDN看偏移量吧。搁置。另一种是AHK声称为纯文本的,也就是经过“Clipboard := Clipboard”变换过的 clipBoard。真的是纯文本! 而且第一种输出作为对比或者空白实验表明,AHK输出的文件可以是二进制的。那么,输出的东西是纯文本,只能是它原本就是纯文本,而不是在输出过程中转换了。

由验证性实验变成了证伪性实验,否定了我的猜测。我原本猜测“Clipboard := Clipboard”不好使,输出的东西不是纯文本。这样后面正则表达式匹配错误等现象就全都可以解释了。然而,这一猜测不能解释为什么输出了纯文本这一现象,或者说,输出了纯文本这一现象证否了猜测。

猜错了,也没有新猜测了,卡住了。

2.5 捋一捋

我们捋一捋都发生了些什么。

假设第一步输出的剪贴板与第二步输入的剪贴板是同一的,也就是说操作系统和AHK都没碰它,非易失的,这个暂不验证。

猜测过正则表达式匹配有问题,用PCRE regex onlin证否过了。把记事本里的文本复制到剪贴板里,在AHK代码里为字符串赋值,都表明正则表达式匹配没问题。

猜测剪贴板中的并非文本格式,刚刚证否了,就是纯文本。

探索!死马当活马医,再跑一步。把文件读回来。

image4

假设剪贴板写出的文件与读回的文件是同一的,那么
经过“Clipboard := Clipboard”剪贴板 = 文件 = 新的剪贴板

这样,

既然 经过“Clipboard := Clipboard”剪贴板 匹配正则表达式有问题,

那么 新的剪贴板 匹配正则表达式也会有问题。

这就是假设,验证一下。

再跑一步,把写出的文件读回来是探索,但是会发生什么,我有明确的预期。我猜测匹配还是不好使才对,这是验证/证伪。

神奇的事情发生了,意外。好、使、了。把不好使的剪贴板写出去,再读回来,好使了。就像经过记事本(末端相同)、经过浏览器(末端不同)一样,这中间发生了什么变换?我此前假设过记事本的作用是转换剪贴板为纯文本,但是这个假说被证否了,剪贴板本来就是纯文,差异(由匹配错误到匹配正确,由不好使到好使)的原因不是转换为纯文本。也就是说,在经过记事本,或者经过写读文件这个过程,中间除了转换为纯文本,还发生了点别的什么。

别的什么,是什么?

有的同学可能插话,好使了,那不就是解决了么。好使了,只是故障现象消失,我并不知道原因。莫名其妙消失的,也可能莫名其妙突然再次出现。就在你论文答辩现场,在你项目验收现场,在甲方大老板亲临现场的时候,在最重要的客户试用的时候,突如其来,让你措手不及。

微信图片_20220512152532

2.6 变小了?

我用 msgbox 作为探针把这几个东西都打出来,一个个看。由微信复制得到的剪贴板,经过“Clipboard := Clipboard”的剪贴板,写出的文件(用记事本查看),读回的文件……它们全都一样。

看起来都一样,但是表现不一样。说明,有我看不到的东西存在。

什么呢?一个字符一个字符打印出来……试了一会儿,太长了,我很快疲劳,鉴别能力下降,比对结论值得怀疑了。表面上这是探索,然后这是验证性实验,验证/证伪的猜测是“它们不一样”。

猜测,写出文件,应该是文件变小了,格式发生了什么变化,去除了 非文本 的什么东西。

我做实验,打印出这些东西的字节数。由微信复制得到的剪贴板,经过“Clipboard := Clipboard”的剪贴板,写出的文件(用记事本查看),读回的文件……

由微信复制得到的剪贴板最大,这是意料之中的。因为根据AHK手册,经过“Clipboard := Clipboard”变换,得到的 clipboard 去除了非文本元素,变小是对的。

意外又出现了。写出的文件,比写出前的剪贴板,大了。我以为会变小,这是猜测,实验结果证伪了这一猜测。好,所有的意外都提供了新的信息。

为什么会变大,增加的是什么,值得对比了。比对之前,我发现增加的字符数似乎与行数相同。有的同学到此可能已经猜到原因了,我当时没猜到。

我做了个短的剪贴板,1.用AHK转换为纯文本,假设转换成功。逐一打印出字符的ASCII。因为有东西看不见,所以ASCII更可靠;2。把写出的文件用 emacs hexl-mode (十六进制)打开。对比二者。

一目了然。拍大腿,这么简单啊。所有的bug,都是简单的,只是在定位以前我们不知道它在哪里。

以下是当时的日志截图。

image5

回车这个词是有二义性的。Windows操作系统下,回车是两个字符,CR Carriage Return 译为回车 13(0x0d),和 LF line feed 译为换行 0x10(0x0a)。Unix操作系统下,回车是单个字符,LF line feed 换行 0x10(0x0a)。

微信复制到剪贴板的文本,即使在windows操作系统下,也遵循了Unix的习惯,回车是单个字符。

2.7 解决

我写的正则表达式,匹配回车的时候只匹配1个字符。为什么在Windows下能工作呢?因为从微信复制到剪贴板以后,一直在AHK中工作,与操作系统无关。写入文件、贴到记事本里、贴到浏览器中,都涉及进程间通信,经过操作系统之手了。

既然知道了原理,就有了比写出文件再读回来更好的解决方法,当然比开个记事本不能碰机器更好。

只修改了一行代码,确切地说,增加了10个字符,匹配任意回车。

新的正确写法 needle := "(*ANYCRLF).*" element ".*:\R([^不:]*?)稳定"
旧的错误写法 needle :=           ".*" element ".*:\R([^不:]*?)稳定"

回顾一下整个实验和代码中的数据流,如下。在数据流图中,特别关注变换,数据的类型的变换。

image6

3.未来

修改以后,代码跑了一段时间了,代码稳定,我们也每天说自己稳定。

昨天,发现了两个bug,暂不修复。不过挺有意思,所以在这里讲一下。

都是剪贴板的问题,在转换成纯文本以前就出毛病了,不过仍然可以通过剪贴板贴到记事本里作为探针查数据来诊断。

第一个bug是有位WT同学明明回复了“稳定”,但是监听脚本仍然报告他不稳定或者未回应。有诸多可能的原因,我首先要排除 剪贴板的内容错了 这种可能性。选哪里开始,是另一个漫长的话题,以后再说。

对比粘到记事本里的剪贴板和微信聊天记录,可以发现,WT同学在微信聊天记录里回复了“稳定”,但是粘到记事本里的剪贴板中,他的发言刚好没了。前一名和后一名同学的发言都在,WT同学连人名带发言都消失了。猜测是昨天我们大家讨论的内容比较多,在AHK询问的时候仍然在频繁互动,所以攒下了不少聊天记录。聊天记录长到AHK由下向上滚动复制的过程,需要翻页才能到达询问的时刻。在触发翻页展开这个动作中,跳过了一些(这个案例中是一条)消息。

感慨 生产场景比测试场景更复杂,充满了我们没有预料到也因此未做约束的情况。

第二个bug是有位TYQ同学,他的回应刚好在22:34,这正是AHK开始操作微信群复制聊天记录开始的时刻。TYQ回复的时候,AHK代码已经开始向上复制内容,所以没有抓到他的消息。

第一步 我开始复制;

第二步 他回复了,我没复制到;

第三步 我的正则表达式匹配,稳定数组里没有他;

第四步 我发报告,稳定数组里没有他。

TYQ同学总结,这类似于线程安全问题,在AHK汇总的时候,有线程乱入了。我的AHK代码不是原子操作,也没有在开始汇总(复制、匹配、报告)之前冻结聊天现场,因此有微小的几率,就是在22:34:00 到 22:34:02 大约这么长的时间内,回应的消息不能被我的AHK代码采集到。

感慨 即使几率微小,在大样本的情况下,也必然发生。

微信图片_20220512152530

这样,做出发送模块,又做出了采集模块和匹配模块。最后解决了采集模块和匹配模块这两个模块间的接口剪贴板问题。解决最后这一行代码10个字符,过程曲折,我日志的部分标题如下。猜测,然后证伪,不断尝试,直至找到坏人。结果甚至是次要的,这个过程充满趣味,令我乐此不疲。

image7

Leave a Reply

Your email address will not be published. Required fields are marked *