关于点击了打卡提交按钮

前言

首先我想先铺垫一点点基本概念。网上的信息都是经过了『网络』这个转播媒介，计算机网络讲的就是这部分（物理层->数据链路层->网络层(IP)->运输层(TCP\UDP)->应用层(DNS\HTTP\FTP\SMTP)）。对于我们用户来说我们直接使用的就是应用层之上的服务。

常见的就是 HTTP（Hypertext Transfer Protocol，超文本传输协议），我们使用浏览器访问页面就会发送非常多的 HTTP 请求，发送了请求获取到数据 HTTP 的活就干完了，接下来就是浏览器将数据展示出来。DNS（Domain Name System，域名系统） 就是域名解析，根据你的域名解析 IP 地址（为了让用户更好的记住网站地址，而不是让用户去记 IP 地址）。 FTP（File Transfer Protocol）用于文件传输，SMTP（Simple Mail Transfer Protocol） 用于邮箱服务等等。

用户通过应用层的这些协议来获取数据，那么这些数据在哪里呢，答案就是在这个世界上的某台计算机的数据库里面放着。数据库分为关系型数据库(MySQL、Oracle)、非关系型数据库(Redis)…一般存储用户数据都是用的关系型数据库类似于 excel 表，可以理解为为什么每次没打卡的信息导出的都是 excel 表格（而且每次没打卡的都是那么几个人（bushi））。

知道怎么获取数据，和数据怎么存的我们就能开始回答这个问题了。

点击前

为了更好的回答这个问题，我还是想说说点击前发生了什么事情，也就是我们点击首页健康打卡图标进入到打卡界面这一段时间。

发送了非常多的 HTTP 请求。有的用来获取选项有哪些（为什么会发送呢，因为如果写在软件里面了，那下次修改模板的时候只能通过发放新版本来更新，而通过 HTTP 我只需要修改数据库你获取得就是不一样的）；有的用来获取你上一次的打卡数据（现在很多学校通知取消回显功能，那么这个请求可能就返回不了什么有用的数据了）；有的用来获取你的个人信息（学院、班级、姓名等等）；有的用来获取你当前的位置（就是你当前的地址，请求的是百度的 Web API）。（Web API（application programming interface，应用程序接口）可以理解为一次特定 HTTP 请求的姿势，定义了传过去什么数据，返回来什么数据）

发送了上面那么多 HTTP 请求才会展示给你打卡界面。此时你需要慢慢填写你的打卡信息了。

点击后

终于在此刻（00:01），你眼睛都不眨得一下一口气填完了所有的信息，终于要点击提交按钮，准备睡觉了（指熬到零点打卡睡觉）。

首先会做的就是验证你的信息有没有漏填，必填项没填，点击按钮会告诉你哪里没填，不准你提交打卡。必填项也填好了，一切准备就绪，点击提交。程序会收集你所填写的信息组合在一起，组合起来的样子其实就是配置文件 post_json 里面可以填写的样子，这就是为什么往配置文件里面填，能让它自动提交配置文件的数据，你所填写的打卡选项都会被封装到 updateinfo 这个里面，格式大致如下：

{
    "areaStr": "...",
    "customerid": "xxx",
    "deptStr": {
        "deptid": "xxx",
        "text": "xxx"
    },
    "deptid": "xxx",
    "gpsType": 1,
    "phonenum": "xxx",
    "reportdate": "xxx",
    "source": "app",
    "stuNo": "xxx",
    "templateid": "pneumonia",
    "token": "xxx",
    "updatainfo": [
        {
            "propertyname": "sex",
            "value": "男"
        },
        {
            "propertyname": "xxx",
            "value": "xxx"
        }
    ],
    "userid": "xxx",
    "username": "xxx",
    "ver": "xxx"
}

收集好用户信息组合成这样之后就会开始发送 HTTP 请求，发送的就是这一串数据，返回的数据当然就五花八门了（再次说一下 HTTP 请求简单理解为发送数据获取数据，当然有些不会发送数据，它只获取数据）。大致有：areaStr 不能为空、deptid 不能为空、找不到机构模板、打卡频繁、成功、模板不符…这其实是脚本才会大概率报出这样的错误，APP 由于数据处理好了，所以提交只会有成功、频繁。成功了当然就会返回一个页面，一个大大的绿色的✅，下面一行字写着提交成功。看到这个界面基本就安心睡去了。

但是数据提交过去可不能就这么没了，不然老师获取未打卡名单里面还是会有我们，所以数据存在了数据库里面，以看起来是 excel 的形式的关系型数据库，姓名，班级，打卡时间，打卡数据…。

自动打卡是怎么运作的

自动打卡的目的只有一个就是想法设法模拟发送上面这个 HTTP 请求，所以脚本就是在想尽一切办法把这些字段补齐。

token，需要登录获取，所以写了登录的代码，模拟登录发送 HTTP 请求，获取到 token
updateinfo，现在回显功能取消的话，基本是告别了获取上次数据的简单流程，所以不得不在配置文件的 updateinfo 中填写你的那些获取不到信息的打卡数据
其他字段也是发送 HTTP 请求帮助我们获取的，其重点就是我们要去找要去抓包，看 app 是怎么获取的那部分数据（抓包也就是看 APP 发送了哪些 HTTP 请求，我们能用软件捕获到他们，然后我们进行分析，分析它发送了什么数据，又获取到了什么数据，这一次 HTTP 请求是否对我们有用）
推送功能，自动打卡当然不能只有一个悄无声息的 HTTP 请求数据发过去，我们用户需要知道到底发送了什么，成功了没有，错误的话又是怎么个错误原因，都是由推送来推送给我们使用者

总结

数据获取发送通过 HTTP 请求
数据保存在数据库里面（为了就是老师导出未打卡的人员的时候到底有没有我们）
脚本就是在想法设法发送最关键的那一个 HTTP 请求，但是为了这一个又必须发送非常多其他的 HTTP 请求

Writing

关于点击了打卡提交按钮

前言

点击前

点击后

自动打卡是怎么运作的

总结