1．前情回顾
为……我写了个AHK脚本，每天在微信群里问同学们“你情绪稳定不”，同学们帮助我一起测试，也调侃我。调试的过程虽然不漫长但是曲折，值得一讲的故事写成了两篇博客。一篇是《写个脚本，问候你今天情绪稳定不》[https://zhuanlan.zhihu.com/p/488537616]，介绍了如何用AHK脚本自动化定时向微信群发送消息，需要应@尽@。另一篇是《情绪稳定不稳定的心路历程 - AHK监听微信群回复》[https://zhuanlan.zhihu.com/p/496703430]，介绍读取微信群中同学们的稳定回应，然后用正则表达式匹配找到不稳定或沉默的同学。
在第二篇中报告了，当时有个相当对付的解决手法，活儿干得有点脏。背景是AHK操作在微信中选择聊天记录，复制到剪贴板。然后在AHK中按名单列表通过正则表达式匹配获取稳定不稳定。在这样的技术背景下，发现正则表达式匹配有问题，谁都能匹配到，无论他发言是不是“稳定”，并且匹配到的偏移量总是整个剪贴板文本字符串的最开头，索引下标是1。然而，保持同一个剪贴板的内容，贴到浏览器里，通过在线的 pcre online 工具匹配，没毛病，匹配的发言和位置都正确。又，把剪贴板粘到记事本里，再复制回剪贴板，也没毛病。 
如下图所示，从AHK操作微信得到的同一剪贴板，到正则表达式匹配，有毛病；过记事本，再到正则表达式匹配，没毛病；通过浏览器使用 PCRE regex online工具匹配正则表达式，也没毛病。
当时解决这一故障的手段挺对付，用AHK打开个记事本，把剪贴板粘到记事本里，再全选、复制到剪贴板中。对从记事本 过 过一遍的剪贴板做正则表达式匹配，达到了想要的效果。
然后终究是不优雅，意难平。
2．心路历程
故事的最终结局是 问题解决了，仅一行代码。难点是在哪里，加入一行什么代码。有趣的部分是定位故障的原因，就像侦探小说一样，到底谁是坏人不重要，重要的是寻找坏人的过程和论证、揭示的严密性。
那行代码在本文最后，接下来是过程。
2．1 验证性实验
要想解决问题，先要知道原因。不知道原理的实验，就是瞎试。瞎试的实验，说得好听一点，可以叫做“探索性实验”。这改改，那捅咕一下，看看会发生什么。婴幼儿和小猫对这类活动乐此不疲，借此认识世界。然而这不是干活的路子，因为一爪子下去是毫无反应还是天崩地裂，我也没谱。干活得有计划，至少要有预期。不然，就是纯玩儿了。
干活什么样呢。我们事先就知道一共就这么四五种方法，哪种方法有什么优缺点也知道，这个活有什么需要也知道。优缺点和需要匹配一下，就知道哪个方法最适合当前需求。解决问题也差不多。造成这个症状的可能一共就那么四五种，挨个试一下，有可能的话探测一下这四五种可能原因的特有现象，有哪个现象就是哪种原因。这是“验证性实验”。
严格地说，应该使用“证伪性实验”。所有的实验都不是为了验证你猜测的可能原因是符合事实的，而是尽可能设计刁钻的实验试图推翻猜测，如果没推翻，那么就可以暂时认为也许、大概、差不多就是这个原因，或者最不坏的就选它了。当然，证伪性实验的第一步与验证性实验相同，就是要先验地知道有哪些可能的原因。所谓”不重不漏”中的“不漏”在这里特别重要。如果你事先没想到，实验是万万什么也发现不了的，因为干活的成年人不探索。
2．2 猜测-剪贴板里的不是文本
这就是瞎猜的，并非从知识体系中回忆起“此类情形有如下三种可能”这样的问答题。如果猜测正确，即剪贴板里不是文本，而是包括文本、格式，以及图像等在内的一些东西（也许不止富文本），就能解释为什么通过记事本以后能好使。事实上，我正是从记事本是纯文本想到了这种可能，也就是记事本与AHK得到的剪贴板的区别是什么，区别是记事本是纯文本的。
验证实验的话，第二篇博客的解决方案就是了。你看，好使，通过记事本把剪贴板转换为纯文本好使了，因此剪贴板原来并非纯文本就是问题的原因。
这个逻辑是错误的，“不重不漏”中有漏。漏了什么呢，把剪贴板转换为纯文本固然使症状消失了，A方法使症状消失，A方法就是原因么？用酒精擦身子能退烧，皮肤缺酒精是发烧（或不退烧）的原因么？喝咖啡心情好，缺咖啡是抑郁的原因么？
攻击的实验是这样的，不少博客说 “Clipboard := Clipboard”，这样一行AHK代码，或者类似的代码，可能把剪贴板转换为纯文本。我加了这行代码，不好使，经过记事本转化就好使。我们还可以补充猜测，这行代码不好使，博客不可信。但是，AHK官方手册中文英都这么说。手册也烂？有时候是这样，那么——有人可能接着想到的是如何解决呢，联系手册作者……但是故障现象这么漫长，而且是微信这种特定场景下，怎么描述呢。
接下来不是解决，而是分析原因。既然怀疑“把剪贴板转换为纯文本”可能不是原因，那么就该设计实验验证这一假说了。
2．3 剪贴板里到底是什么
这是个验证性实验，探测（不是探索）一下剪贴板里到底是什么，什么格式，什么内容。我需要的是剪贴板内容查看工具。
找了几个，没有好的。在 sandboxie 中试了一下，有要要弹出广告，有的要安装服务，有的要常驻内存、修改启动项。Codeproject老牌好工具聚集地，要求注册。我的账号忘了，注册超时。
看不到。
2．4 穷人的必要技能，手动
没有工具，创造工具吧。如果不能做到剪贴板“在线”时查看，那么，输出来。
类似于电路的探针，在不干扰系统运行的情况下，我把剪贴板通过“写文件”操作，写到文件系统中。然后使用第三方查看工具看文件。
写出来了，写了两种。一种是 clipAll，AHK手册说是带格式的。文件内容是二进制，看不懂，得查MSDN看偏移量吧。搁置。另一种是AHK声称为纯文本的，也就是经过“Clipboard := Clipboard”变换过的 clipBoard。真的是纯文本! 而且第一种输出作为对比或者空白实验表明，AHK输出的文件可以是二进制的。那么，输出的东西是纯文本，只能是它原本就是纯文本，而不是在输出过程中转换了。
由验证性实验变成了证伪性实验，否定了我的猜测。我原本猜测“Clipboard := Clipboard”不好使，输出的东西不是纯文本。这样后面正则表达式匹配错误等现象就全都可以解释了。然而，这一猜测不能解释为什么输出了纯文本这一现象，或者说，输出了纯文本这一现象证否了猜测。
猜错了，也没有新猜测了，卡住了。
2．5 捋一捋
我们捋一捋都发生了些什么。
假设第一步输出的剪贴板与第二步输入的剪贴板是同一的，也就是说操作系统和AHK都没碰它，非易失的，这个暂不验证。
猜测过正则表达式匹配有问题，用PCRE regex onlin证否过了。把记事本里的文本复制到剪贴板里，在AHK代码里为字符串赋值，都表明正则表达式匹配没问题。
猜测剪贴板中的并非文本格式，刚刚证否了，就是纯文本。
探索！死马当活马医，再跑一步。把文件读回来。
假设剪贴板写出的文件与读回的文件是同一的，那么
经过“Clipboard := Clipboard”剪贴板 = 文件 = 新的剪贴板
这样，
既然 经过“Clipboard := Clipboard”剪贴板 匹配正则表达式有问题，
那么 新的剪贴板 匹配正则表达式也会有问题。
这就是假设，验证一下。
再跑一步，把写出的文件读回来是探索，但是会发生什么，我有明确的预期。我猜测匹配还是不好使才对，这是验证/证伪。
神奇的事情发生了，意外。好、使、了。把不好使的剪贴板写出去，再读回来，好使了。就像经过记事本（末端相同）、经过浏览器（末端不同）一样，这中间发生了什么变换？我此前假设过记事本的作用是转换剪贴板为纯文本，但是这个假说被证否了，剪贴板本来就是纯文，差异（由匹配错误到匹配正确，由不好使到好使）的原因不是转换为纯文本。也就是说，在经过记事本，或者经过写读文件这个过程，中间除了转换为纯文本，还发生了点别的什么。
别的什么，是什么？
有的同学可能插话，好使了，那不就是解决了么。好使了，只是故障现象消失，我并不知道原因。莫名其妙消失的，也可能莫名其妙突然再次出现。就在你论文答辩现场，在你项目验收现场，在甲方大老板亲临现场的时候，在最重要的客户试用的时候，突如其来，让你措手不及。
2．6 变小了？
我用 msgbox 作为探针把这几个东西都打出来，一个个看。由微信复制得到的剪贴板，经过“Clipboard := Clipboard”的剪贴板，写出的文件（用记事本查看），读回的文件……它们全都一样。
看起来都一样，但是表现不一样。说明，有我看不到的东西存在。
什么呢？一个字符一个字符打印出来……试了一会儿，太长了，我很快疲劳，鉴别能力下降，比对结论值得怀疑了。表面上这是探索，然后这是验证性实验，验证/证伪的猜测是“它们不一样”。
猜测，写出文件，应该是文件变小了，格式发生了什么变化，去除了 非文本 的什么东西。
我做实验，打印出这些东西的字节数。由微信复制得到的剪贴板，经过“Clipboard := Clipboard”的剪贴板，写出的文件（用记事本查看），读回的文件……
由微信复制得到的剪贴板最大，这是意料之中的。因为根据AHK手册，经过“Clipboard := Clipboard”变换，得到的 clipboard 去除了非文本元素，变小是对的。
意外又出现了。写出的文件，比写出前的剪贴板，大了。我以为会变小，这是猜测，实验结果证伪了这一猜测。好，所有的意外都提供了新的信息。
为什么会变大，增加的是什么，值得对比了。比对之前，我发现增加的字符数似乎与行数相同。有的同学到此可能已经猜到原因了，我当时没猜到。
我做了个短的剪贴板，1.用AHK转换为纯文本，假设转换成功。逐一打印出字符的ASCII。因为有东西看不见，所以ASCII更可靠；2。把写出的文件用 emacs hexl-mode （十六进制）打开。对比二者。
一目了然。拍大腿，这么简单啊。所有的bug，都是简单的，只是在定位以前我们不知道它在哪里。
以下是当时的日志截图。
回车这个词是有二义性的。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([^不:]*?)稳定"
回顾一下整个实验和代码中的数据流，如下。在数据流图中，特别关注变换，数据的类型的变换。
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代码采集到。
感慨 即使几率微小，在大样本的情况下，也必然发生。
这样，做出发送模块，又做出了采集模块和匹配模块。最后解决了采集模块和匹配模块这两个模块间的接口剪贴板问题。解决最后这一行代码10个字符，过程曲折，我日志的部分标题如下。猜测，然后证伪，不断尝试，直至找到坏人。结果甚至是次要的，这个过程充满趣味，令我乐此不疲。
两个交点，两个解。而且这两个解在图中正是两条曲线的交点，横轴以3为中心对称，±根号5，纵轴以3为中心对称，±根号5，两个值刚好互换……
