阅读视图

发现新文章,点击刷新页面。

北青深一度和谷雨实验室全文RSS

之前《我制作的微信公众号RSS》这篇文章的评论里,有网友反馈了一些希望输出 RSS 的信息源,捡了两个看着顺眼的做了下。

北青深一度

地址:https://feedpress.me/bqs

制作步骤:

  • 找到北青深一度的网易号页面:https://c.m.163.com/news/sub/T1477387792079.html
  • 在 Inoreader 中添加订阅源,输入这个地址,会显示这不是一个有效的 Feed,然后点击「创建 Rss 订阅源」,按照提示创建

    20211031_132837.png

    不知道为什么,我今天想重现这个过程,老是显示「我们无法抓取远程网站」,所以无法给出后续步骤示例了。

  • 由于这种方式创建的订阅没有公开的 RSS 地址,要给别人用的话不太方便,好在 Inoreader 提供了对目录输出 RSS 的功能(限 Pro 用户),因此在 Inoreader 里新建了一个同名目录,把这个订阅移动到这个目录里,右键选择获取 RSS 订阅源就可以得到可以公开使用的 RSS 地址了

    20211031_133912.png

谷雨实验室

地址:https://feedpress.me/wx-guyulab

制作步骤

  • 用我的个人微信订阅「谷雨实验室-腾讯新闻」这个公众号,并记住公众号 guyulab
  • 在 Telegram 上将这个公众号关联到我专门的群组里
  • zs 生成 Huginn Scenario

    zs-rss gen-wx-scenario -n 谷雨实验室 -i guyulab -o wx-guyulab.json
    
  • 登录 Huginn 导入创建好的 Scenario

关闭部分公众号RSS的全文输出

出于服务器压力、对微信反爬的担忧等多方面考虑,我决定关闭一些我制作的微信公众号 RSS 的全文输出,选择的标准如下:

  1. Inoreader 上订阅数少于 3 的,考虑关闭全文输出;
  2. 每日发表文章在 3 篇以上的,考虑关闭全文输出;
  3. 作者(或写作团队)有在其他平台发布内容且提供 RSS 输出的,考虑关闭全文输出;
  4. 内容很简短的,考虑关闭全文输出;
  5. 我个人对内容已经不感兴趣的,考虑关闭全文输出。

按照上述标准,筛讯出来了 8 个公众号 RSS,在昨晚做调整把它们的全文输出关闭了,这 8 个公众号及关闭全文理由如下:

  • AINLP: 更新频率过高
  • 艾格吃饱了: 美食类公众号,我个人不是很有兴趣,订阅数 4 人也比较少
  • 碗丸食事:同上
  • 也谈钱:作为投资理财类公众号,内容比较水(个人观点),我不太想看了,且订阅数少于 3
  • 微软研究院AI头条:其内容同样被发布在 MSRA 的官方博客上,并提供全文RSS输出,所以这个公众号 RSS 其实就没必要了
  • 观人看世界:虽然订阅者有 17 人,但是其主要内容是引用其他文章并发表简短评论
  • 民俗学论坛:订阅数少于 3 人
  • 华山感染:订阅数 4 人,且内容我不是很有兴趣

如果对上述公众号有全文需求,有如下解决办法:

  1. 使用 Inoreader,打开文章后,按下 w 键来载入全文,经测试对微信公众号的抓取效果还不错
  2. 我提供的 RSS 输出的都是文章原始链接,所以可以使用我提供的 RSS 抓取全文

(已修复)对微信公众号 RSS 停止更新的说明

年初换了新工作后,变得更忙了一点,看 RSS 的习惯也逐渐荒废了,今天上去看看,才发现我之前制作的微信公众号 RSS (见文章1文章2)全部停止更新了,故障发生的时间点大概是三到四周前,赶紧去看下到底是怎么回事。

由于 RSS 最终是由 FeedPress 输出的,所以我先登录到 FeedPress 上看了下,确认 FeedPress 自己没有出问题,只是输出的数据都是三到四周前的了;接着去看 Huginn,也是一样,工作正常,但接收到的原始数据就缺失了,而这些原始数据是我在一台国外 VPS 上的定时任务产出的,通过 Telegram API 获取 EFB 同步过来的微信公众号文章消息(详见我的另一篇文章),看了下日志,确认是这个定时任务出问题了。

手工执行了下定时任务,得到了这么一条错误输出:

The authorization key (session file) was used under two different IP addresses simultaneously, and can no longer be used. Use the same session exclusively, or use different sessions'

出错的代码见 Github

至此明白原因了:大概三周前,我在本地使用相同的 token 跑了自己写的脚本,用来导出聊天记录,当时我本地也报了这个错,但没太在意,就是从那个时候起 VPS 上的 token 就失效了,然后加上没有做什么监控也没有用户反馈,导致到今天我才发现这个问题。

明确问题后,按照如下过程修复问题:

  1. 删除 VPS 上的 token,并重新认证
  2. 获取 2021.04.30 后的微信公众号更新消息
  3. 对每个有输出 RSS 的公众号,取最近 10 篇文章发送到 Huginn,生成相应的 RSS

