#1 - 2018-8-22 22:46
叡山電車 (無産少女日々異化中)
如题，现在可以通过RSS来订阅一些Bangumi上的信息源了。

https://docs.rsshub.app/#bangumi

配合IFTTT之类的工具体验最好
#2 - 2018-8-22 22:52
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶 (ᓚᘏᗢ_(:3」∠)_翼です～銀髪赤眼最高！ ...)
终于时隔多年(?)又看见有人发提及RSS的帖子了。(bgm38)
#3 - 2018-8-22 23:19
默沨 (星梨花/環/弥生/桃子/杏奈P)
RSS不是已经凉了吗(bgm38)
#3-1 - 2018-8-22 23:25
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶
并没有凉啊(bgm38)
#3-2 - 2018-8-22 23:34
默沨
Neko_Aria 说: 并没有凉啊
说起来好像是前几天想研究一下结果发现好几个订阅工具都停止服务给了我错觉？(bgm38)
不了解的东西还是不乱说了(bgm38)
#3-3 - 2018-8-22 23:41
bangumi大西王
默沨(id: eien) 说: 说起来好像是前几天想研究一下结果发现好几个订阅工具都停止服务给了我错觉？
不了解的东西还是不乱说了
好几个订阅工具国内AppStore下架了, 不过没凉...
#3-4 - 2018-8-22 23:47
默沨
Trim21 说: 好几个订阅工具国内AppStore下架了, 不过没凉...
这样啊(bgm38)谢指点
#3-5 - 2018-8-22 23:53
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶
默沨 说: 说起来好像是前几天想研究一下结果发现好几个订阅工具都停止服务给了我错觉？
不了解的东西还是不乱说了
我用的是Inoreader，其他的还有Feedly、NewsBlur等。
最早是Google Reader，都凉了好多年了。(bgm38)
#3-6 - 2018-8-23 00:21
默沨
Neko_Aria 说: 我用的是Inoreader，其他的还有Feedly、NewsBlur等。
最早是Google Reader，都凉了好多年了。
受教了，得空在研究下，看起来挺好用(bgm38)
#4 - 2018-8-23 07:50
ForsakenRei (A.T.Field)
(bgm38)我RSS订阅只用来扫需要的资源和想看的新番了(
#5 - 2018-8-23 08:46
owl (素晴らしい作品の感動を共有して何が悪い! ... ... ..)
就算订阅了还是忍不住刷超展开(bgm38)
#6 - 2018-8-23 10:11
Cedar (｡´-д-)
天啊梦寐以求(bgm38)很早就想RSS刷Bilibili等站了 我还特意去问过B站客服有没有RSS..客服经过短暂的沉默后(大概是偷偷去问技术人员了)告诉我没有→_→(早期明明是有的)
我记得RSS工具凉掉的原因是没法变现..而且有了RSS后广告商也没法做广告了..但是RSS本身是不会凉的, 现在所有推送功能的背后应该都是类似RSS的技术..或许RSS工具还是要做成免费开源去中心化的才能生存..
#6-1 - 2018-8-23 12:51
叡山電車
RSS是符合早期的互联网精神的，那时候互联网并非单纯是资本家的发财工具
#6-2 - 2018-8-23 13:04
Cedar
叡山電車 说: RSS是符合早期的互联网精神的，那时候互联网并非单纯是资本家的发财工具
所以我是相当支持的!
更新..突然发现RSS跟我想的不太一样(bgm38)
#7 - 2018-8-23 12:21
epix ((((；ﾟДﾟ)))))))
时隔多年的RSS讨论..
RSS似乎是没有什么翻页机制的? 如果每小时有10条新信息, RSS只包含最近20条信息, 那如果RSS抓取器连续2小时没有抓的话, 就会永远错过消息了.
#7-1 - 2018-8-23 12:50
叡山電車
RSS抓取器是通过每个条目的唯一ID来确定该条目是否是一个需要推送的新条目的
#7-2 - 2018-8-23 15:42
epix
叡山電車 说: RSS抓取器是通过每个条目的唯一ID来确定该条目是否是一个需要推送的新条目的
你没看懂我啥意思... 我可能说的不明白
我这里说的RSS抓取器是阅读器, 比如inoreader
假设一个RSS源每小时有10条新信息, RSS里只固定包含最近20条信息. 也就是某时间源里是第1~20条信息, 过了一个小时以后是第10~30条信息, 过了两个小时以后是20~40条信息.
如果RSS阅读器间隔超过2小时才去访问一次RSS源的话, 就会永远错过两个小时以前的消息了. 比如第一次访问拿到了第1~20条信息, 三个小时后再去访问, 拿到的是第30~50条信息. 第20~30条信息错过了
#7-3 - 2018-8-23 18:49
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶
如果有更多的需求，要么付费要么自己折腾Tiny Tiny RSS。(bgm38)
现在也没多少优质的订阅源，我感觉免费的就够用了，也懒得折腾Tiny Tiny RSS。
刚开始用RSS那时候，订阅最多的是各种私人博客。
自从微信公众号流行起来后，越来越多人不继续更新私人博客了，转移到微信公众号上面去了。
#7-4 - 2018-8-23 21:10
epix
Neko_Aria 说: 如果有更多的需求，要么付费要么自己折腾Tiny Tiny RSS。
现在也没多少优质的订阅源，我感觉免费的就够用了，也懒得折腾Tiny Tiny RSS。
刚开始用RSS那时候，订阅最多的是各种私人博...
我说的是RSS本身的缺陷...
不管是用托管的服务还是自己搭的, 没有人能保证100%可用, 即使RSS阅读器保证100%了, 要抓的RSS源或者之间的链路也无法保证什么时候不会出问题一下, 就担心会丢信息.
#7-5 - 2018-8-23 21:13
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶
epix 说: 我说的是RSS本身的缺陷...
不管是用托管的服务还是自己搭的, 没有人能保证100%可用, 即使RSS阅读器保证100%了, 要抓的RSS源或者之间的链路也无法保证什么时候不会出问题一下, 就担心会...
你有强迫症吗？。。这种低概率信息丢失都要计较？(bgm38)
要是觉得别人的RSS源不靠谱，自己写爬虫建立RSS源咯。
写爬虫的过程按下不表，运行爬虫又需要额外的服务器资源开销。
RSS只是用来获取信息的渠道之一，何必一棵树上吊死。
#7-6 - 2018-8-23 21:27
bangumi大西王
epix(id: epix) 说: 我说的是RSS本身的缺陷...
不管是用托管的服务还是自己搭的, 没有人能保证100%可用, 即使RSS阅读器保证100%了, 要抓的RSS源或者之间的链路也无法保证什么时候不会出问题一下, 就担心会...
这个缺陷就算不rss, 用其他的消息聚合服务也会出现的...
甚至源站还有可能挂掉呢(
#7-7 - 2018-8-23 21:31
Cedar
Neko_Aria 说: 如果有更多的需求，要么付费要么自己折腾Tiny Tiny RSS。
现在也没多少优质的订阅源，我感觉免费的就够用了，也懒得折腾Tiny Tiny RSS。
刚开始用RSS那时候，订阅最多的是各种私人博...
我还以为不需要折腾呢..用qbit自己的RSS功能时就很简单..查了查Tiny Tiny RSS竟然还要自己搭服务器..这是为啥?
#7-8 - 2018-8-23 21:48
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶
Cedar 说: 我还以为不需要折腾呢..用qbit自己的RSS功能时就很简单..查了查Tiny Tiny RSS竟然还要自己搭服务器..这是为啥?
qBit的RSS是在本地同步的，获取到的信息里最重要的是种子的下载地址，另外附带番剧信息等，
这相对简单得多，而且需要同步的频率没那么高(一个订阅源一天不会有几十个更新)。
而Tiny Tiny RSS这种RSS服务是需要高同步率，这需要机器24小时不间断运行(首选服务器)，
而且需要存储文本、图片等信息(信息存档)，还有一些别的定制化操作。
两者的定位就不一样。
#7-9 - 2018-8-23 21:56
epix
Trim21 说: 这个缺陷就算不rss, 用其他的消息聚合服务也会出现的...
甚至源站还有可能挂掉呢(
twitter就不会. tweet有个唯一id, 先抓去一次, 然后下次抓取的时候, 可以一路翻页抓取到上次停下的id, 来保证不会漏. 以及可以不是按照固定的分页去抓, 来避免, 我只需要抓到第15个, 而每页提供10个, 导致我必须得抓第10~20个消息, 白费了5个消息的资源还要去重.
漏消息不难受吗... 万一挺重要呢.. 就让我感觉这协议不可靠..
#7-10 - 2018-8-23 22:07
bangumi大西王
epix(id: epix) 说: twitter就不会. tweet有个唯一id, 先抓去一次, 然后下次抓取的时候, 可以一路翻页抓取到上次停下的id, 来保证不会漏. 以及可以不是按照固定的分页去抓, 来避免, 我只需要抓到第15...
推特不算是rss这种消息聚合服务啊...

我刚刚说的缺陷是指服务挂掉这种情况

你说的这个做法不同的rss服务端和客户端有不同的行为, 本身rss协议是没规定这个的.

比如说服务端也可以一直抓取, 直到出现了上一次抓取过的id, 表示没遗漏消息
#7-11 - 2018-8-23 22:42
epix
Trim21 说: 推特不算是rss这种消息聚合服务啊...

我刚刚说的缺陷是指服务挂掉这种情况

你说的这个做法不同的rss服务端和客户端有不同的行为, 本身rss协议是没规定这个的.

比如说服务端也可以一直抓取,...
服务端没法一直抓取rss直到出现上一次的id, 因为rss没规定这个, 所以没有人能做到
把每个用户视作一个消息源, 关注了他们的timeline就是消息聚合了..
#7-12 - 2018-8-23 22:45
bangumi大西王
epix(id: epix) 说: 服务端没法一直抓取rss直到出现上一次的id, 因为rss没规定这个, 所以没有人能做到
把每个用户视作一个消息源, 关注了他们的timeline就是消息聚合了..
呃...为什么rss没规定这个所以没有人能做到?

以楼主发的这个为例子, 服务端(rsshub)从数据源(bangumi)具体爬多少数据是写程序的楼主决定的, 只要最终返回来的数据格式符合rss的格式就可以了.

规范没有规定意味着可以不实现, 不代表不能实现
#7-13 - 2018-8-23 23:00
bangumi大西王
epix(id: epix) 说: 服务端没法一直抓取rss直到出现上一次的id, 因为rss没规定这个, 所以没有人能做到
把每个用户视作一个消息源, 关注了他们的timeline就是消息聚合了..
啊 我突然明白你的意思了

你说的是feedly这类rss服务吧...,他们的服务端会根据数据源的更新频率设置不同的抓取频率, 来尽量保证不漏消息, 而你用对应的客户端看的时候会像推特一样, 从你最后看的消息开始

一般rss会有对应的冗余的, 如果每天会产生20条消息的话rss整个数据源不会只返回20条消息

当然，如果某个rss源某天的信息量暴涨，的确是没有一个办法在理论上完全避免遗漏消息的
#7-14 - 2018-8-23 23:38
Cedar
Neko_Aria 说: qBit的RSS是在本地同步的，获取到的信息里最重要的是种子的下载地址，另外附带番剧信息等，
这相对简单得多，而且需要同步的频率没那么高(一个订阅源一天不会有几十个更新)。
而Tiny Tiny RS...
其实我对RSS了解挺少的..不过要是订阅某花园的首页的话 一天肯定有几十个更新呀(bgm38)我订阅之后一两天不看就能积累200多条..而且为什么要保存图片信息呢 qbit好像是看哪条才主动获取哪条的图片
其实如今RSS更多是提醒功能..想要获得完整信息 还是需要自己去源站点看吧..比如用楼主提供的链接里那种RSS获取B站视频更新的话 还是要进B站观看视频呀..所以我还以为RSS都是很轻量级的..像qbit一样 打开就能用..(bgm38)
我就一台小笔记本电脑..也不可能24小时开着..有没有什么简单的方法使用Tiny Tiny RSS呢? 用自己的笔记本建个给自己用的服务器 然后想看RSS的时候才启动? 可是用别人的服务又感觉限制太多..
#7-15 - 2018-8-23 23:44
bangumi大西王
Cedar 说: 其实我对RSS了解挺少的..不过要是订阅某花园的首页的话 一天肯定有几十个更新呀我订阅之后一两天不看就能积累200多条..而且为什么要保存图片信息呢 qbit好像是看哪条才主动获取哪条的图片
其实如今...
你是学生吗，腾讯云主机每月12块钱。
自建rss服务有一个目的是获取一个全文rss，所以要保存图片之类的。

然后京东618的时候有一折活动…不过今年已经过了…

不是还有rsshub吗（
#7-16 - 2018-8-24 00:06
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶
Cedar 说: 其实我对RSS了解挺少的..不过要是订阅某花园的首页的话 一天肯定有几十个更新呀我订阅之后一两天不看就能积累200多条..而且为什么要保存图片信息呢 qbit好像是看哪条才主动获取哪条的图片
其实如今...
我也没什么深入了解，也就是轻度使用。(bgm38)
之所以要做信息存储，就是为了直接在RSS阅读器里阅读，过滤掉多余的信息，
同时也能避免遗漏某些信息吧，比如被删掉了的帖子什么的。(bgm38)
虽然RSS本身是设计来做信息聚合的，但是也可以作为信息提醒。
Server-side
You will need a dedicated web hosting account (i.e. a VDS) or access to a physical server running LAMP stack.

Everything else, including, but not limited to, shared hosting accounts, windows and other alternative OSes, NAS boxes, PaaS services of any kind, is not supported. Not supported in this case meaning: it may work in your particular case but if you have problems you are on your own.
要折腾Tiny Tiny RSS的话需要搞个Linux主机，虽然官方建议搞个虚拟主机或者物理服务器，
但是我看了下也可以用树莓派这类基于Linux的微型主机。
#7-17 - 2018-8-24 00:10
𝒩𝑒𝓀𝑜_𝒜𝓇𝒾𝒶
Trim21 说: 你是学生吗，腾讯云主机每月12块钱。
自建rss服务有一个目的是获取一个全文rss，所以要保存图片之类的。

然后京东618的时候有一折活动…不过今年已经过了…

不是还有rsshub吗（
用国内的主机虽然省事，但是遇到有些访问不了的国外网站不是扑街？(bgm38)
#7-18 - 2018-8-24 00:11
epix
Trim21 说: 啊 我突然明白你的意思了

你说的是feedly这类rss服务吧...,他们的服务端会根据数据源的更新频率设置不同的抓取频率, 来尽量保证不漏消息, 而你用对应的客户端看的时候会像推特一样, 从你最后...
对.. #7-2就是想解释清楚.. 看来还是没解释清楚 qaq
考虑rss的话, 只能在生成rss的时候尽量多存一段时间至少不小于1小时的保证阅读器能抓到(似乎阅读器大多能1小时刷一次), 或者用 WebSub做推送. 然而这个推送我还是觉得不科学, 比如一样的掉线一段时间怎么办, 以及要求客户端有 web 接口来做推送.

大概只有造个新轮子才行了
#7-19 - 2018-8-24 00:15
Cedar
Trim21 说: 你是学生吗，腾讯云主机每月12块钱。
自建rss服务有一个目的是获取一个全文rss，所以要保存图片之类的。

然后京东618的时候有一折活动…不过今年已经过了…

不是还有rsshub吗（
我只是觉得为一个RSS订阅弄一个服务器有点小题大做的感觉 (
为什么会提RSSHub 那个不是生成RSS源用的么? 不是阅读器吧
#7-20 - 2018-8-24 00:25
bangumi大西王
epix(id: epix) 说: 对.. #7-2就是想解释清楚.. 看来还是没解释清楚 qaq
考虑rss的话, 只能在生成rss的时候尽量多存一段时间至少不小于1小时的保证阅读器能抓到(似乎阅读器大多能1小时刷一次), 或者用 W...
现在主流rss服务的服务端跟客户端之间已经不是用rss协议来通讯的了, 不会出现你说的那种问题... 比如你提到的inoreader...我刚刚提到的feedly
#7-21 - 2018-8-24 00:27
bangumi大西王
Cedar(id: 313469) 说: 我只是觉得为一个RSS订阅弄一个服务器有点小题大做的感觉 (
为什么会提RSSHub 那个不是生成RSS源用的么? 不是阅读器吧
啊..提到rsshub是因为, 如果已经有全文rss生成器的话, 用feedly这类服务就已经足够了, 不需要再自建一个了. (用来追踪dmhy的前提下)
#7-22 - 2018-8-24 00:27
Cedar
Neko_Aria 说: 我也没什么深入了解，也就是轻度使用。
之所以要做信息存储，就是为了直接在RSS阅读器里阅读，过滤掉多余的信息，
同时也能避免遗漏某些信息吧，比如被删掉了的帖子什么的。
虽然RSS本身是设计来做信息聚合...
我还以为所有RSS服务器都像qbit那样的(bgm38)如果qbit再加个分类和星标功能大概就够我用了..
#7-23 - 2018-8-24 00:29
Cedar
Trim21 说: 啊..提到rsshub是因为, 如果已经有全文rss生成器的话, 用feedly这类服务就已经足够了, 不需要再自建一个了.
这样..果然还是用别人的服务吧..(bgm38)但是qbit那种又是怎么做到的呢? 难道是它内置了一个服务器么 为什么别的RSS阅读器就不内置呢..
#7-24 - 2018-8-24 00:31
epix
Trim21 说: 现在主流rss服务的服务端跟客户端之间已经不是用rss协议来通讯的了, 不会出现你说的那种问题... 比如你提到的inoreader...我刚刚提到的feedly
啊? 那用什么通信?
#7-25 - 2018-8-24 00:40
bangumi大西王
epix(id: epix) 说: 啊? 那用什么通信?
具体就没研究过了, 应该是他们自己新的数据格式, 但是肯定不是rss了(bgm38)
#7-26 - 2018-8-24 00:41
bangumi大西王
Cedar(id: 313469) 说: 这样..果然还是用别人的服务吧..但是qbit那种又是怎么做到的呢? 难道是它内置了一个服务器么 为什么别的RSS阅读器就不内置呢..
我不知道qbit是什么...233
#7-27 - 2018-8-24 00:42
bangumi大西王
epix(id: epix) 说: 啊? 那用什么通信?
如果是只实现了客户端的那种, 还是直接从rss源抓取数据的, 没法避免你说的问题的发生, 不过一般也不叫他们"rss服务"了
#7-28 - 2018-8-24 00:55
epix
Trim21 说: 具体就没研究过了, 应该是他们自己新的数据格式, 但是肯定不是rss了
我说 feedly 和 rss源 之间, 这不用rss用什么..
#7-29 - 2018-8-24 03:09
bangumi大西王
epix(id: epix) 说: 我说 feedly 和 rss源 之间, 这不用rss用什么..
这两个之间是rss, 我是说feedly服务端和客户端之间不是rss...(

这两个之间就是我#7-12说的, 如果rss源返回数据有一定的冗余量的话不会遗漏消息, 如果设计的不好的话就会遗漏了...
#7-30 - 2018-8-24 13:00
epix
Trim21 说: 这两个之间是rss, 我是说feedly服务端和客户端之间不是rss...(

这两个之间就是我#7-12说的, 如果rss源返回数据有一定的冗余量的话不会遗漏消息, 如果设计的不好的话就会遗漏了.....
feedly服务端和客户端之间当然不是RSS，而是自己做的能保证不会丢的…这个没有讨论的意义

冗余本身就不科学，比如我一小时抓一次，结果每次都返回最近100小时的内容，那每次都有99%的信息没用白费资源。如果是类似Twitter的，都可以做到很久才抓一次也不会漏
#7-31 - 2018-8-24 17:35
bangumi大西王
epix 说: feedly服务端和客户端之间当然不是RSS，而是自己做的能保证不会丢的…这个没有讨论的意义

冗余本身就不科学，比如我一小时抓一次，结果每次都返回最近100小时的内容，那每次都有99%的信息没用白费...
这就见仁见智了（
冗余本身虽然会造成一些浪费，但是为了避免丢失信息这个角度上没啥不科学的…浪费一些流量节约（可能是双方的）开发时间也没啥不好…
#7-32 - 2018-8-25 07:50
Jamella
Trim21 说: 啊..提到rsshub是因为, 如果已经有全文rss生成器的话, 用feedly这类服务就已经足够了, 不需要再自建一个了. (用来追踪dmhy的前提下)
如果文章有翻页或者想把文章里图集的原图弄出来的话，还是得自己造轮子
#8 - 2018-8-24 21:01
蜜瓜改二@五月病🍭
我不喜欢 rss，我喜欢 streaming api
#9 - 2018-8-25 07:42
Jamella (Hail to you, Champion. | Lumis Eterne | 君と同じ青 ...)
从rss过来的，用feed43简单搞了一个...(bgm39)
https://feed43.com/0708677181263446.xml

全文的话就懒得爬了，因为每个话题里都会有新跟帖，全文意义不大