#1 - 2019-6-12 12:22
魔法使
----------------编辑于2019年7月1日---------------------
现在项目已经开工了(开工有几天了),项目地址

姑且简单介绍下现在干了啥和设计思路吧:
1. 将网页数据结构化,即输入参数为班固米网页URI,返回的是结构化的数据
2. 提供同步、异步接口,方便后续开发
3. 利用sqlite构建了一个本地的数据库,缓存已访问过的网页

接口形式:
Alice->GetParsedContentSync(“https://bgm.tv/subject/282395”,CachePolicy::FIRST_FROM_CACHE)

Alice->GetParsedContentAsync(“https://bgm.tv/subject/282395”,CachePolicy::FIRST_FROM_CACHE, Callback_proc)


现在还在苦逼结构化网页数据中...................详情请访问源代码


----------------编辑于2019年6月15日---------------------
目前计划是采用C++写,内含Boost.Asio网络库,数据库采用 sqlite

数据库做内容的cache和版本控制。
1.   内容cache : 在bgm服务器不稳定时提供内容cache,但是需要曾经访问过。
2.   版本控制:bgm的wiki有更新的情况时,可以索引旧版本,包括cv的证件照、staff表、diff等。(感觉没什么用)


----------------编辑于2019年6月12日-------------------
鉴于开发热情高涨(马上期末考试完),又不想继续摸鱼下去了,想开一个坑,构建一个标准化的Bangumi开发库,我认为它应该包括以下内容:

1. 可被引用性
       一个标准化的开发库,它应当是可以被引用到各种应用程序中的。
2. 跨平台性
       该库应该有各个平台的实现,以便让不同平台的应用程序能够直接接入。
3. 稳定性与异步性
       该库除稳定外,还应当提供内构的异步网络访问系统,防止主线程等待,降低在该库基础上开发新应用软件的难度。
4.  拥有足够的功能
       鉴于目前官方API的功能有限,可能的话,该库应当是基于爬虫的,这样才能提供足够的功能接入。
5.  可扩展且功能可自定的
        不同情况下需要使用到的功能不一定相同,该开发库应当可自行修改、删除或添加编译模块,以满足足够的可自订性。

想起再加........有什么问题可以在下方留言(bgm24)
#2 - 2019-6-12 12:31
(hhh汝视视汝)
各平台会很多... 也许可以从爬好的内容 as a (http) service开始
#2-1 - 2019-6-12 12:40
魔法使
嗯,那最初的开发应当从哪个平台入手呢?我现在有点想用C++来写,Python的话感觉不方便嵌入其他项目,也有考虑用Java,但是就是纯粹面向Android平台了
#3 - 2019-6-12 12:40
有结构化bangumi网页数据的打算吗(bgm38)
#3-1 - 2019-6-12 12:41
魔法使
parse只是第一步,更多的是作为interface
#4 - 2019-6-12 12:40
(天生万物以养人,人无一物以报天)
跨平台很难搞啊,难道说的是js吗(bgm38)

搞一个爬虫提供http api感觉是相对来说最好的选择
#4-1 - 2019-6-12 12:43
魔法使
跨平台的话,感觉上应当是代码移植性的问题,如果使用POSIX规范的话,PC平台应该是没问题的,Android好像也支持引入C++和.so库,具体还没查相关资料。

还有就是iOS平台的问题,嘛,就是想大家集思广益下,看看怎么做最方便
#4-2 - 2019-6-12 12:45
魔法使
http api的话也应该是一个比较好的解决方案
#4-3 - 2019-6-12 12:46
bangumi大西王
永夜的魔法使 说: 跨平台的话,感觉上应当是代码移植性的问题,如果使用POSIX规范的话,PC平台应该是没问题的,Android好像也支持引入C++和.so库,具体还没查相关资料。

还有就是iOS平台的问题,嘛,就是想...
我觉得大部分bgm开发者都不会用到c或者c++来写个跟bgm相关的东西,虽然写出来可以轻松的绑定到各种语言…

nodejs和Python也支持c扩展
#4-4 - 2019-6-12 12:53
魔法使
Trim21 说: 我觉得大部分bgm开发者都不会用到c或者c++来写个跟bgm相关的东西,虽然写出来可以轻松的绑定到各种语言…

nodejs和Python也支持c扩展
嗯,暂时想法就是基于C/C++核心,然后套一层皮,扩展到别的编程语言上。此外还可以提供HTTP API或者RPC之类的
#5 - 2019-6-12 13:02
(✨️make bangumi great again✨️)
API就够了 问题是谁提供服务器 parse的cookie也不好搞
#5-1 - 2019-6-12 13:06
bangumi大西王
众筹(
我现在就有几台机子闲置可以拿出来用…
#5-2 - 2019-6-12 13:15
astrea
最理想的应该是API+本地的库,只有API的问题是bangumi有rate limit(虽然有野路子绕过)+额外一层到第三方服务器的延迟,只有本地库的问题是parse网页必然是不稳定的,假如本地的库出问题了能有一个作为fall back的在线API,丢一个html过去解析一个parse好的数据回来
#5-3 - 2019-6-12 13:35
魔法使
astrea 说: 最理想的应该是API+本地的库,只有API的问题是bangumi有rate limit(虽然有野路子绕过)+额外一层到第三方服务器的延迟,只有本地库的问题是parse网页必然是不稳定的,假如本地的库出...
有点意思
#6 - 2019-6-12 13:05
(プリキュアなりたい)
后排支持(
#7 - 2019-6-12 14:05
所以其实如果 sai 老板能来把 api 再完善一下就没有这么多事了
#7-1 - 2019-6-12 14:07
魔法使
HTTP API完善了,在写程序的时候还不是要wrap一次(bgm38),可能的话做成编程语言的native interface形式,直接调用,方便直接。
#7-2 - 2019-6-12 14:27
ouoω
能直接读DB是最好的,从html parse时总有种亏了感
#7-3 - 2019-6-12 20:12
魔法使
rnono 说: 能直接读DB是最好的,从html parse时总有种亏了感
如果做成班固米的镜像DB站的话,条目有更新肯定没法动态获取,只能爬全站,感觉赛姐姐会生气,这小霸王服务器想必也承受不了。
#7-4 - 2019-6-12 20:22
ouoω
永夜的魔法使 说: 如果做成班固米的镜像DB站的话,条目有更新肯定没法动态获取,只能爬全站,感觉赛姐姐会生气,这小霸王服务器想必也承受不了。
可以cache嘛, 對最終用戶不是大問題
#7-5 - 2019-6-12 20:23
bangumi大西王
永夜的魔法使 说: 如果做成班固米的镜像DB站的话,条目有更新肯定没法动态获取,只能爬全站,感觉赛姐姐会生气,这小霸王服务器想必也承受不了。
做成镜像DB站,然后把数据库放在公网上给人连吗(bgm38)

从客户端或者其他第四方网站来说,感觉调用http api要比多一个数据库需要自己来链接要方便多了吧
#7-6 - 2019-6-12 20:38
魔法使
rnono 说: 可以cache嘛, 對最終用戶不是大問題
做一个本地的缓存系统么?工程量感觉又增加了
#7-7 - 2019-6-12 20:40
魔法使
Trim21 说: 做成镜像DB站,然后把数据库放在公网上给人连吗

从客户端或者其他第四方网站来说,感觉调用http api要比多一个数据库需要自己来链接要方便多了吧
数据库服务也可以用http api提供啊🌚
#8 - 2019-6-30 22:28
爬了一遍登录,不知道有没有用
https://gist.github.com/ekibun/67812f5e5f911c6870ea4afab1cbc575
#8-1 - 2019-7-1 11:12
咕咕子❶
吼啊
#8-2 - 2019-7-7 02:52
astrea
参考了一下,谢谢~(让用户浏览器登录然后拿cookie和token的方式问题太多了,最终还是决定转用户名密码登陆)
#8-3 - 2019-7-7 07:31
ekibun
astrea 说: 参考了一下,谢谢~(让用户浏览器登陆然后拿cookie和token的方式问题太多了,最终还是决定转用户名密码登陆)
但是这样没做的页面就能带cookie访问了hhhh
单纯拿cookie算token就好了
#8-4 - 2019-7-7 08:12
astrea
ekibun 说: 但是这样没做的页面就能带cookie访问了hhhh
单纯拿cookie算token就好了
我担心带cookie访问会导致有人不小心点到退出登录所以就没做带cookie访问,oauth相关的几个功能懒得再爬网页改了所以还是暂时同时维护两套吧
我遇到的几个问题是:
1. 验证码输入错误之后的体验非常糟糕(验证码偶尔不自动刷新需要手动点击刷新,输错验证码再退回需要重新输密码),把验证码拿回来再让用户输可以有更好的掌控权
2. 目前是采取oauth授权同时从浏览器拿chii_auth的方式进行登录,然后不知道是不是因为不同的机型自带浏览器不同的原因,有时候就算用户登录了也拿不到chii_auth,或者第一次拿不到再来一次就可以了
3. oauth登录界面如果加载比较慢这时快速点击几下登录会被转到首页而不是oauth授权界面,导致后续处理变得非常麻烦
4. 因为登录界面要加载网页卡太久所以没过审
不过直接输用户名密码应该会有人有所顾及不愿意输吧...
#9 - 2019-7-1 12:54
(プリキュアなりたい)
有大佬试试graphQL吗(
#9-1 - 2019-7-1 13:10
魔法使
这看上去也太强了吧
#10 - 2019-7-1 18:05
有点厉害,后排支持