日々私たちが過ごしている日常は、実は、奇迹の連続なのかもしれな。 我们所度过的每个平凡的日常，也许就是连续发生的奇迹。 ——《日常》
能让我过上写代码和看番这样的日常，可能就是连续发生的奇迹吧。
介绍
全功能弹幕播放器，项目逐步推进中…（咕咕咕
架构
为了更方便地维护，引入中间层，用node.js实现代码复用。同时引入插件概念，设计思想类似于typecho中的插件。同时，由于政策受限，iOS客户端将只实现最基本的功能。
设想 & 可能用到的技术栈
- ✅: 完成, 🚧: 施工中, ❌: 未开始
- 🌏: 开源, 🔒: 闭源
Server
🌏 番剧数据库构建
- 总体思路
- Bangumi定时爬虫
- AniDB匹配: https://anidb.net/search/anime/?do.search=1
- 实现思路
- 数据库与工具都会开源
- 不考虑
- https://github.com/bangumi-data/bangumi-data , 原因：人工、延迟、没有特殊番剧
注意：我们会开源两个数据库：
- 最小必要数据库，即所以番剧名称（包括别名、不同语言）与番剧ID匹配的数据库
- 全数据库
由于额外的番剧数据 (全数据库提供) 可以由本地端对 bgm.tv 进行爬取，所以我们也会提供本地端爬取的组件。但是，全数据库仍然是有意义的：
- 更加方便，因为部分 bgm.tv 的数据需要 Cookies (由用户提供)，增加了用户的使用学习成本
- 我们开源在GitHub上的数据库可以提供全球jsDelivr加速
流程框架：
注意：由于AniDB等网站可能会进行流量限制，诸如限制单位时间内访问次数，所以我们需要对数据进行判断、缓存。
🌏 文件hash数据库构建
- 总体思路
- 定时遍历番剧数据库
- 以番剧条目名称作为关键词搜索各大资源站
- 获取文件名与hash值的对应
- 对文件名进行分词，然后算出针对各个番剧的似然 (likelihood)
- 【为什么要这么做？】 举例: 如果用京阿尼的《日常》的罗马音
Nichijou作为关键词搜索，很轻易地便能得到《魔物娘的同居日常》诸如此类的结果，所以我们需要一定的算法来规避类似于这样的问题。
- 【为什么要这么做？】 举例: 如果用京阿尼的《日常》的罗马音
- 对所有计算得到的番剧似然取
argmax归类番剧 - 另外：由于种子长期存在于BT网络上，所以在经历过一次大扫描之后，只需要定时关心资源站内新上传的资源了，不必重复计算。此外，为避免特殊情况，可以考虑对处理过的条目进行记录缓存。
- https://share.dmhy.org
- https://acg.rip
- http://bt.acg.gg
- http://www.kisssub.org
- http://mikanani.me
- http://www.nyaa.si
- 特殊数据
- 琉璃神社 https://www.llss.at/wp/
- 直接爬取上面的hash值，随后进行文件名匹配
- 实现思路
- Python
- node.js
- 数据库与工具都会开源
- 参考工具：
🌏 网站, 信息通知服务
- 总体思路: 做/使用一套完善的信息发布工具
- 实现思路
- 现有博客框架
- GitHub Pages?
🌏 信息聚合数据库构建
- 总体思路: 现有平台抓取
- 实现思路
- Python
- Go
🌏 与视频网站链接的数据库构建
- 待定
- 精确到介绍页的数据：https://github.com/bangumi-data/bangumi-data
- 通过搜索进行定位
- 插件服务：传入参数可以为番剧名称
Web Server / API
- 涵盖内容
- 🌏 番剧识别服务: 借助文件hash数据库实现
- 🌏 私有弹幕池服务
- 🌏 用户服务 (追番管理与bgm.tv同步)
- 🔒 用户贡献番剧与其他网站链接的服务
- 我们提倡开源思想，所以这个数据库将会开源
- 🌏 信息、通知服务
- 🌏 推荐、时间表, 等其他信息聚合服务
- 实现思路
- Go
- Python, Django / Flask / FastAPI
- rust (好像是人类之光)
🌏 网页
- 目标: 提供网页端的API服务
- 实现思路
- Vue
- 前后端分离