这样处理后问题暂时就解决了,FeedPress 应该会在之后陆续更新相应的 RSS 源了。

在此对订阅这些 RSS 源的朋友表示歉意!

用 Huginn 为高频 RSS 生成每日摘要并输出新的 RSS

我订阅了一些资讯类的 RSS,但是这种 RSS 通常更新频率都较高,好一点的一天十来篇文章,烦一点几十篇都有可能。但其实我订阅这些 RSS,只是想要对相关的领域(如时事、游戏)保持一定的关注度,更希望是定期(比如每天)整体扫一眼看有没有关心的内容,而不是在一天的各个时间段内连续不断地收到更新。

基于这个想法,我就想找个现成的工具为这种 RSS 生成一个每日摘要,但是只能找到从 RSS 生成摘要邮件的一些方法,而在邮件里看资讯并不是我习惯的方式,还是得自己动手啊。

思考尝试了下,这个问题有两种解决方法:

  1. 先用 Email Digest 工具(如IFTTT)将 RSS 转成摘要邮件,然后再将邮件转成 RSS,最后这一步可以用 Zapier
  2. 直接上 Huginn,RSS Agent + Digest Agent + Delay Agent + Data Output Agent 一套搞定

第一个方案我虽然也能操作,但是始终要在邮箱里过一遍,我还是嫌麻烦,而 Huginn 是我非常熟悉的工具,于是就选用了第二套方案。花了几天验证效果,调整之后的 Scenario 如下图所示:

digest-scenario.png

机核的 RSS 为例,从上到下五个 Agent 分别是:

  • RSS Agent:负责监听原始的 RSS 源,接收更新生成 event

    {
      "expected_update_period_in_days": "5",
      "clean": "false",
      "url": "https://www.gcores.com/rss"
    }
    
  • Digest Aget:负责聚合一定时间 RSS Agent 输出的 event 产生一个新的 event,我设定为每天凌晨 1 点执行,这样能把前一天所有的 RSS 更新聚合起来

    {
      "message": "<ul>{% for event in events %}<li><a href={{ event.url }}>{{ event.title }}<\/a><\/li>{% endfor %}<\/ul>",
      "expected_receive_period_in_days": "2",
      "retained_events": "0"
    }
    
  • Event Formatting Agent:给 Digest Agent 产生的 event 添加一个标题

    {
      "instructions": {
        "content": "{{ message }}",
        "title": "机核{% assign current_date = 'now' | date: '%s' | minus: 86400 %} {{current_date | date: \"%Y-%m-%d\" }} 摘要"
      },
      "matchers": [
    
      ],
      "mode": "clean"
    }
    
  • Delay Agent:延迟一定时间后将 Event Formatting Agent 的输出再传递给最后的 Data Output Agent,我设置为延迟到早上六点

    {
      "expected_receive_period_in_days": "3",
      "max_events": "100",
      "keep": "newest",
      "max_emitted_events": "1"
    }
    
  • Data Output Agent:将最终结果输出为新的 RSS

    {
      "secrets": [
        "gcore-daily"
      ],
      "expected_receive_period_in_days": 2,
      "template": {
        "title": "机核-每日摘要",
        "description": "机核每日消息汇总",
        "item": {
          "title": "{{ title }}",
          "description": "{{ content }}",
          "link": "https://www.gcores.com/"
        }
      },
      "ns_media": "true"
    }
    

这样我每天早上六点就能收到一个前一天的汇总列表了,效果如下:

digest-rss-item.png

除了机核,当然还会有其他资讯类 RSS 想做这个转换,每次都在 Huginn 上手动创建一个个 agent 也不是个事,就顺手在我的个人脚本仓库里加了一个脚本,还是以机核为例,只要执行下面的命令就会生成一个 Huginn 的 Scenario 文件,然后到 Huginn 上直接导入就好了:

zs-rss gen-daily-scenario --feed-url "https://www.gcores.com/rss" -n 机核 -o gcore.json

目前制作了两个这样的每日摘要 RSS,分别是:

输出的 RSS 里只有原始 RSS 里文章的标题和链接,文章内容被我丢掉了,之后考虑改一下把内容加上(如果有的话)。

我所使用过的微信公众号文章转 RSS 的方法

背景

作为一个 RSS 重度用户,在微广场关闭前,我一直使用微广场来把自己想看的微信公众号、知乎专栏转成 RSS。在微广场关闭后,不仅是我,很多人也意识到了,类似的公开服务最终都可能走向同样的结局。在那之后,我就开始探索自己的方案,尝试不依赖第三方服务来把微信公众号转成 RSS。比较幸运的是,当时我已经接触到了 Huginn使用它来获取一些学术论文资讯,而我加入的一个 Huginn 交流群里,早就有人在做相关的尝试了。基于交流群中朋友分享的方案,我也开始使用 Huginn 来为公众号输出 RSS,在这三年时间里,我前后使用过的方案有下面这些:

  1. 基于搜狗微信搜索的方案
  2. 基于即刻/快知和 RSSHub 的方案
  3. 基于 EFB 和 Telegram 的方案

我将在后文中按顺序讲一下这三种方案。

