简单剖析学校打卡网页的定位方式

瞎猜

近来，自己时常打不上卡，而因此遭到训斥。究竟是打卡系统的问题还是我自己的问题呢？为彻底地解决这种神奇现象，我对打卡页面展开了全面的PHP代码研究与实验。

绝大多数要求展示地理位置的网页，比如百度，都是读取浏览器中的CDN缓存，然后通过已知位置的CDN推算用户的位置。这个数据通常由IP地址提供。调用方法很简单，用CDN提供商免费开放使用的API接口发起get请求就行：

<script>
function getlocation(obj) {
    console.log("省["+obj.pro+"] 市["+obj.city+"] 区["+obj.region+"]");
}
</script>
<script src="https://***.com?callback=getlocation&ip=****">
</script>

这种方法响应速度极快，且是完全静默的，用户不知道网页在定位自己，因为请求只发给另一个服务端，而不是用户端。实际上，所有带有地理位置信息的推送广告，基本都是使用这种定位方法。

瞎扯

但是，打卡的定位方法却不是这种，而是跳过缓存，通过JavaScript直接向用户发起一个精准位置信息请求，至于这个位置信息具体怎么得来的，完全由用户端决定，它只管收取信息：

window.navigator.geolocation.getCurrentPosition(showPosition);

这个字段将以JSON的格式回传给打卡网页，大致格式是这样的：

{success{纬度、经度}}

当然实际信息组成不止这么简单，通常还有：
position对象的属性，
latitude纬度，
longitude经度，
altitude海拔高度，
accuracy纬度或者经度的精度，
altitudeAccurancy海拔高度的精度，
heading设备前进方向，
speed设备的前进速度…等等。

打卡网页只获取JSON中的两个关键信息，一是注明请求成功与否的标头，二是经纬度数值。

标头有三种，success、error、timeout。error通常由用户设备标明，例如用户没有打开GPS，用户主动拒绝提供位置…等等。timeout通常由服务端自行标明，在不知道用户出了什么毛病，可能是突然断网了，总之就是没反应了，服务端就给用户标一个超时未响应。这两种标头都会直接归类为定位失败，体现在打卡网页上就是“位置获取中”-“定位失败”。仅当检测到success标头时，服务端认为定位成功，然后读取详细经纬度数值。

{error{}}这样肯定是没法打卡了。

重点来了。我当下使用的手机的GPS天线摔坏了，可能松动了，也可能是断了。它在定位时，虽然没有定到位，但是它在系统层面上，自己认为自己定到了。所以它会给打卡页面返回一个带有success标头的空信息。打卡网页读接到信息后，也以为自己拿到了经纬度，但实际上它没拿到。所以，即使页面没有弹窗说定位失败，页面的定位数据也是空值。

{success{}}

进一步地，即使根据这个空的定位信息，页面在本地运行PHP代码的层面上，显示打卡成功，在后台上，它也是没打上的。因为在这个打卡页面里，定位信息是必填项，如果是空值，那么它是无法将表单完整录入后台数据库的。

如果没有急着退出打卡页面，页面会在按下打卡按钮，即提交打卡表单后自动刷新，刷新之后就可以看见今日已打卡的按钮没有变绿，也就是没打卡的效果。退出太快，自然也就无法发觉了。

瞎吹

经过本次探究学习，我掌握了打卡页面的工作逻辑与数据结构。打卡系统没有问题，甚至可以说是编写得相当认真负责的一个系统，问题出在我自己这边（即用户问题）。现在，我不仅可以明确地避免再次出现此类乌龙，还能够自己编写JSON信息，代替系统返回值，任意更改打卡定位。由于本过程是闭环的，所以自动打卡也因此得以完全实现。

解决方案

垃圾1加9，使用不到一年，摄像头，屏幕，振动，GPS，全几把坏了，立刻置入不可回收垃圾桶，更换其他手机用于打卡。

后记

除了上述方法外，还有更复杂的静默定位方法。例如Google、Apple、Microsoft这类国际大厂提供的位置服务，可以通过设备周围WiFi甚至周围联网设备的Mac地址信息，在它们巨大无比的数据库里进行三角测量，得到无比精准的定位。因为太过于精准，所以即使这种方法是静默的，它在被使用时，还是需要事先声明。只有用户知情并且同意了，才能获取位置，否则违反规定。