结合你的需求,建议用楼上说的第二种形式.代码上看起来麻烦一点.逻辑也有点绕,不过最适合你的情况.
当然,你用的就是第一种形式.所以针对你这种形式产生的问题,以下回答:
逻辑代码当然是放进 run()里,不然多线程的意义在哪.
用继承的方式实现线程,有一点要特别注意,你的子类 Thread 除了 run()里的代码是跑在新线程里.其它的信号槽都是在父线程里的.这个逻辑上的区别不知道怎么解释给萌新听,结果就是很多时候程序没有按照你想的方式运行.
引用官方对这继承方式的警告:It is important to remember that a QThread instance lives in the old thread that instantiated it, not in the new thread that calls run(). This means that all of QThread's queued slots will execute in the old thread. Thus, a developer who wishes to invoke slots in the new thread must use the worker-object approach; new slots should not be implemented directly into a subclassed QThread.

变量问题,不懂你的疑问点在哪.如果这些变量是专属于某个硬件的,那么放进这个类里.如果是十几个硬件共享的数据,那么放进一个全局单例中共享访问.记得加锁.

@Gimini 现在可以提 issues 给我哦.

@harry890829 开源了哦.

有地址吗,有机会可以做一点贡献!

顶一下.竟然有原生的 api,果然我微软大法好.
ps:我也做了个答题的辅助工具,高峰期 baidu 会过 5.6s 才返回结果,很不满意.这样一下 Ocr 的效率可以提高到极限啦.

@silencefent 哈?现在还有人在用 32 位的系统吗...大意了啊.

@xiqingongzi 能量球的好处在于程序"总在最前",这样可以在工作中无缝识别.丑...不是现在要考虑的问题啦.哈哈...你说的拖到图标上我也会做的.

@ORZRRR 没有哦.无论哪一家,都有 N 种接口开放出来.针对不同场景有不同的接口.比如身份证,车牌,驾照等.我用的也只是百度的通用图片识别接口,也就意味着针对身份证,驾照这种特殊场景是没有优化过的.我用百度仅仅是先搜了他家的资料.就直接用了...
哈哈貌似有点随意啥.我倒是想比较 google 的,但是要我输信用卡啊啥的,懒得弄了.

@xiqingongzi
嗯.拖文件到图标上来这个,我觉得不如做个类似 360 的能量球的东西.不用时吸在屏幕边上,用的时候直接把图片拖到球上.不过这个就跟现在的也差不多了.只不过现在是一张图片.
anyway,我会试试看的.

@xiqingongzi
嗯.关于快捷键,我有考虑监听全局快捷捷,比如 ctrl+s+y,按下后我直接后台判断当前剪切板的内容是否是图片,如果是的话直接调 api 解析一次,然后把结果放回到剪切板.(顺便弹一个系统通知出来)
默认输入文件的识别是指什么意思,没有很明白.当前版本拖图片进去时会判断格式是否正确的.如果不是正确的格式,拖到程序上会变成一个红色的禁止符号.
感谢你的意见.

@hester 谢谢你的回复.在你说这段话之前,我还真没意识到要区分产品或是 Demo.所以在读了你这段话之后,我可以确定,我做的就是一个 Demo.唔,大概我正文里提到的"小玩具"一词可以作些许旁证吧.
至于长期维护与 github.我个人只在 github 上放源码.如果只是 exe.就算了.我的想法是这只是一个小玩具.可能过了两天,我的这个程序就只能在我的硬盘里找到曾经存在的证明了.
不过正如我回复另一个朋友的话,如果真的有人喜欢,愿意一直的给我提意见,那我非常愿意继续维护和改进,并且开放源码.毕竟整个程序核心还是调用在线的 api(还是人家给的免费额度,嘿嘿).当前的话,我的程序的反馈途径只有这个帖子和我程序里的邮箱了.
我以前是做服务端程序的.写界面算是个新手.我的初衷是练个手.
至于蹭热度,只是随口说的.
我有想法写这个程序,是在 13 天前.刚好回复过 iText 作者的某个帖子(不知道别人能不能看到我的回帖记录,可以去看看),看到有人问有没有 windows 版.在那之后几天就写了这个程序.
然后昨天和今天发现大家都在讨论这个事.我就随手把我的程序分享出来了.
无所谓认同或者其它的.就图个热闹.

@jucelin 啊.我没参考.自己乱想了一个需求然后就写了.你的程序给我看看.让我参考一下.

@harry890829 哈.这个本身没有任何技术含量.乱写的代码.就先不开源了吧.如果后期有大家的反馈做得完善一点了我再开源.没别的意思.现在的代码没法看.唔...我的高手人设不能崩.

哈哈,我也凑个热闹.我也是看到那个 iText 之后自己也写了一个.Windows 版的.
免费使用.
https://pan.baidu.com/s/1pLJtyrh

我为什么这么空....伤脑筋啊...

@quietjosen utf-8 是一种编码规范,实际上它是可变长的,并不是所谓的每个字符占 2 字节(不是位).而且正如楼上某位说的,utf8 是兼容 ascii 的,也就是说针对'a''A'这种,utf8 也规定只占用一个字节.可能我说这些你会听得一头雾水.
如果有空可以自己了解一下.

至于你说的猜测,我也有几个猜测.
1.你以为的 3MB 个字符其实并不是真的 3MB,实际的字节数已经超过 4MB,你可以看下你的 context-length 上标识的是多少.
2.如返回值所说,你传的图片的尺寸真的超出 15px*4096px 限制.
3.你传的数据在某个过程中被截断了.可能是你这边,也可能是在服务器那边,错误的数据导致了百度解析图片出错,而服务端的返回值延用了尺寸不对的错误码.本质上是数据解析(读取图片)出错.

@keenwon 是摘要算法.可以理解一个 md5 是一篇文章的中心思想.
加密成立的前提在我看来是可以解密,但是我们显然无法从中心思想反推全文,所以不算.

另外,多一次 base64 编码在麻烦程度上来说,对谁都没有好处.服务器在拿到你 base64 的数据后,必然是要做一次反编码来获取真实数据的.只是 base64 可以归一化所有的二进制数据到 ascii 码上,从而变成更通用的 string.