当然,除了这三种方案外,也有一些门槛相对低的方案,不想折腾的人可能会更感兴趣一些,所以我会在文末也介绍一下这些方法。

Huginn 简介

由于几个方案主要都是使用 Huginn 来实现的,这里简单介绍一下 Huginn。

huginn.png

Huginn 是一个 Ruby 编写的自动化工具,在理念上类似 IFTTT 和天国的 Yahoo! Pipes,即进行事件的监听然后根据预先设定的规则自动化地进行后续操作。

Huginn 的 wiki 上列举了一些典型的使用场景,如:

  1. Never Forget Your Umbrella Again: 下雨提醒
  2. Adding RSS Feeds to Any Site: 为任意网站生成 RSS 输出
  3. Follow stock prices: 监听股票价格

在 Huginn 中,主要有 event 和 agent 两个概念,agent 类似 IFTTT 里的 channel,event 则是 agent 的输出。在 Huginn 中可以将一个 agent 的输出作为另外一个 agent 的输入,由此产生复杂的自动化操作。

huginn_diagram.png

上图来自 Huginn:烧录RSS的神器 一文,该文对 Huginn 的使用做了很详细的介绍。

和 IFTTT 不同的是,Huginn 需要自己部署,很多细节需要自己定制,因此在使用门槛上会高很多。想尝试一下的话,可以参考文档一键免费部署 Huginn 到 PaaS 平台 Heroku 上,轻度使用的话足够了。

本文的目的并不是专门介绍 Huginn,如果读者想了解更多关于 Huginn 的内容,可以自行搜索、阅读文档和相关资料。

基于搜狗微信搜索的方案

搜狗微信搜索是一个开放的网站,同时又能获取指定公众号的最新文章,所以就成了早期的公众号文章转 RSS 的重要工具。

在搜狗微信搜索中,如果知道一个微信公众号的 ID,可以直接拼接出该公众号在搜狗微信搜索上的页面,以“经济学人”的公众号举例,其公众号 ID 是 TheEconomistGroup ,那么其对应的搜狗微信搜索页面就是 https://weixin.sogou.com/weixin?query=TheEconomistGroup ,访问这个页面,可以看到如下内容:

sogou_wexin_search.png

从最下方的“最近文章”处就可以解析出该公众号最新文章的标题和链接,因此基于搜狗微信搜索的方案,通过下面几个步骤来得到公众号的 RSS 输出:

  1. 解析公众号的搜狗微信搜索页面,获取最新文章的标题和链接
  2. 访问文章的链接,解析出文章的全文
  3. 输入包含文章标题、文章链接、文章内容的 RSS

看起来是比较简单的,然而这个方案在实际中却遇到了一个比较大的问题,那就是搜狗的反爬机制。大概是出于保护内容、流量的缘故,搜狗微信搜索虽然能够比较方便地访问到微信公众号文章,但我们通过它获得的文章链接,都不是文章的原始链接:2017 年的时候这个链接是一个有时效性的临时链接,这个链接在不到一天的时间内就会失效而不可访问,所以早期的方案都会在链接没有失效的时候先解析出全文,这样在 RSS 阅读器里直接就能阅读;而现在,这个链接是一个重定向链接,在重定向后才会得到一个临时的文章链接。

我个人没有办法解决链接重定向的问题,所以认为这个方案现在已经无效了,如果有读者认为该问题可以被解决,那么可以参考 Huginn教程:微信公众号 转换成 RSS 一文去尝试一下。

(已失效)基于即刻/快知和 RSSHub 的方案

即刻上线机器人功能后,用户就可以自定义微信公众号机器人来抓取任意公众号并生成一个主题了,而即刻的每个主题,又是存在公开 WEB 链接的,所以就可以用 Huginn 解析一个即刻的公众号主题页面,来获取一个公众号的文章列表更新了。而后来 RSSHub 又能直接输出一个即刻主题的 RSS,所以这个流程又能进一步简化一下,省略掉解析即刻主题页面这一步,直接从 RSSHub 输出的 RSS 中,进一步解析出公众号文章的原始链接并抓取全文了。

在即刻服务可用的时候,我就彻底抛弃了基于搜狗微信搜索的方案,因为基于即刻和 RSSHub 的方案一来可以获取文章的原始链接,二来在整体流程上比前者都更简单。

可惜的是,即刻也因为某些暂不了解的原因而停止服务了,不过依赖第三方服务服务会有这个下场我也是有心理准备的,后来就有了第三个方案。

在说第三个方案之前得说一下,现在有一个非常类似即刻的 APP 叫做快知,可以充当这个方案里即刻的替代品,唯一的差别是没有办法获得文章的原始链接,所以在 Huginn 中就少了一个文章直链获取的 Agent,见下图对比:

huginn_scenarios_comparison.png

