加入说昨天是因为时间少而没有完成依赖库的安装的话，那么今天是真的花了一整天的时间在安装所谓的百度识别的依赖库，但是环境并不是在vs上，因此是将环境全部转移到qt上安装的，将3个环境安装完成之后（这个时候已经经过了4-5个小时），出现了上百个错误，逐一百度修复了之后，将错误减少至1个无法编译成.o文件的问题，又经过了几个小时搜索相似的案例，发现国外有一例一模一样的例子，可是按照相同的方法之后，.o文件无法生成的错误消失后，转而成为一个...id的错误，这个错误无法消除(经过了无数次的实验之后)，无论如何，都是如此。不断的探索失败之后，已经到了深夜的12点多，因此昨天的博客拖到了今天，然后因为这个从来没有人遇到的问题(至少在百度上找不到相同或相似的案例)无法被解决，只能转换策略，打算转向实现qt对https的支持。之前因为qt4对https不支持，只能通过外部的模块实现对https的支持，因此才没有一开始就想用这个方法实现，然后如果可以实现对https的支持，通过百度ocr的http接口就可以实现这个功能。而且json的问题可以通过自己对字符串的分析得出结果，然后查找了一大堆例子，发现实现qt4对https的支持在众多编程的人员之中成功实现的很少，基于整体分析，这个策略同时被我否定。当时选择qt4开发实际上是一个折中的方法，qt5的软件带上动态库至少都有20M大小，即使经过压缩之后还有10M的大小，所以在一开始编辑软件的时候，既然想法是写一个小工具的集合，那么这个程序就不能太大，因此选择了支持相对较少的qt4编写程序。在否认这个策略的同时，继续转换思路，既然调用外部ocr无法实现，那自己编写ocr如何，搜索案例发现自己编写ocr需要增加很多模块，因此这个方案同时被否认。继而继续转换思路...
计划今天（因为已经在凌晨）对该工程转换成可解的问题，在前几天的探索过程之中，虽然像是啥都没有写成，实际上已经对调用所需要的依赖库有了逐渐的积累。在读过之前那本人月神话之后，我发现了现在遇到的这个问题和书中的案例有相似之处，看起来很简单的问题，实际上是一个深不见底的深渊。基于10天开发的时间，我决定更改我之前的计划，即在完成这个截图识字的功能之后在完成其他功能的计划进行调整。把这个深不见底的深渊工程调至最后