xmokay

> 哈哈，感谢你发现了这个神奇的Bug~ > > 我调查了一下，发现事情是这样的：剪贴板里的数据有各种格式定义嘛，比如`位图CF_BITMAP、文件句柄CF_HDROP、字符串CF_UNICODETEXT`等。一条数据可以同时具有多种格式。我之前的代码只检测剪贴板是否为位图CF_BITMAP，是则调用OCR。 > > 而微信复制的时候，它先把图片写入临时文件夹`C:\Users\xxxx\AppData\Local\Temp\WeChat Files`，再把图片字节和文件句柄同时写入剪贴板，即同时具有`CF_BITMAP`和`CF_HDROP`双重属性，因此干扰了我程序的判断。 > > 实际上，我[昨天的更新](https://github.com/hiroi-sora/Umi-OCR/commit/c190f02d3d5173ec48f528a2f6d8b8ea3f216ce7)已经间接解决了这个问题，能以**读入临时文件的文件句柄**的形式识别微信复制到剪贴板的图片了。不过还不够完美，我之后试试改成优先以**位图**的形式读入~ ------- 这么快就回复，效率太高了。期待新版本。

> 并不是引擎的占用，OCR引擎在非活动期间是不占用CPU的。 > > 你看到的应该是前端UI的占用。如果进行过截图OCR等操作，前端正在显示图片的话，就会产生1%~2%的占用。测试如下： > 情景 CPU占用稳定值 > 打开截图标签页，未显示图片 0.3% > 打开截图标签页，正在显示图片 2% > 截图，然后关闭窗口（放到托盘） 0% > 一直放在托盘，进行截图操作 0% > > 未来我可能对图片渲染组件的性能进行优化，但优先级不高。当前，对性能敏感的用户可以： > > * 截图OCR后，手动清空图片（下版本支持） > > *...

可以中英文同时支持么，好多情况都是中英同时存在的。