目前基于快知的这个方案是可用的,如果想使用这个方案,可以有两种办法:

  1. 安装我的个人项目 zs 然后执行下面的命令来生成一个 Huginn Scenario 文件,然后在 Huginn 中导入

    zs-rss gen-scenario -t kz -n 晚点LatePost -i postlate --kz-topic-id k69QJvO82RKoA -o postlate.json
    

    命令参数解释如下:

    • "-t kz" 表示生成一个基于快知的 Huginn Scenario
    • "-n 晚点LatePost" 将这个 Scenario 命名为“晚点LatePost”,同时也设置了最后输出的 RSS 的标题
    • "-i postlate" 指定这个公众号的微信 ID,会用在最终的 RSS URL 中,比如这里指定的是 postlate,假设 Huginn 服务的域名是 https://myhuginn.com 那么最终的 RSS URL 可能是 https://myhuginn.com/users/1/web_requests/395/wx-postlate.xml —— 这里如果不在乎可维护性的话,不用公众号的微信 ID 也可以,给一个自己喜欢的英文 id 即可
    • "–kz-topic-id k69QJvO82RKoA" 这里指定“晚点LatePost”这个公众号在快知中的主题 ID,可以通过快知搜索到公众号后,分享链接到浏览器获得,比如“晚点LatePost”在快知中对应的主题链接是 https://kz.sync163.com/web/topic/k69QJvO82RKoA ,那么主题 ID 就是尾部那串符号 "k69QJvO82RKoA"
    • "-o postlate.json" 指定输出文件名,随意
  2. 直接下载我准备好的 Huginn Scenario 文件 kz_scenario_template.json ,在 Huginn 中导入后再修改其中的设置

基于快知的方案目前可用,但我并不看好这个方案,按照经验,这种做信息抓取的服务,总是存在风险的。

基于 EFB 和 Telegram 的方案

由于我一直使用 Linux 系统,工作中需要使用微信进行沟通的时候非常不方便,后来了解到 EFB 后就用它来把收到的微信消息转发到 Telegram,而 Telegram 是有 Linux 客户端的,这样我就能在 Linux 系统上查看微信消息了。

EFB 本质上是在服务器上登录网页微信,然后监听网页微信上的消息来做转发,只要不去搞什么自动回复机器人之类的,那么在使用 EFB 的过程中,所有通过 EFB 收到的消息就是微信上好友、关注的公众号主动发过来的消息,通过 EFB 发送的消息也都是以个人身份发出去的,总之是一个正常用户的正常行为,并不会有封号之类的风险。我使用 EFB 已经有两年了,除了偶尔需要重新登录一下,并没有遇到什么大问题。

使用 EFB 后可以在 Telegram 上收到我关注的公众号的更新消息,而 Telegram 的 API 丰富易用,完全可以写点代码把 Telegram 上收到的公众号文章更新收集起来再转成 RSS。于是在即刻停止服务后,我就开始摸索出了一套新的方案,大致流程是这样的:

  1. 写一个脚本,利用 Telegram 的 API,定时获取更新的公众号文章,并保存下来
  2. 在 Huginn 上新建一个 WebhookAgent,它会提供一个对应的 webhooks
  3. 将保存下来的公众号文章发往到 WebhookAgent,然后通过后续的其他 Agent 进行全文解析和 RSS 输出

一个完整的 Scenario 是下面这个样子的:

huginn_efb_scenario.png

这个方案的好处有:

  1. 不依赖除 Telegram 外的任何第三方服务,因此也不用担心反爬、服务停止等各种问题
  2. 能获得极低延时的 RSS 更新

不过相对的,这个方案的门槛也是最高的:

  1. 需要自己部署 EFB 和 Huginn,其中 Huginn 虽然可以免费部署,但 EFB 却不行,所以至少需要一个 VPS
  2. 需要熟悉 Telegram 的 API 并编写代码 —— 不过这块我已经做了,其他人有兴趣可以直接使用我的代码
  3. 需要一个能登录网页微信的个人微信号,而 2017 年 9 月份之后注册的微信号已经无法登录网页微信

