说正经的,写这个小程序的起因在于自己提交作品时,不知道是否已经有重复的作品,也没地方去检索。而这次活动的官网 腾讯网和 新华网都只提供登录和一览,只能一页一页翻。特别初期每天都上万的新数据,哪里翻得过来,于是自己想搞个检索和统计的辅助程序。这样有一搭没一搭的搞到现在...马上都快到截至日了...我这效率...
最终完成的辅助程序放在GAE上 —— 嫦三月车辅。因为是appspot,请自备云梯。
截至20日的部分统计信息:
![](http://dl2.iteye.com/upload/attachment/0090/3416/6ce2e8c1-a31d-3145-91df-46eca92b4577.png)
其实这篇博文原打算叫“奋斗记”的,实在是有够折腾的。
- GAE数据存储的配额太低了!Datastore Write Operations 0.05 Million Ops,5万次写。我当时收集到的原始数据就13万,根本就不敢想。整理后的数据倒是只有3万,一试之下,毫无悬念的崩!减半,分两次如何?崩!好吧好吧,减到1万,再来过,崩!不高兴再试了!再少也没什么意义。
- 打算转Google Cloud SQL。必须缴费,作罢。
- 转其他Online DB。急切间没有合适的,最终作罢。
于是放弃存储,一切都On The Fly,全部走内存!话说GAE这点不错,内存倒是足够,不崩!且快!哈。除了每次启动后重新上传数据...
再就是数据,真够劲!
★ 腾讯网 最初从列表页面取,可以一次多条,效率会高,毕竟有十几万(至10月17日)的数据,但是此路不通。一是没有作者,日期等信息,二是名字过长时用...代替。最终改成从详细页面取,十几万的数据,又不敢开多线程(不能去添乱啊),每次都得6,7个小时...
★ 新华网 好些,因为本身就用论坛做的活动页面。加上数据量不大,几万(至10月17日)的数据,每页20楼,半个小时就搞定。但是,新华网的问题是把作者提交的作品和描述等都合并在一处显示,用<br>分割。还自动为每个名称加上“号”字,这处理就比较多余了。因为作者本身就会以“Xx号”命名,于是满眼的”Xxx号号”,我整个人都“号号”了。
★ 最后是作品 真够劲!正常是每人限5件作品,名称和描述分开。无论腾讯还是新华都是有输入框的,名称有名称的输入框,描述有描述的输入框。应该说绝大多数作品都是按规矩来的,但还有那许多的作者“勇于打破条条框框”!
- 名称和描述都写在名称里的。
- 多个名称用标点符号或文字分割写在一次提交里的。这是我处理分隔符的正则表达式。
半角空白|全角空白|,|,|》|《|】|【|、|;|/|/|;|:|:|。|(|)|\"|”|“||\\(|\\)|\\*|&|’|‘|[|]|\\d{1}\\.|简称|或(者){0,1}(叫){0,1}
- 上面这些分割符的用途也各不相同,有的是分割多个名字的,有的是标注读音的,有的则是名称描述的...我选择数据量最大的“分割”来处理。
- 然后是后缀。由于设计上打算去除重复的数据,比如“玉兔”和“玉兔号”或“玉兔号月球车”,这些都算做“玉兔”。但是这些个后缀也太“丰富”了。这是我能分辨后缀的正则表达式。
(((?i)no)*(—|-|·|\\.)*(\\d|一|二|三|I|壹|X|1)*(号|號)*(月球|探月|探测)*(车|器)*)*$
(这么看来恐怕官网得上大量人工处理了吧...)
由于能力有限,太多例外,只能做最简处理。毕竟只是辅助程序,所以一定有好多漏洞。比如哪位的作品叫:“简称”,那么多半会被我的程序滤掉了。