～技术宅真可怕～#1 - 2022-3-2 03:57
NekoNull
联动 bangumi有一天会关闭么？ 和 Sai 老板的指引，使用 Bangumi API 写了一些 Python 脚本，一个导出数据到 JSON，一个把 JSON 转换成稍微可以读的 HTML。
项目地址：https://github.com/jerrylususu/bangumi-takeout-py
2023/8/2 更新：现已支持 Github Actions，具体使用请参考 README
2022/12/1 更新：备份工具使用量过大，造成 Bangumi 全站缓慢，被 Sai 吐槽了。已经减缓请求频率，备份耗时可能增加。
2022/6/22 更新：欢迎尝试实验性项目 Bangumi Takeout More，现已支持小组讨论、日志、目录导出。
2022/5/24 更新：现已支持增量导出和导出至 CSV。
2022/5/10 更新：因为上游 API (Bangumi API) 的收藏接口出现了一个 Bug，2022/3/6 之后导出的数据可能存在评论错乱问题（指多个条目下有重复的「个人评价」）。这个 Bug 现在已经被修复。如果发现自己的导出记录中存在此类问题，您可能需要重新导出一次。
2022/3/3 更新：🎉现已支持在 Colab 上运行，无需任何本地部署！点此尝试：
结果大概长这样（示例链接）:
欢迎各路大触 PR ！也欢迎各位用自己的账户测试，因为我自己点的格子还挺少的（示例文件做了裁剪，自己实际上不到 100 个），所以肯定有部分条目是有问题的，只是我现在发现不了
项目地址：https://github.com/jerrylususu/bangumi-takeout-py
2023/8/2 更新：现已支持 Github Actions，具体使用请参考 README
2022/12/1 更新：备份工具使用量过大，造成 Bangumi 全站缓慢，被 Sai 吐槽了。已经减缓请求频率，备份耗时可能增加。
2022/6/22 更新：欢迎尝试实验性项目 Bangumi Takeout More，现已支持小组讨论、日志、目录导出。
2022/5/24 更新：现已支持增量导出和导出至 CSV。
2022/5/10 更新：因为上游 API (Bangumi API) 的收藏接口出现了一个 Bug，2022/3/6 之后导出的数据可能存在评论错乱问题（指多个条目下有重复的「个人评价」）。这个 Bug 现在已经被修复。如果发现自己的导出记录中存在此类问题，您可能需要重新导出一次。
2022/3/3 更新：🎉现已支持在 Colab 上运行，无需任何本地部署！点此尝试：
结果大概长这样（示例链接）:
欢迎各路大触 PR ！也欢迎各位用自己的账户测试，因为我自己点的格子还挺少的（示例文件做了裁剪，自己实际上不到 100 个），所以肯定有部分条目是有问题的，只是我现在发现不了
顺序
#3 - 2022-3-2 07:20
bangumi 教宗
#3-2 - 2022-3-2 17:56
NekoNull
已添加对 bangumi/Archive 的支持，不过似乎 Archive 里的数据和 API 得到的数据存在略微差异？API 上似乎 episode type 只有 0,1,2,3（本篇、SP、OP、ED），但是 Archive 里还有 4 和 6（预告/宣传/广告、其他）。
#3-3 - 2022-3-2 22:07
bangumi 教宗
我好久没见到4和6了，等着在API里加上。
NekoNull 说: 已添加对 bangumi/Archive 的支持，不过似乎 Archive 里的数据和 API 得到的数据存在略微差异？API 上似乎 episode type 只有 0,1,2,3（本篇、SP、OP...
#3-4 - 2022-3-2 22:09
#3-5 - 2022-3-4 05:27
#3-6 - 2022-3-4 05:35
#3-8 - 2022-3-4 19:54
#3-9 - 2022-3-4 20:09
#4 - 2022-3-2 09:56
#7 - 2022-3-2 11:01
#20 - 2022-3-3 21:05
#22 - 2022-3-4 11:39
年轮蛋糕
(Bangumi ❤er)
ohno，generate.py报错了，只得到了json
看了看报错的问题，我收藏了3个条目，现在已经被锁定了。网页虽然还看得到，但是 Bangumi Archive好像获取不到的样子...
少女与战车 爱里寿战争！
北欧妹子日本好吃惊
亲吻那片花瓣 玲绪麻衣日记
获取到的json
subject_data是None，代码找不到key值，于是报错
虽然已经锁定了，但是不想就这么删除收藏。希望猫空桑可以修复，谢谢
，只得到了json看了看报错的问题，我收藏了3个条目，现在已经被锁定了。网页虽然还看得到，但是 Bangumi Archive好像获取不到的样子...
少女与战车 爱里寿战争！
北欧妹子日本好吃惊
亲吻那片花瓣 玲绪麻衣日记
获取到的json
{'subject_id': 182792, 'subject_type': 2, 'rate': 0, 'type': 2, 'comment': None, 'tags': ['2016'], 'ep_status': 0, 'vol_status': 0, 'updated_at': '2019-07-29T01:03:42+00:00', 'private': False, 'subject_data': None, 'ep_data': {}, 'progress': None}subject_data是None，代码找不到key值，于是报错
虽然已经锁定了，但是不想就这么删除收藏。希望猫空桑可以修复，谢谢
#23 - 2022-3-5 11:40
#26 - 2022-5-10 16:04
#29 - 2022-5-10 20:27
#32 - 2022-5-13 15:08
用户
#32-1 - 2022-5-13 15:23
NekoNull
1. 这是可行的，理论上可以对前一次和这次的数据diff，从而只更新新增/修改的数据。主要耗时的部分应该是收视进度获取，对现有的程序（fetch 部分）做一些修改应该就可以实现。
2. 我前端技能树点的不是很多，当前选择完全输出至 HTML 只是因为实现起来比较简单。另一种方式可能是实现一个类似于「数据浏览器」的前端网页，选择导出的 json 文件之后动态加载。这部分可以通过写其他的 generator 实现，其他开发者也可以自己实现。（另：太长指的是多少？千级？）
3. 如果指的是从其它网站导入数据，会存在需要把数据关联到 Bangumi 对应条目的问题。而如果指的是重新导入此前用本工具导出的数据，我暂时想不到什么场景下会需要这一功能，欢迎回复讨论。
2. 我前端技能树点的不是很多，当前选择完全输出至 HTML 只是因为实现起来比较简单。另一种方式可能是实现一个类似于「数据浏览器」的前端网页，选择导出的 json 文件之后动态加载。这部分可以通过写其他的 generator 实现，其他开发者也可以自己实现。（另：太长指的是多少？千级？）
3. 如果指的是从其它网站导入数据，会存在需要把数据关联到 Bangumi 对应条目的问题。而如果指的是重新导入此前用本工具导出的数据，我暂时想不到什么场景下会需要这一功能，欢迎回复讨论。
#32-2 - 2022-5-13 15:39
用户
谢谢答复。
2. 一个ACG长老，完全有可能收集数以万计的条目。
3. 同步用户数据，当你在旧账户和新账户中分别有相当数量的条目，想要合并时，这个功能就会发挥作用。
NekoNull 说: 1. 这是可行的，理论上可以对前一次和这次的数据diff，从而只更新新增/修改的数据。主要耗时的部分应该是收视进度获取，对现有的程序（fetch 部分）做一些修改应该就可以实现。
2. 我前端技能树点...
2. 一个ACG长老，完全有可能收集数以万计的条目。
3. 同步用户数据，当你在旧账户和新账户中分别有相当数量的条目，想要合并时，这个功能就会发挥作用。
#32-3 - 2022-5-13 15:56
NekoNull
2. 看来是我估计少了。这种情况可能的确上分页比较合适，不过担心会破坏单文件 HTML 的便携性。如果依然要保持单文件的话，可能要内嵌一个巨大的 JSON 对象，或者进行一定程度的压缩。
3. 对于这一点，理论上可以在生成 HTML 的时候，从多个 takeout.json 中获取数据，相当于本地合并。如果直接修改 Bangumi 数据，感觉有可能触发 API 速率限制。
用户 说: 谢谢答复。
2. 一个ACG长老，完全有可能收集数以万计的条目。
3. 同步用户数据，当你在旧账户和新账户中分别有相当数量的条目，想要合并时，这个功能就会发挥作用。
3. 对于这一点，理论上可以在生成 HTML 的时候，从多个 takeout.json 中获取数据，相当于本地合并。如果直接修改 Bangumi 数据，感觉有可能触发 API 速率限制。
#32-4 - 2022-5-13 19:58
用户
我使用过 #19 的用户脚本，发现它非常方便。它似乎还带有一个导入功能，但我还没有试过。
#19 的用户脚本是以 CSV 格式导出的，后来又更新为 .xlsx 格式，所以可以很容易地在电子表格软件中使用。
它似乎完全满足了我对用户数据迁移的需要。它输出的数据相对较少，而且不能记录你看过多少集。我认为可以用一种方法来记录数据，创建一个新的字段，数据格式为 "EP 001~009, 011~013; SP 001~005"。
我没有学过编程，不能顺利地将 json 格式导入电子表格。我认为 CSV 格式已经足够用于迁移用户数据，而且在电子表格中排列、汇总比HTML格式更方便。
我认为条目的详细信息（例如每一话的标题、歌曲的曲目列表等）应该以另一种方式存储，导出仅仅记录需要的数据。
NekoNull 说: 2. 看来是我估计少了。这种情况可能的确上分页比较合适，不过担心会破坏单文件 HTML 的便携性。如果依然要保持单文件的话，可能要内嵌一个巨大的 JSON 对象，或者进行一定程度的压缩。
3. 对于这...
#19 的用户脚本是以 CSV 格式导出的，后来又更新为 .xlsx 格式，所以可以很容易地在电子表格软件中使用。
它似乎完全满足了我对用户数据迁移的需要。它输出的数据相对较少，而且不能记录你看过多少集。我认为可以用一种方法来记录数据，创建一个新的字段，数据格式为 "EP 001~009, 011~013; SP 001~005"。
我没有学过编程，不能顺利地将 json 格式导入电子表格。我认为 CSV 格式已经足够用于迁移用户数据，而且在电子表格中排列、汇总比HTML格式更方便。
我认为条目的详细信息（例如每一话的标题、歌曲的曲目列表等）应该以另一种方式存储，导出仅仅记录需要的数据。
#32-5 - 2022-5-13 22:43
NekoNull
takeout.json 中包含了所有数据，本身也足够通用，不过面向普通用户的操作便携性也的确是问题。已经将生成 csv 的需求加入 issue，但不太确定具体需要包含哪些字段。在 #19 脚本上加入一个「已完成分集」？如果有更多描述，欢迎在 issue 链接讨论，或是在本帖/站内信交流。
https://github.com/jerrylususu/bangumi-takeout-py/issues/6
用户 说: 我使用过 #19 的用户脚本，发现它非常方便。它似乎还带有一个导入功能，但我还没有试过。
#19 的用户脚本是以 CSV 格式导出的，后来又更新为 .xlsx 格式，所以可以很容易地在电子表格软件中使...
https://github.com/jerrylususu/bangumi-takeout-py/issues/6
#32-6 - 2022-5-14 00:11
用户
我基本上没有任何需求。目前我的需求是导出和导入最收藏的条目，以及 “已完成分集” 的信息。
当然，有些人可能希望能够导出他们自己的短评论（吐槽）、长评论、Tags 等。有些人希望在 ep 下留下自己与他人的讨论。
我认为只要是用户自己写的，就可能是有意义的。但要导出所有的讨论应该是很困难的，如果有太多的收藏，数据会变得很大。
至于可能触发API限制的导入，我认为可以 "愚公移山"，每天保存100条信息，10天保存1000条信息。
NekoNull 说: takeout.json 中包含了所有数据，本身也足够通用，不过面向普通用户的操作便携性也的确是问题。已经将生成 csv 的需求加入 issue，但不太确定具体需要包含哪些字段。在 #19 脚本上加入...
当然，有些人可能希望能够导出他们自己的短评论（吐槽）、长评论、Tags 等。有些人希望在 ep 下留下自己与他人的讨论。
我认为只要是用户自己写的，就可能是有意义的。但要导出所有的讨论应该是很困难的，如果有太多的收藏，数据会变得很大。
至于可能触发API限制的导入，我认为可以 "愚公移山"，每天保存100条信息，10天保存1000条信息。
#32-7 - 2022-5-24 22:57
NekoNull
hi! 刚才发布了新版本，新增了增量导出以及导出至 CSV。如果可以的话请试试看吧！（但是目前还没确定分集的最佳表现形式，欢迎 feedback）
用户 说: 我基本上没有任何需求。目前我的需求是导出和导入最收藏的条目，以及 “已完成分集” 的信息。
当然，有些人可能希望能够导出他们自己的短评论（吐槽）、长评论、Tags 等。有些人希望在 ep 下留下自己与...
#32-8 - 2022-5-25 22:14
用户
感觉基本上满足了需求，非常好。
如果继续使用现在的完成度表达方法，感觉可以把“完成的集数”和“总集数”分成两列。“完成度（百分比）”可以从电子表格中计算出来，可以考虑删除这一栏。
关于分集的表现形式，我在上面举了一个例子："EP 001~009, 011~013; SP 001~005"。意思是我已经完成了正片的第 1~9 话，11~13 话，而第 10 话未看。另外完成了 SP 1~5 话。我所想到的就是这种表示方法，供参考。
NekoNull 说: hi! 刚才发布了新版本，新增了增量导出以及导出至 CSV。如果可以的话请试试看吧！（但是目前还没确定分集的最佳表现形式，欢迎 feedback）
如果继续使用现在的完成度表达方法，感觉可以把“完成的集数”和“总集数”分成两列。“完成度（百分比）”可以从电子表格中计算出来，可以考虑删除这一栏。
关于分集的表现形式，我在上面举了一个例子："EP 001~009, 011~013; SP 001~005"。意思是我已经完成了正片的第 1~9 话，11~13 话，而第 10 话未看。另外完成了 SP 1~5 话。我所想到的就是这种表示方法，供参考。
#46 - 2022-5-27 22:56
运行报这个错误楼主，
#51 - 2022-6-20 15:25
konata
#51-2 - 2022-6-20 17:32
konata
所有显示时间的地方都是中时区,是在colab中运行的,但是我用的是日本的节点
NekoNull 说: 具体指的是导出数据中哪个位置的时区呢？是不是在 colab 上运行的？默认是根据运行环境所在时区的。
#51-3 - 2022-6-21 02:50
NekoNull
多谢说明！刚才确认了这是程序内未指定时区，默认使用运行环境时区导致的。Colab 内的机器无论地理位置应该都是 UTC 时区。未来可能会增加选项让用户自定义输出时区。
https://github.com/jerrylususu/bangumi-takeout-py/issues/11
藍色飛揚 说: 所有显示时间的地方都是中时区,是在colab中运行的,但是我用的是日本的节点
https://github.com/jerrylususu/bangumi-takeout-py/issues/11
#77 - 2023-7-26 08:41
他说nil没法调用IsNil
(nobody cares.)
#77-2 - 2023-7-30 10:44
他说nil没法调用IsNil
我自己写了一些服务的自动备份还没出事，archive似乎也是这么运作的；cron别设置太高频，artifact保留日期缩短一点应该没啥问题。token可以最长可以申请365天，一年一更github secrets呗。感觉运行时间会是瓶颈，可能需要你做一些并行化修改。
NekoNull 说: 是个好主意，不过不知道这样是否会违反 ToS？另外 API 令牌过期可能也是个问题
#77-3 - 2023-8-2 00:07
NekoNull
已支持，可以参考 README 「使用 Github Actions 执行」 一节。
不过目前只是简单建了个 yml，代码层面没有做并行化。其实大部分数据从 archive 取的话，串行请求也够了，最耗时的也就是获取每个收藏的进度。我自己试了下，~140个收藏12分钟也跑完了，考虑到 Github Actions 有6个小时运行时间限制，一般情况下应该够用了。
不过目前只是简单建了个 yml，代码层面没有做并行化。其实大部分数据从 archive 取的话，串行请求也够了，最耗时的也就是获取每个收藏的进度。我自己试了下，~140个收藏12分钟也跑完了，考虑到 Github Actions 有6个小时运行时间限制，一般情况下应该够用了。
#77-4 - 2023-8-2 00:43
他说nil没法调用IsNil
牛的牛的
使用体验补充：总收藏条目超过3k的用户请不要使用github action，大概率会超时。
NekoNull 说: 已支持，可以参考 README 「使用 Github Actions 执行」 一节。
不过目前只是简单建了个 yml，代码层面没有做并行化。其实大部分数据从 archive 取的话，串行请求也够了，...
使用体验补充：总收藏条目超过3k的用户请不要使用github action，大概率会超时。
#87 - 2023-10-17 18:28
OH_toothache
(小圣杯邀请码: whyjxz14#576501)
#87-1 - 2023-10-17 22:19
#87-2 - 2023-10-19 02:34
OH_toothache
下下来自己搞了。用colab弄死了都失败
NekoNull 说: 这里为了避免对bangumi服务器造成攻击，加载间隔设置的很保守。可以手动调小 fetch.py 18 行的 LOAD_WAIT_MS 值试试，如降低到1500，但不要调的太小。
#89 - 2023-10-17 18:44
#97 - 2025-8-25 23:27