这个方案的总体过程是这样的:

  1. 部署 EFB,可参考小众软件的文章:EFB 简明安装教程:用 Telegram 收发微信
  2. 在 Telegram 上新建一个频道,比如“微信.公众号”
  3. 与 EFB 机器人对话,将需要输出 RSS 的公众号链接到刚才建立的频道,如 "/link 晚点LatePost",这样该公众号的消息就会被 EFB 发送到这个频道了

    telegram_linked_channel.png

  4. 创建一个包含 WebhookAgent 的 Huginn Scenario,同样有两种方法

    • 第一种方法是安装我的项目 zs,然后执行下面的命令来生成 Scenario 文件

      zs-rss gen-scenario -n 晚点LatePost -i postlate -o postlate.json
      

      参数含义同之前生成基于快知的 Scenario 时一样

    • 也可以直接下载我项目中提供的 Huginn Scenario 文件 efb_scenario_template.json 然后在 Huginn 中导入

    创建好 Huginn Scenario 后,点击进入“微信公众号 Webhooks”这个 Agent,获取 webhooks 链接,比如:https://myhuginn.com/users/1/web_requests/318/4SXo3X2T2X7HCDjv

  5. 在 VPS 或某台能 24 小时开机的机器上上新建定时任务
    • 首先安装前面反复提到的我的个人项目 zs
    • 然后创建本地数据库,用来存储收集到的微信公众号文章更新

      zs-rss create-db
      

      这条命令会在 $HOME/.zs/data 目录下新建一个数据文件 rss.db

    • 在 $HOME/.zs/config 目录下新建配置文件 rss.json,写入刚才获得的 webhooks 链接,如

      {
          "huginn_webhooks": {
              "default": "https://myhuginn.com/users/1/web_requests/372/d742b76e",
              "晚点LatePost": "https://myhuginn.com/users/1/web_requests/372/4SXo3X2T2X7HCDjv"
          }
      }
      

      这个配置的意思是,公众号“晚点LatePost”的更新发送到一个 webhooks,其他的发送到另外的 webhooks。如果每个公众号都要输出一个 RSS,那么就需要为每个公众号都设置一个 webhooks 链接;如果有多个公众号想要合并输出一个 RSS,那么可以不设置 webhooks 而使用 default 对应的 webhooks。

    • 使用 crontab 新增两条定时任务

      7,17,27,37,47,57 * * * * zs-rss fetch-wx-articles -n 微信.公众号 >> log.txt
      */10 * * * * zs-rss send-wx-articles >> log.txt
      

      具体的时间频率可以自己调整。

      其中第一条定时任务需要 Telegram 的授权认证,具体来说是需要在 $HOME/.zs/config/telegram.json 中有如下内容

      {
          "api_id": "561071",
          "api_hash": "22691769c5decd501fd49d96ecff58e3",
          "session": "AUTHENTICATION SESSION CODE"
      }
      

      其中 "api_id" 和 "api_hash" 可以在 https://my.telegram.org/ 上获取,而 session 的值会在第一次运行时生成并自动写入到上面的配置文件里。

目前 zs 这个项目仅考虑了我自己的需求,所以设计未必很合理,如果有开发能力的话可以参考我的代码自行更改、增加功能。

其他参考方案

如果不想折腾,也有一定的经济来源,可以考虑一些付费服务,比如:

  1. 今天看啥:以前可以免费订阅若干个公众号的,现在必须付费了,价格见今天看啥-RSS订阅方法
  2. WeRss:免费试用三天,试用期间可订阅 8 个公众号,具体价格见WeRss 付费价格

另外,Kindle4rss 上面有不少热门的微信公众号全文 RSS,我大致数了下差不多有 100 个,如下图所示:

kindle4rss_feeds.png

Kindle4rss 的免费用户可以有 12 个订阅,付费价格也不贵,一年 36 人民币就可以订阅 300 个源,比前面两个便宜多了,而且这个服务存在很多年了,可以说一直很稳定,非常推荐。

此外 RSSHub 也有微信公众号支持,见文档。在 RSSHub 里支持了六种方案,分别是:

  1. 基于 WeMP 的方案
  2. 基于传送门的方案
  3. 基于北美生活引擎 CareerEngine 的方案
  4. 基于微信公众号数据分析平台二十次幂的方案
  5. 基于知识管理工具优读的方案
  6. 基于 EFB 和 Telegram 的方案

RSSHub 的前五个方案都是基于一些第三方信息抓取服务的,相对来说非常易用,但仍然存在第三方服务被关停的风险,最后那个方案和我的第三个方案类似,只不过把 Huginn 替换成了 RSSHub。

后记

也许有人会说微信就是个大毒瘤我就不看微信公众号,但确实有一些很好的作者只在微信公众号上写作,还有很多博客时代的知名写作者也迁移到了微信公众号上,原来的博客不再更新甚至不可访问了,加上微信生态的封闭,所以一个微信公众号文章的抓取和开放访问需求始终是存在的,也因此各种第三方抓取服务层出不穷。厌恶微信到完全不想碰微信产品包括微信公众号的人自然是有的,但既然大众的需求存在,我想也没什么好争辩的,每个人都有自己选择的自由。虽说如此,在看到一个好的公众号的时候,也不妨先去了解一下作者是否有同步更新的独立博客或知乎专栏,如果有的话还是更推荐去订阅其博客或知乎专栏等更开放的文章来源。

我制作的微信公众号RSS(2)

上一篇文章一样,都是全文 RSS,罗列如下:

公众号名称 RSS 链接 简介
晚点LatePost https://feedpress.me/wx-postlate 《财经》杂志与小晚团队推出的商业新闻媒体
深响 https://feedpress.me/wx-deep-echo  
看理想 https://feedpress.me/wx-ikanlixiang  
华山感染 https://feedpress.me/wx-hsinfect 张文宏所在的华山医院感染科的公众号
民俗学论坛 https://feedpress.me/wx-folklore-forum 中国民俗学会的公益学术公众号
LCA https://feedpress.me/wx-lca “热爱生活 喜欢文化 关注艺术”
余晟以为 https://feedpress.me/wx-yurii-says  
老顾谈几何 https://feedpress.me/wx-conformalgeometry  
观人看世界 https://feedpress.me/wx-iwatch1024 “传递认知,让你看到我眼中的世界”
笔下求生 https://feedpress.me/wx-tmt-invest “互联网分析师,CFA,在某创业公司扫地”
筹码 https://feedpress.me/wx-chouma2016 “认知是唯一的筹码”
艾格吃饱了 https://feedpress.me/wx-aigechibaole 美食类公众号
碗丸食事 https://feedpress.me/wx-foodfile-111010 美食类公众号

