2014年抢票总结

2014年的抢票捡漏工作已经结束,现对这段时间以来的付出和收获进行总结。过程记录:http://www.cnblogs.com/liweis/p/4150354.html

  • 黄牛与普通人对比

黄牛的工作流程:在极好的网络环境和硬件配置下,利用准备的身份证号,使用专门软件购买大量的车票。一旦QQ群里有订单需求,就退票再刷给相应的乘车人。

网络环境:大多数普通人都是使用10M宽带,甚至更低;而黄牛都是使用的100M光纤;我在上班的时候网速还行,但在外还是蹭的别人的网,网速不稳定。

硬件配置:普通人多是使用的工作电脑或PC电脑,配置一般;而黄牛是专人配置的服务器级的设置,成本上万;我还是2011年买的笔记本为主。

身份证号:普通人基本都只有一个账号(一个账号同时只能提交一个订单);黄牛预先在网上买了大量身份证号信息(基本是5毛一个号),同时注册了多个账号;我为了帮多个人刷票,也利用一些身份证号注册了5个账号。

专门软件:普通人可能会去官网或用一些浏览器插件;黄牛有专门的程序员,订做软件,速度是极快的,突破5秒刷新限制(有黄牛在,普通人一般是买不到票的);我主要使用的低价的心蓝(绑定注册码版30元,加密狗版70元)和木鱼的免费的12306订票助手。

订单需求:普通人多是帮亲朋好友买些票,需求量10张左右;黄牛的需求是无止境的,市场也是有的,基本来源是QQ群等;我也只是帮自己的家人,朋友,朋友的家人抢些票,50张左右。

  • 打击黄牛的策略

国家体系上,如果发现黄牛的非法行为,判刑?他只是违反治安管理的行为,通常不会触犯刑法,因为没有营业许可证,最多算非法营业;罚款?黄牛挣那么多黑钱,也不怕你罚,人家只当拿钱消灾;最好的方法是与信用体系挂钩,一旦黄牛行为被查明或举报,将与借贷、担保、抵押、保险等相关,提高他们的风险性。

软件系统上,12306系统需要改正一些漏洞,比如验证码本来是针对黄牛软件的,可现在对黄牛软件无效(自动识别能力极高),反而变向针对了大众,所以,要么更换验证码方式,要么干脆取消。至于其他方面的问题,我作为外行人也不敢发表过多见解。

购票制度上,制度不改,根本不可能解决黄牛问题。今年提前60天实质上是助黄牛一臂之力,一方面,12306有更多的退票收入;另一方面,黄牛党也牟取了暴利。我们不排除12306与黄牛合作的嫌疑,有传统黄牛依然可以内部拿票。有很多可行的细节问题需要改变,如付款时间45分钟过长,预售期太长,退票需要本人持身份证去车站办理,12306账户与银行卡账户绑定,拉黑大量购票的用户(团体票除外),同一个IP限制登录账户数及限制查询间隔等。

当然,出现黄牛的根本原因是供不应求的市场,这是难以改变的。

  • 关于抢票的技巧

下面是心蓝总结的抢票技巧,分享给大家。

预售票抢票技巧

A、了解放票时间。

电话和网络预售票从12月7日起改为60天(即打开订票助手后默认的出发日期,其中学生票预售期会提前,请点击"更多查询设罝"中的"我是学生"后再查询),12月7日开始发售2015年舂运第一天(2015年2月4日)的车票,窗口站台则错后两天起售。目前每天起售时间点有21个,即8:00至18:00期间,每个整点和半点均有新票起售。同时C、D、G字头列车不再单独起售,起售时间与车站保持一致。每个站点的起售时间不同,在助手的出发地输入站点后,后面显示的数字即代表该站的起售时间。您也可以在"帮助"-"各地互联网起售时间"中查看您即将购票的站点的起售时间。记住时间,别9点起售的票,您11点半才来预定,那可能早被人抢光了。同时提醒大家,12306官网的服务时间为7点到23点,所以早上7点其实也算是一个起售点。为了能赶在12306开门后第一时间购票,可尝试电脑不关机,这样助手一直保持登录状态,7点整即可马上查询提交订单,快人一步。

