 |
1
hiddenstar Jan 19, 2013
https://github.com/mbin/12306_ticket_helper
这个东西本来是由于12306的验证码跳过漏洞（已修复）进行自动登陆和自动填表的 不过现在就是自动填好所有表格什么的，只要输个验证码，其他的就是类似于清除无效项美化界面什么的小事情…… 反正相当于一个简化的12306接口……个人看法…… |
 |
2
binux Jan 19, 2013
没有必要研究，任何前端工程师高兴都能写一个。
你也想出名，也写一个呗。 屏蔽是不可能的，最多加个验证码，即使如此，ORC能解决大部分问题。 借擦肩插件操作？这是插件作者和浏览器们的事，不用你操心。 |
 |
4
subpo Jan 19, 2013
现在对猎豹浏览器就是一个字，反感，特别是昨天买通一大堆微博大号转发那个“猎豹浏览器，挺住！”的微博，滥用人的同情心和一堆无脑愤青对国家的恶感
|
|
6
hiddenstar Jan 19, 2013
12306所有的验证码都是斜体字，没有大小变化和扭曲，只有随机的直线和模糊的背景，唯一无法辨识的地方是j有的时候下半部分会被遮住什么的（虽然人类也无法识别……）
OCR判断率应该可以达到90%以上，咳咳…… |
|
7
binux Jan 19, 2013
|
 |
8
Tianpu Jan 19, 2013 via iPhone
真想做成服务，就打码呗
|
 |
9
walkingway Jan 19, 2013
|
 |
10
kaiqiz89 Jan 19, 2013 via Android
之前看报道说经过验证，验证码能做到反ocr的就只有google和reCAPTCHA，但后者又被google收购了……
|
 |
11
Cofyc Jan 19, 2013  1
google 就是用 reCAPTCHA，reCAPTCHA 的图片文字是从电脑出现前的物理书上复印来的，不是算法生成的，没有规律可循，很难编写一套程序识别所有的文字。人来辨识 reCAPTCHA，顺便就将这些书籍数字化了。
|
 |
12
chaos_mical Jan 19, 2013
binux+1，没有必要研究
另外引用最早在raw.github上的问题： “ “12306订票助手”的开发者iccfish(木鱼)在GitHub上解释：他引用了托管在Github上的Javascript代码，不同浏览器又使用了该插件，导致大量请求涌向Github，最终拖慢了服务器。 这里不妨说说具体原因，供开发者参考：GitHub有个未知安全检测，当访问比较频繁的时候，会直接返回403错误。作者就加了一条规则：如果返回的是403，就每5秒重试一次，并且是永久重试。结果GitHub认为用户访问更频繁了，于是一直返回403，最后成了死循环。” 楼主觉得这种处理手法的水平还需要讨论什么吗... |
 |
14
annielong Jan 19, 2013
供开发者参考：GitHub有个未知安全检测，当访问比较频繁的时候，会直接返回403错误。作者就加了一条规则：如果返回的是403，就每5秒重试一次，并且是永久重试。结果GitHub认为用户访问更频繁了，于是一直返回403，最后成了死循环。”
那能怎么处理？设置1分钟后再重试，或者干脆不访问吗？ |
 |
15
shuizhuzi Jan 19, 2013
这个家伙在把GitHub爆库之后把服务器转到了SAE上，结果SAE竟然轻松承受住了，汗啊。
难点就是https服务器，他说他找了半天采用了Github，后来才用了SAE 1L说的挺好 反正任何web应用都是https或http请求，只要细细摸清了请求的路径和参数，编写客户端脚本就可以运行了。 |
|
18
Cofyc Jan 20, 2013
@rqrq reCAPTCHA 都是两张图片成对出现，一张是已知，一张是未知的。校验是否人类输入，只判断已知的那张图，同时记录未知图片的一个人类识别结果。收集数据多了，就能准确地帮助书籍数字化。
|
 |
19
JimmyZ Jan 21, 2013 1
各位一个个对木鱼冷嘲热讽, 可是写点什么放出来给普通人用的, 只有他
|
Select Language