其中 LCA 是网友在上一篇博客的评论中推荐的。

注:若公众号作者看到本文认为我制作的 RSS 侵犯了版权还请告知我,我会关闭全文输出。

我制作的微信公众号RSS

都是全文 RSS,罗列如下:

公众号名称 RSS 链接 备注
AINLP https://feedpress.me/wx-ainlp  
CatCoder https://feedpress.me/wx-catcoder 微广场作者的个人公众号
LateNews by 小晚 https://feedpress.me/wx-latenews  
L先生说 https://feedpress.me/wx-lxiaoshengmiao  
ResysChina https://feedpress.me/wx-resyschina  
中文信息学报 https://feedpress.me/wx-jcip1986  
六神磊磊读金庸 https://feedpress.me/wx-dujinyong  
利维坦 https://feedpress.me/wx-liweitan  
哈工大SCIR https://feedpress.me/wx-hit-scir  
孟岩 https://feedpress.me/wx-dreamytalks  
安静的书桌 https://feedpress.me/wx-quiet-desk  
MorningRocks https://feedpress.me/wx-morningrocks  
微软研究院AI头条 https://feedpress.me/wx-msrasia  
程序媛的日常 https://feedpress.me/wx-girlswhocode  
视觉求索 https://feedpress.me/wx-thevisionseeker  
语音杂谈 https://feedpress.me/wx-yyzt  
长赢指数投资 https://feedpress.me/wx-chinaetfs  
单读 https://feedpress.me/wx-dandureading  
大象公会 https://feedpress.me/wx-idxgh2013  
呦呦鹿鸣 https://feedpress.me/wx-youyouluming  

读者如果有好的公众号可以推荐给我,我感兴趣的话会去为其制作 RSS。

数字独立与自由

1996年 的时候,电子前线基金会的创始人之一 John Perry Barlow 发表了《数字空间独立宣言》,在宣言中,他说道:

Governments of the Industrial World, you weary giants of flesh and steel, I come from Cyberspace, the new home of Mind. On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather。

在这份宣言中,John Perry Barlow 宣称数字空间是无国界的,是一个不在所有政府的疆界内的自由的空间,是一个人人可以表达自己的信仰和思想的新世界,并拒绝政府以解决现实世界问题的借口来侵犯这个空间。当时持这种态度的人不少,比如说 RSS 发明人、Markdown 作者之一的 Aaron Swartz,但最终,他死于捍卫网络世界的自由,年仅 26 岁。

从 Aaron Swartz 自杀到现在,我们已经可以清楚的知道,数字空间并非天堂,并没有真正地把人类的心灵都联结起来。跨国界的自由,似乎也没有真正地实现过,各个国家都建起了自己的围墙,并以反恐等各种名义监视着每个数字空间里的个体;与此同时,数字空间里的住民们,也在这种畸形的环境里,展现出了很多丑陋的姿态。

深受以 Aaron Swartz 为代表的早期互联网先驱们影响的我们,该如何面对这样一个世界呢?作为一个技术人员,最好的形式,当然是利用自己的技术能力来让这个世界变得更好一些,然而这个世界的复杂性有很大一部分其实来自于人性的复杂,在行动的同时,我觉得,我们也应当进行更多的思考和讨论,本文就是我对相关问题的一些思考的记录。

大体上,我仍然是抱持数字空间独立与自由理念的,但在当下的大环境里,谈论整个数字空间与现实世界的独立,似乎已经不太现实,我更想谈的是,个人在数字空间中,如何保持独立与自由。如果每个个体,都能对自身在数字空间中的权利与义务有足够的认识,我相信即使技术没有得到革新,这个世界也会有很大的改观。

要谈独立与自由,那就得了解我们在数字空间中有哪些权利和义务。由于各国相关法律也并不统一,数字空间内所有人也并没有形成共识,下面的一些内容,仅仅是参考了一些相关资料后我个人的想法。

首先,最基本的权利是互联网接入权。

2009 年 10 月 14,芬兰交通运输部宣布互联网访问权成为法定权利,从 2010 年 7 月开始,芬兰公民将具有至少 1Mb/s 带宽的互联网访问权利,并计划在 2015 年将这个带宽下限提高到 100Mb/s,这应该是第一个将互联网接入权写入到法律里的案例。在这之后,很多国家以成文或不成文的形式承认这个权利。从现实世界来看,我们想要接入到互联网,似乎是轻而易举的事情,但是这个权利仍然面临如下威胁:贫穷导致一部分人无法支付宽带接入的费用、被滥用的监管导致每个人都可能被断网。一方面我们应当努力去促成合理、完善的法律法规的产生,另外一方面我们也应该在法律法规完善并且能被正确实施前,掌握足够的方法和工具来保障我们的权利。

另外,并不是我们能上网,我们的互联网接入权就得到保障了。重点是,我们应当可以接入世界互联网,而不是一个受限的局域网络;再更进一步,接入网络后,我们还应当具有自由地访问网络上的内容的权利。而这些延伸的权利,同样也受到很多威胁,当我们访问的文章、网站显示 404、被屏蔽或者被删除时,我们应该要意识到,在那一瞬间,我们的权利被剥夺了。