B、    做好充分准备。

建议大家提前半小时(高峰期可再提前)登录好订票助手.在"更多查询设置"中设置好您需要的车次席位等购票需求,左边下方的"乘客信息"选择好(目前12306规定身份证乘客必须状态是"已通过",如待核验状态请前往火车票售票窗口当面核验)。提醒大家订票助手同一个12306账户可以登录三个窗口,即打开三次,登录三次,配合多站点多日期提高订票的成功率。建议订票前退出电脑右下脚的一些无关紧要的程序,以加快电脑的响应速度。

C、    细节决定成败。

订票助手说起来简单,概括为登录-查询-预订-提交四个步骤。每个操作,助手右下脚的日志记录都有显示以便用户了解情况和总结经验。每个人掌握的技巧不同,订票的效果也不同。如12306的查询结果不是实时的,各个服务器都具有一定的缓存。如10点放票可能您10点过10秒才查询到出票,也有可能显示有3张余票,可提交又返回说"没有足够的票"。因此建议大家对于明确放票时间的购票,如购买预售票,点击"自动查询"后,"开始查询时间"设置一个靠近真实出票时间的时间,然后下面打上"查询到有票后自动预定和提交"(第二个勾视自身需求决定)。对于错过了放票点的票,如刷退票则无需设罝开始查询时间,直接确定开始查询即可。再比如,刚才说过可以开三个窗口多站点多曰期轮查,那么您可以在出发地添加比如北京南,北京北,北京西这样三个站名不同但查询结果相同的站点,这样做可以让您减小缓存,更快地查询到余票信息。穷则变,变则通,更多细节,大家各自发挥总结,在此不再一一列举。

刷退票回笼票技巧

如果您错过了60天预售起售点抢票的最佳时间点,也请您保持淡定。坚信一点:预售60天,如此之漫长,总会有人改签退票的,以及一些内部预留的票会放出来。所以保持良好心态,别以为预售没买到就没有希望了。当然刷退票要有耐心,也要有技巧。一天刷不上,明天继续刷;刷不到3号,就刷4号,或者5号三天一起刷。刷不到杭州,就刷杭州前后的如义乌,上海等;一些小站票少,可以刷就近的大站,这样退票的几率更高。总之灵活变通,总会刷到您回家的票。这里给大家提_几点:

A、    助手"更多查询设置"中的购票需求筛选设置具有排上优先的原则,查询结果中有满足您设罝的需求时就会显示蓝色表示可以预定,否则灰色表示不可预定。如您最想要硬卧,没有硬卧硬座也行。此时您就把硬卧,硬座打上,同时硬卧上移到硬座上面。这样如果同时查询到有硬卧和硬座的退票,助手会给您优先提交硬卧。提交后如果返回"没有足够的票",则会自动给您提交硬座。默认席位类型优先于车次类型,也就是先按您设置的第一个席位(如硬卧)去车次类型中可预定的车次按优先原则逐个去提交,不成功再用第二个席位(如硬座)去按刚才的顺序提交。如您要改成车次类型优先于席位类型,请点击旁边的绿色箭头进行切换。

B、    比如您有5个人想一起走,可票非常紧张,不得不拆散,那么"自动查询"里的第二个选项"余票不足时允许部分预定提交"即表示如果只有3张退票,那么就会自动给您提交3个人的预定。对于热门火车票资源紧张,可能同时有多个人在刷和您同样的退票,因此建议能刷到一个是一个,逐个解决。否则出来5张票,可能某人在那出票的瞬间刷成功了2张,剩下只有3张了,而您一直在提交5张,自然是"没有足够的票"。而此时如果有人提交的是3张,那么他成功了,而您却又错 过了。

