有一套免费且漂亮的源码。
不知道谁放网上的。
版本号还按最新版写的，但是安装完了你看不到到底是什么版的。
几天前我费了点周折把它安装上线。
然后发现其中有一部分采集功能隐约是不可用的。
真的是隐约。
感觉还有救。
不想放弃。
毕竟这个采集的可用的是某宝的API，光明正大，不至于偷偷摸摸吧？
按照该公司的说明关注了公众号，拿到了采集功能所需的KEY（不是某宝的KEY）。
OK，进到相关采集页面，默认采30页，1页、2页、3页……最后毛都没有。
好吧，没报错，没说不能采，那么应该是可以的。
过了几天，我也知道写这套源码的公司不想免费了，不维护免费版了，但是由于网上的人说新版安装完的版本号和旧版一样，所以我也心存侥幸，想看看是不是运气不错，还能用。
今天晚上就专门来修理这采集模块。
首先看到了一个奇怪的错误， Illegal mix of collations (gbk_chinese_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE)
研究了半天，无非就是编码不一至的问题。
为什么编码不一致的，因为为了避免重复入库，采集程序拿新采回来的数据去Like库里的数据，如果是一样的，就不入库了。
这个好啊，但是由于新采的数据可能是gbk的，而库里的字符是utf8的，所以就出问题了。
当然这是我的分析，实际情况复杂得多，mysql默认的collation是utf8，但有两个变量死都是latin，set几次一重启就回来了。
而这个数据库当初安装的sql脚本设置的字符默认是gbk，但是实际上因为我安装时的设置，把它弄成了utf8，具体到出错的表，它的collation又是gbk。
我一怒之下，把所有能设成gbk的都设了，但是历史数据是不能改的。
然后在mysql_query方法执行前加入了set names gbk。
结果是页面上全是乱码。
好吧，我改成set names utf8。
然后把报错的那两个字段的排序改成utf8，其他不变。
结果呢，页面显示是不出错了，但是那个mix错误还在，因为每次Like的时候还是会遇到gbk。
于是我找到like前的准备语句，用iconv方法把字符串先转成utf8再说。
结果呢，mix问题不存在了。
但又遇到了Warning: Illegal string offset问题，网上的人说是因为数组为空，好吧，我做一下检查，如果数据为空就不入库。
结果发现没用，因为入库的数组本身并不是空的，只是数组没有内容。
嗯，好坑啊。
所以我决心把整个代码都给看一下，梳理一下采集的流程，找到错误最开始的地方。
可我没有在本地安装开发环境，完全是在线上调试的。
线上嘛，你只能看到一部分的错误，有些东西你是看不到的，因为有些错误被程序给处理掉了。
最后找到采集列表的部分，把curl拿到的原始数据写到一个文本文件上（没有专门的写日志语句只好自己撸fsopen了），结果很顺利，得到了一个很短的json：
{“state”:”0″,”msg”:”\u514d\u8d39\u7248\u4f18\u60e0\u5238\u670d\u52a1\u5668\u5df2\u5173\u505c\uff01″}
然后把这玩意用js的decodeURIComponent一处理，结果如下：
{“state”:”0″,”msg”:”免费版优惠券服务器已关停！”}
真是心都凉了。
其实我一开始是把那个采集目标页访问过了的，明明可以访问，我就不明白怎么用浏览器可以，用curl就不行，难道非要我假装成浏览器才行吗？
不过代码也没仔细看完，估计并不是直接用原始URL，可能是什么API的URL吧。
算了，暂时不理会了。
这件事情最神奇的是：刚装完这套代码的时候，遇到有些页面报fatal错误，说找不到class，我一开始眼尖，发现代码里有时候大写有时候小写，大小写和文件名还不一致，比如有个Page.php文件是大写开头的， 结果代码里一会儿大写一会小写，所以我以为是大小写问题，冲这个问题想了好多办法。结果发现根本不是。
后来我下载了“另一个”版本的源码，覆盖了文件之后问题自动就好了！
其实真不是大小写问题。
因为今天又出了这个问题。
我认真搜索一下，有人说这是命名空间的问题，因为同样用这个类来实例化，有时候他们写成new etc\framework\page，有时候写成new etc\framework\page().
其实我以前没想过php还可以这么干，直接写个路径在这里new？原来这个就是命名空间的效果。
当我以为完全是命名空间的锅的时候，发现问题的触发因素了：
一搞数据库，页面就出这个问题。
特别是测试采集报错的时候，随机性地出现甲乙丙丁不同的页面报fatal错误，同一个页面，一会儿正常，一会儿说找不到。
不搞采集，直接开着phpmyadmin，也会出现这个事情，一关掉一重新登录，一切又正常了。
真的是神奇的代码。
为了这么一个不是问题的烂问题，我竟然花了一个晚上！
影影绰绰学了不少东西，实际上屁用也没有，就是增长了点知识和经验，下次遇到类似的问题，只能说可以加速破案吧。
还是本地装个开发环境来得合适，目前这样搞，简直是要死人。只差没建个“日志”表直接把数据写到数据库里去了。
哦，对了，今天还玩了一堆插件的源码，帮它们改BUG。也是醉了。