其次,我们应当享有在数字空间上的言论自由权利,可以在网络上自由地表达自己的观点,也可以自由地创作文字、音频、视频等各种形式的作品。这份权利受到的威胁,我想有不少人是深有体会的,比如说发表的言论其他人完全看不到、创作的文章不被允许发表或被删除,有些人甚至因为在网络上的言论而导致现实中的人身权利受到威胁。一个理想的数字空间,当然是大家都可以堂堂正正地发表自己的言论,互相碰撞并求同存异,但在现今这样恶劣的环境里,我们也得考虑通过一些方法和工具来保障我们的言论自由权利,比如说脱离对垄断平台(如微信)的依赖,或在恶劣环境中隐匿自己。

第三,我们应当享有在数字空间中的隐私和安全权,个人身份信息、个人数据都应该被保护,在未经个人允许的前提下,任何其他个人、机构,都不应该访问、利用我们的个人身份信息和个人数据。对于这点,很高兴看到欧盟《一般数据保护条例》(General Data Protection Regulation, GDPR)的通过和施行,但如果我们并非身处 GDPR 作用范围内的地区,那么,在现实世界的法律法规并未完善时,我们还是得时刻谨记自己享有这份权利的正当性,并在这些权利受到侵犯时奋力抗争。

在个体角度上,我并不信任大部分的法律、平台,或者说,出于对上述数字权利的敏感,必须得带着怀疑的目光看待所有可能侵犯这些权利的个体或者机构。为了保障我们的数字权利,我认为我们必须提高自身的认知、实践总结相关的方法并利用好一切能利用的工具。

所谓的提高认知,包括但不限于:

  1. 理解互联网的构成和原理
  2. 了解现实世界与数字权利相关的法律法规
  3. 认识数字空间中信息传播规律、群体构成等社会规律
  4. 建立数字空间中的权利意识和道德观念
  5. 掌握基本的信息搜集和甄别能力

保障我们数字权利的方法和工具,则可能有下面这些:

  1. 数据加密的方法和工具
  2. 突破互联网封锁的方法和工具
  3. 数据备份与恢复的方法和工具
  4. 信息搜集和筛选的方法和工具
  5. ……

我计划在未来的几年内,阅读更多相关的书籍和资料、积极思考,以此提高自己的认知水平,同时实践相关的方法和工具。除此以外,还准备为如 EFF、GNU 这样符合我个人价值观的机构或组织贡献一点个人的力量,比如更积极地参与开源项目、定期捐赠、传播相关理念等。也欢迎志同道合的朋友的交流和补充。

通俗化解释GFW工作原理

场景约定

先对用户上网行为中的一些实体或行为做以下约定:

  • A镇:中国互联网

    A镇是一个小镇子,四面环山、风景优美,人民淳朴善良、勤劳勇敢。

  • 镇外:国外互联网

    镇外有很多繁华的城市,丰富多彩的商品。

  • 居民:客户端(PC/智能终端等)

    居民是A镇的居民,他们每个人都有一个家。

  • 商店:网站

    居民们经常需要购买一些东西,这些东西就要到商店里去买,镇里镇外都有商店。居民一般是不能自己卖东西的,如果要卖东西,要经过工商局的许可,还要注册一个商店名称。

  • 商店名称:网站域名

    每个商店都有一个独一无二的名称,绝不重样。

  • 具体地址:IP

    每个居民的家以及商店都有一个具体的地址,如:xx街道xx号。

  • 购买:网络连接

    购买就是购买,可以购买镇内的东西,也可以购买镇外的东西。购买东西的时候,商店通常都会记下购买者的地址和对方购买的商品列表。

  • 管家:浏览器

    (实际上这个比拟不恰当,请不要深究)

    居民们很忙,没有空自己去买东西(有的商店也很远),所以居民们把购买的事情交给管家去做,通常只告诉管家 商店名称要买的东西

  • 道路:路由

    管家是走路去的商店的,有的也开车,但是这个世界没有飞行器。

  • 路口:路由器

    镇上道路四通八达,到达一个目的地有很多种走法。在每个路口都有路标,指示各个方向可以到达什么地方,比如说有一个路口的路标上有这么一句:

        向左拐可以到山麓百货商店
    

    当然,其实向前走也可以,总之随便走,取决于管家对道路的熟悉程度了。

  • 交警:DNS服务器

    管家有时候会不知道商店在哪个位置,不过没关系,他可以去问交警,交警博文强识、乐于助人,会告诉管家商店的具体地址的,然后管家就可以乐呵地去目的地了。

  • 谨慎购买:TCP连接

    有些居民怕买东西上当,因为毕竟不是自己去嘛,所以又无情地压榨老管家的劳动力了(打倒资本主义!)。这是居民会先让管家按照某种规定和商店进行交流(TCP三次握手),确定商店是可信的并且让商店也信任居民后,就可以进行谨慎购买了。这后面居民买东西时,就不用再报上自己的信息了,售货员暧昧地看了一眼老管家就知道,唔,又是这个家伙。而且,售货员会细心检查商品看有没有质量问题。

    在这种购买方式要结束时,居民会让老管家和商店说一声,这样商店知道这货不会再来买东西了。

  • 切口:TCP三次握手

    在进行谨慎购买时,要对交换三次密文,用来对答切口,确定对方是否可信任。

    1. 第一次,管家带着用明矾水写的密文前往商店,上面写着:

             天王盖地虎
      
    2. 到达商店后,售货员解读了密文后,也用明矾水写一张密文,内容是:

             宝塔镇河妖
             地振高岗,一派溪山千古秀
      

      第一句是回应管家带来的切口,第二句则是要求购买方对答的切口。

    3. 管家把密文带回居民家中,居民解读出密文,再制作一张密文,内容为:

             门朝大海,三河合水万年流
      

      再让管家带过去,这时候售货员和居民都可以确定了:唔,自己人!

  • 随意购买:UDP连接

    谨慎购买太麻烦了,所以有些人喜欢随意购买这种方式,告诉管家要买什么东西,到商店里拿了付钱走人就完了。不过这种情况,售货员不会帮管家检查商品质量,买回去有可能是次品(退货这种事情这里就不讨论了)。