C、    目前12306取消订单及退票改签后的票具体何时返回再次销售时间不定,且12306的查询不是实时的。因此刷退票是一 个任重而道远的工作,需要足够的耐心和信心及人品运气,请您保持良好心态。当然网速越好,电脑配置越高,刷到的成 功几率就越大。毕竟"僧多肉少",几毫秒的差距就可能决定了"花落谁家"。

D、    如果担心票源紧张,可先购买支付一张无座或硬座作为后备,再点右上角"我的火车票"已支付订单"中进行改签。 如"席位类型"中只选硬卧,然后自动查询。这样一旦有硬卧退票,就会给您提交硬卧了。如果提交成功为硬卧的上铺,而您又想要上铺,则可让它45分钟付款超时过期后,再次自动查询改签。重复上述步骤,直到成功订到硬卧下铺为止。同 时提醒您:对开车前15天(不含)以上退票的,不收职退票费;在其他列车有余票时,可以改签发到城市相同的车票。具 体是,开车前48小时(不含)以上,可改签预售期内的其他列车;开车前48小时以内,可改签开车前的其他列车,也可改 签开车后至票面曰期当曰24:00之间的其他列车,不办理票面曰期次曰及以后的改签;开车之后,旅客仍可改签当曰其他列 车,但只能在票面发站办理改签;改签后的车票乘车曰期在舂运期间(2015年春运期间为2月4曰至3月15曰)的,退票时 一律按开车时间前不足24小时标准核收退票费。(即开车前48小时外退票的,只收取5%手续费;48-24小时内的,收取 10%的手续费;而不足24小时的,则收取20%的手续费。)

E、    还是那句老话:坚持就是胜利。只要您坚持,一般来说零散的几张票肯定是99%没问题。建议在"文件->选项 "成功提醒邮箱填写个订票成功的提醒邮箱,如139、186等免费手机邮箱(可免费手机短信通知),或QQ邮箱(微信 中绑定则可实现微信提酲),以免不在电脑边上时错过45分钟的付款朗。同时希望大家手机上都安装一个12306官网的手 机版APP,高端大气上档次,随时随地都可以查询预定及支付火车票。

时间: 2024-10-12 16:53:44

2014年抢票总结的相关文章

“开发数据无线潜能”友盟年末战略发布会开始抢票了!

来自友盟的最新数据:中国活跃智能设备已经超过9亿,国内通过4G联网的启动次数比2014年初增长了30倍--可以想象,这些数字的背后,是海量的真实用户,他们或是游戏控.或是动漫迷.90后.社交达人- 在这个庞大的移动互联网生态里,开发者对用户数据的需求,不再停留在"数量"层面的统计,他们更想知道的是"这些用户从哪里来?是应用的核心用户吗?他们深层的喜好和需求是什么--",友盟希望通过回答这些问题与从业者一起将应用数据的价值发挥到最大化. 作为中国最大的移动开发者服务平

火车票抢票API 根据乘客的车次与座席要求快速订票出票

火车票抢票API 根据乘客的车次与座席要求快速订票出票,具体API文档,包括接口地址.参数及返回示例等可参看:https://www.juhe.cn/docs/api/id/257 一.站站查询,根据发车站.到达站.发车日期等条件查询所有符合条件的车次信息.票价.剩余票量等信息 二.创建抢票单,建议先配置回调地址.须知: 1.抢票单仅支持占座和出票合并通知:2.距离发车时间太近无法抢票,建议距离发车前3小时以上的车次才可创建抢票单:3.在抢票有效时间内会持续抢票,抢票成功后直接出票并推送回调: 

离线抢票

现在是2016年12月24日23:21:54,又到了春运抢票的时间. 这次我使用`高铁管家`的离线抢票功能,即先把钱付了,让app帮你抢票. 我发现了几个问题: 你在12306上的所有信息都会被对方获悉,有信息泄密的风险. 手动登录 12306 需要输入验证码,但是如果需要手动输入,那么离线抢票又是怎么做的呢?是不是12306不允许太明显的不输入验证码?还是故意不让用户知道验证码可以由程序识别? 抢票时会默认选择一个30元的保险套餐,规则上解释这个能够调高抢票率.这个是怎么实现的呢?把购买不同套

