其实在上一篇 「日历记事本」规划 之后不久我就把插件陆陆续续写得差不多了，但是由于懒癌发作一直没有更新博客 QAQ ……
那么目前完成的模组有三个流媒体和一个 coding 时间跟踪工具。
目录
Bilibili
B 站的数据是从他们家的历史记录页面抓取的，从审查元素页面可以看到有如下的请求：
curl 'https://api.bilibili.com/x/v2/history?pn=1&ps=100&jsonp=jsonp'那么返回的数据是一个 json 对象，内含一堆 看不懂 的条目……里面比较重要的其实也就下面这些：
- aid: 就是以前的 av 号
- bvid: B 站后来又搞了个 bv 号，想了想那就拿这个当主键吧
- duration: 这个应该是总长吧
- page: 包含观看分 p 号和观看时间等
- progress: 观看的长度；-1 表示的是看完了
- redirect_link: 链接，其实可以用 av/bv 号生成
- title: 标题
- view_at: 观看时间，是 Unix 时间戳格式的
这边比较复杂的一个问题是有些视频是分 p 的，所以需要考虑到可能看完第 1p 之后看了第 2p 导致有两个条目这样的情况。还有的问题就是 progress 可能是 -1 所以这个时候要用 duration 替代……
不过总的来说 B 站的数据真的是很良心了（全靠同行衬托），下面的两个流媒体网站才是真正的灾难（
Netflix
Netflix 只有精确到天且看完节目的记录，所以只能解析 html 了……
curl 'https://www.netflix.com/viewingactivity'虽然不是 json 格式，所幸数据都在一个 table 里面，还算比较规整，只要拿 scraper 稍微搞搞就可以了。其他应该也没什么坑点，日期用正则表达式 parse 一下就行（
Wakatime
Wakatime 做的还不错，至少有 api 和对应的文档（虽然写得不怎么样……）
curl 'https://wakatime.com/api/v1/users/current/durations?date=YYYY-MM-DD'
curl 'https://wakatime.com/api/v1/users/current/summaries?start=YYYY-MM-DD&end=YYYY-MM-DD&cache=false'有个小问题（其实每个插件都会遇到）是，比如我正在看视频或者进行某个项目，那么如果这个活动持续时间超过了服务器抓取历史记录的间隔市场的话，就会抓取到两份历史记录——但是它们指向的是同一个活动。因此一个修复的小技巧就是过滤掉结束时间太近的那些活动；这样会引入一丢丢延迟，但是总体上来说应该没问题。
Youtube
谷歌简直是业界毒瘤x
curl 'https://myactivity.google.com/activitycontrols/youtube?view=item'Youtube 的历史记录要难搞很多，因为首先它可能会受到时区影响（因为精确到了分钟），其次它“智能”地将同一天观看的内容整合在一起，中间用另一个 div 元素分开，所以还要动点脑筋才能把日期读出来……像观看进度这种东西都是靠缩略图上的进度条读出来的，实在受不了这种奇技淫巧x
目前为止时区的问题还不太能搞定……还是等有时间再修复吧x