GFW(Great Firewall,中国互联网防火墙)

话说小镇是一个社会主义小镇——至少小镇管理委员会是这么说的,本来吧,小镇生活挺清苦的,后来有一任镇长看不下去了,就发动了代号为”改革开发“的运动,打通了一条通往外界的道路,从此小镇日新月异,蒸蒸日上。

但是开放有开放的问题啊。万恶的资本主义趁机侵入了小镇。

小镇管理委员会也很无奈啊,首先吧,确实需要万恶的资本主义商店来提升小镇的GDP;其次吧,没有万恶的资本主义商店,委员会的公仆们到哪里去买好吃的好玩的来调养身心为小镇建设做好身体和心理的准备呢?

可是你们这些资本主义商店,我们高等的社会主义小镇给了你们为我们小镇贡献GDP和表现自我的机会,除了感恩戴德之外,怎么还把 自由民主 之类的违禁品卖给我们淳朴善良的居民们呢?什么,你说那不是坏东西?我们说是就是!

于是,在小镇召开的第十九届全镇代表大会上,代表了全镇居民们的代表们设立了 小镇安全委员会 并制订了代号为 GFW 的计划,并交给了小镇第三中学的方校长来执行。可怜的方校长不过是执行者,从此却被激进无脑的小镇居民恨之入骨,人家雨果不是说过了嘛:有罪的不是犯罪的人,而是制造黑暗的人。这就和一个色狼用手骚扰了地铁上漂亮姑娘之后,法庭宣判“判当事人的右手性骚扰罪成立”一样可笑嘛,不过随便了,小镇的人们太淳朴了,大智若愚,大愚若智啊!!!

GFW 计划具体有什么内容不得而知,从目前得到的信息来看,该计划至少包含以下三部分:商店封锁计划、交警催眠计划和商品清单审查计划。

商店封锁计划(IP黑名单)

这个计划是这样的,对于一些不法的商店,直接封锁起来,谁也进不去——老管家当然进不去了。

当然这个计划是有漏洞的,因为很多商店是连锁的呀!比如说谷姐百货,那连锁规模,都快赶上垃圾食品连锁店肯德鸭了。

交警催眠计划(DNS劫持)

之前说过了,老管家是会向交警去问路的。交警催眠计划呢,就是把交警催眠了,当管家问”谷姐百货怎么走“时,交警就会告诉他一个错误的地址。老管家被压榨得太久了,脑袋不灵活啊,交警告诉他怎么走,他就怎么走,结果走到那个地方一看,好家伙,只看到满地的残骸,还有那摇摇欲坠的危墙上大大的一个 字。

老管家很郁闷,回家告诉居民:主人啊,找不到地址啊,说不定是个皮包商店呢。

这种手段主要用于防止管家到镇外去买东西,因为通往镇外的路只有一条,把那条路上的交警催眠了就OK。

镇外的世界啊,水深火热啊,不要去的好。

对于镇内的商店,主要是用商品清单审查计划,当然,现在对镇外的购买行为也开始使用这个了,因为有些镇外商店还是不错的,违禁品比较少,稍微审查一下就好了。

商品清单审查计划(内容审查)

这个计划是这样的。 小镇安全委员会 派出了很多隐形人,偷窥到了老管家身上带的商品清单,如果居民的商品上有违禁品,隐形人就会报告 小镇安全委员会 ,委员会会派出一个人伪装成对应商店的售货员,告诉老管家,”老管家啊,你这个东西我们这里没有“或者”老管家啊,你这个清单格式不对啊,结尾要加上'此致敬礼'啊“之类的。

老管家头脑不是不太好用嘛,就回去了。

后记

写这个东西,是为了向非专业人士解释一下 GFW 的工作原理,为以后向他们传播相关安全知识做个准备。

另外,我的某个老大跟我说过,你要能把事情跟别人说明白才能说明自己是真的懂了。大概就是这么个意思。

后面我会讲一下突破 GFW 的常规手段。

❌