360自动抢票还不够,几行js代码设置无人值守

360就是牛逼哄哄的...... 但是最近在使用360浏览器抢票的时候还是发现了一些体验不好的地方,比如搞着搞着就退出了登录,有时候能帮你自动登录进去,但是自动登录之后又不会帮你自动开始抢.然后验证码几次失败之后 流程就停住了, 所以必须的有人看守. 由于360浏览器是使用Chrome内核 而且提供了调试功能,所以我们写一小段js让360达到无人值守抢票的目的 setInterval(function () { if ($('.username').html() != undefined &&am

使用Python和Splinter实现12306火车票查询与抢票

有一段时间没有使用Python了,前几天经朋友提起一篇关于用Python实现抢火车票的文章,百度了实现抢火车票的技术细节,网上却有不少资料,也不是新鲜的东西.在了解了一些技术手段,阅读了一些大神的博文后,也尝试实现了一下,代码写得粗糙,纯当娱乐,本文在Windows系统下完成.需要提到的是,抢票过程中的验证码部分只能手动完成. 首先,我需要的工具和组件有: Chrome浏览器 浏览器驱动ChromeDriver Python 3.5 Web应用测试工具Splinter Chrome浏览器可自行下

12306新版抢票之逻辑分析

前言 新版的12306大概是前天上线的吧,因为我前天想抢票的时候发现之前写的程序已经无法正常工作了. 登陆的时候就会报错--"非法请求",很纳闷,莫非是12306改了逻辑? 不过经过这两天的研究,已经又搞出了新版的抢票软件,嘿嘿,感觉值得骄傲一下~好了,不嘚瑟了 下面先从登陆入手,来剖析新版添加的dynamicJs(这个名字还挺贴切,就这么叫了) 一窥新版猫腻 下面就是新版的12306登陆所传的参数 根据我上版抢票软件的经验,其中后三个参数都是新添加的,并且其中用红框框中的那个参数的k

python自动抢票

# -*- coding: utf-8 -*- from splinter.browser import Browser from time import sleep import traceback #初始化信息 # 用户名,密码 username = u"用户名" passwd = u"密码" # cookies值得自己去找 starts = u"杭州,HZH" ends = u"黄石,HSN" # 时间格式2016-03

12306改版之后简单抢票软件的实现(转载)

又到一年抢票时,各种抢票软件的肆虐让12306不堪重负,最近这几天12306频繁的更换手段来阻止抢票软件. 先来吐槽一下红红的验证码,过年的时候都喜欢用红色来喜庆一下,12306也深刻的表达了他的喜悦之情,又红又大的验证码啊,不过到底跨越了几个维度呢?看起来晕晕的,感觉像在时空里穿梭. 科学告诉我们,牛是色盲,分不出来颜色,但是伟大的黄牛们不是,不知道黄牛们看到鲜红的验证码之后会不会疯了一样的撞向显示器?那场面一定非常壮观 很快红色的验证码消失了,但是,在抢票的每一步都加了一个验证,过滤掉抢票软

软件工程(3)微信抢票总结

软工三的这个大作业需要在前人的框架基础上完成一个工程,和之前其他课程相比,有一种小学期的感觉,只不过并没有小学期那么充足的时间. 十一期间比较颓废,ftp几乎什么都没做,直接导致迭代一的大部分时间内在补ftp的坑.好在组长百忙之中熟悉接口并完成了大部分基础功能,迭代一ddl前粗暴地处理完的抢票逻辑再简单测试一下性能似乎也还算是说得过去. 迭代二我的主要任务是(迭代一未能开始的)功能测试和单元测试.课件的内容非常清晰,但开始时写起来并不顺利.在逐渐熟悉组长写的接口的代码的精妙的思想后,在阅读dja