如何将友言的评论导入多说

2016/11/18

本文原创作者:Cloud Chou. 欢迎转载,请注明出处和本文链接

无法将友言评论备份或者迁移的朋友们有福了,我先前也和大家一样苦恼评论数据的丢失,最近终于将友言的评论数据迁移到了多说,接下来我和大家分享一下我是如何做到的。

背景

先前用WordPress写博客时,选择用友言这个社交化评论系统,当时友言和多说势均力敌。后来友言被加JiaThis收购,友言的维护就大不如从前了,和客服反馈了无法显示评论数的问题,客服一直没搭理,客服好像一直都没上线过,当时也没有很上心去解决这个问题。

直到最近决定将博客系统从WordPress迁移到Jekyll,才决定解决这个问题,本想着只需要简单的将友言的评论数据导出来。然后再导入多说就可以了,没想到在备份时界面一直提示后台在生成备份文件,但是一直都没备份完,怎么操作都没用。后来用Chrome的开发工具调试了一下,才知道后台接口已经500了,在网上搜了一下,发现不少同学遇到和我一样的问题,觉得还是很有必要将这个问题解决。

由于友言评论的数据备份格式以及展示数据并不包含所有评论信息,导致本方案还存在一些问题,如下所示。

解决方案存在的问题:

  1. 无法备份评论用户的头像,社交平台信息, 因为数据备份格式不支持这些信息
  2. 无法备份评论时间的年信息,也就是说无法准确直到是哪年评论的,因为在评论展示页面只显示了是月和日的信息,不过本方案在将数据导出后,可通过博客的的发表时间信息来对评论时间进行修正,让评论时间尽量接近博客的发表时间

本方案能导出的友言评论信息有评论用户名,评论时间(虽然不是很准确),评论内容,评论哪篇文章,评论和评论的父子关系。

执行环境要求:

  1. 需要安装Python 3.5+,并将Python安装目录和Python的Scripts目录添加到Path环境变量里. 如图所示:

    环境变量

  2. 使用Pip安装requests库,beautifulsoup,demjson,安装命令如下所示:

    pip install requests beautifulsoup4 demjson
    

requests是非常强大的网络请求库,使用该库可以模拟用户登录,自动管理Cookie,爬取页面; 有了beatifulsoup,访问html元素也非常简单;demjson 用于组织成json数据,还可以直接保存到文件,或者将文件里的json数据转换成内存词典对象

操作步骤

  1. 克隆我的脚本仓库:

    1
    
     git clone  https://github.com/cloudchou/PythonScripts
    
  2. 在cmd下进入到下载目录执行脚本UyanCommentBackuper.py

    1
    
    ./UyanCommentBackuper.py
    
  3. 根据提示输入用户名和密码,确定后会告诉你正在执行的备份操作,最终会提示你备份成功,并告诉你数据备份文件的名字,你可以打开看看

如果你也和我一样使用Jekyll,那么可以对备份文件内的评论时间进行修正,否则所有评论时间都是2016年。前提是你的博客文章里包含类似于下面这样的元数据,修正时间时会利用permalink数据和date数据

1
2
3
4
5
6
7
8
9
10
11
12
13
---
id: 982
title: 如何将友言的评论导入多说
date: 2016-11-18T19:34:42+08:00
author: cloud
layout: post
guid: http://www.cloudchou.com/?p=982
permalink: /android/post-982.html
categories:
  - work
tags:
  - work
---

如果你的博客有类似上面的元数据,可以使用下面的步骤修正评论时间:

  1. 修改GetBlogPostTime.py脚本, 将其中的blog_dir变量替换成博客文章存放的目录
  2. 执行GetBlogPostTime.py脚本获取博客发表时间数据,执行成功后会将文章和对应的发表时间等信息输出到posts_time.json
  3. 执行CorrectCommentTime.py修正评论时间
  4. 在多说的管理后台将友言评论数据导入
  5. 恭喜你终于将友言的评论导入到了多说

方案选择背后的故事

我们不能直接访问友言的后台接口,只能访问展示的评论数据,这样我们只可以将展示出来的评论数据按照数据备份格式导出来,通过这种方式进行备份。可选方案有两种:

  1. 编写浏览器插件
    手动登录后,浏览1页评论就通过插件导出来1页,手动导出所有评论数据后再进行合并。当然也可以1次全部导出来,自动进行分页跳转,但是实现起来会更麻烦一些。

  2. Python爬虫
    通过python爬虫技术实现登录,然后读取所有分页的评论数据,再转换友言的数据备份格式

第1种方案对于我来说会更复杂一些,涉及多个没接触过的技术点,包括浏览器引擎如何执行Js,插件跨页面访问,插件导出数据到文件系统,如何编写插件等等。

而第2种方案其实是听同事介绍的,了解到python爬虫技术模拟用户登录非常简单,解析html元素也非常简单,还能自动管理cookie,有了这3点的保障,第2种方案有更好的可执行性,能更快速地实现这个需求。

先前以为用python爬虫技术不能做登录,只能爬取简单页面,

方案实现过程中遇到的那些坑

  1. 在用Chrome的开发者工具Network面板观察网络访问时,需要勾选Preserve Log,否则页面多次跳转时,无法看到中间跳转过程中任何页面的访问,所以如果登录时有多次跳转你就找不到实际登录时访问的html页面。第1次看到这个选项时,以为和日志有关,所以被误导了,就没勾选,所以导致找登录页面花了不少时间
  2. 用python的request库登录友言时,以为只要在登录页面模拟登录就可以了,但实际上不可以获取任何评论数据。 通过在chrome登录并用开发者工具观察到在登录页面模拟登录后,服务器返回的数据包含3个让浏览器跳转的页面,才知道一定要访问其中的两个跳转页面才可实现真正登录。也是通过Chrome的开发者工具观察到有1个JS脚本可以用于校验是否已登录,先前都不知道到底是登录问题还是别的问题导致无法获取评论数据
  3. python 3.5的一些新特性及语法, 比如 with as结构,’**‘参数的用法(其实就是个字典,调用时用变量名+’=’+值,例如indent=2,并且可传递多个这样的元素),以及’**‘实现字典合并的用法(比如假设dict是1个字典,{*dict,”test”:2}),’‘参数的用法(可以传递多个参数,但是直接传值,不能以字典形式传参)
  4. demjson格式化数据时,需指定两个参数indent_amount和compactly=False,否则输出的数据并不是格式化的数据
  5. 在python里写正则表达式模式时,需用 \s形式,而不是%s形式,我经常弄错
  6. request的session可以帮我们自动维护cookie,不需要另外维护构建cookie参数,传递给session的get方法或者post方法,如果需要持久化cookie的话,也可以从session里取出cookie做持久化

总结

不得不感叹,互联网真的是变化好快,当时友言也是挺火的一个评论系统,现在成了这个样子,而多说也没那么多人维护了,论坛里各种水贴,不知道是因为没有找到好的盈利模式还是别的原因。大家觉得这种类型的互联网项目是否可以通过开源+赞助的形式生存呢? 只需保持少量维护人员就好。 我觉得这种评论系统对于个人博客的博主来说还是挺有用的。

经过这次折腾,我收获到的经验教训有:

  1. 做事前一定要先调研 ,找到可行的多个方案,分析各个方案的优缺点,并根据需要选择最合适的方案

    比如这次选择方案时有找到两种方案,浏览器插件方案对于我来说有很多不确定的点,最重要的是不确定JS能否跨多个页面收集数据,如果系统学习浏览器插件开发原理需要很长时间,而Python爬虫方案确定可以很简单的实现3个方面的需求。对于我来说,目前最重要的是快速实现评论数据的备份,而不是学习前端开发知识,所以第2个方案最适合我。

  2. 调研时应尽量用最小的代价和最少的时间来验证方案可行性,打通关键环节

    这次在这方面做的不是很好,我应该要先确定友言的评论数据是否能导入多说的,在我将友言评论数据导出后,第1次导入到多说时,竟然出现404问题,怎么尝试也没用,幸亏后来多说有修复这个问题,不然我花这么多时间做的评论数据备份功能就白做了。所以在事前调研阶段,我已经了解到多说缺少维护的情况下,应该先构造一份简单的评论数据来进行验证,看多说是否还支持评论数据的导入,通过最小代价验证方式可以避免某些时间白花了。

  3. 写代码应先写架子,后实现架子的各个步骤

    先将功能实现拆分成多个步骤函数,然后再一步步实现各个步骤函数,也就是说先看大局,再进入细节,可避免忘记大局的步骤

  4. 一门编程语言应尽量频繁使用才可避免日久生疏

    其实先前早就学过并使用过python,只是做了一些简单任务,现在已经很久没用了,所以非常生疏,对Python 3的新特性也不了解,编程语言还是得在某个阶段里常用才不至于生疏,可以在某个阶段完成任务时尽量用同一门编程语言,以达到熟悉目的。不要在多门编程语言之间切换来切换去,这样的后果是没有哪门语言是熟悉的,每次写都会非常慢。Python 3在中文编码的处理方面比Python2强太多了,以后不要再使用Python 2了。

  5. 积累并整理自己的代码库很重要

    可以积累各门编程语言的代码库,脚本有脚本代码库,Android,C++,Java后台等还需要各自积累一套快速开发框架,以便后续开发某个项目时能快速开发出来

  6. 学习技术不可浮躁,API文档需要静下心来看

    这次写Python代码时, API文档没有仔细看,导致用demjson做json代码格式化时花了不少时间,没有注意到需要设置compactly=False,还有在re.sub函数上老是花很多时间做匹配,也是因为没有仔细看API文档,做技术的同学还是得静心修炼,浮躁不得

  7. 调试代码永远比通过多次尝试进行验证要快得多

    Python是支持调试的,调试代码永远比通过多次尝试进行验证要快得多,因为调试时可看到所有变量的值,可以很明显地看出来问题出在哪,而多次尝试是凭猜测,猜测问题当然没有分析问题得到的结论准确,所以尽量使用调试代码的方式来解决问题把

  8. Sublime Text不适合写Python脚本,PyCharm更适用

    本想将Sublime Text打造成1个超级IDE,用来开发简单脚本,包括python脚本等等,但是经过这次折腾才发现Sublime Text并不适合做这种事情。有好几方面原因,Sublime Text不支持调试Python脚本,分析问题很麻烦,不支持变量重构,print输出不支持中文,打印中文竟然没有任何输出,连乱码也没有,会让开发人员误认为代码没执行,不支持一键回到上一个编辑的地方,这个也非常不爽。而PyCharm有这所有的功能,所以PyCharm更适合写Python脚本,而SublimeText适合那些没有专门的IDE的编程语言,比如Shell,比如写博客,前端HTML,JS,CSS等语言的开发,这才是它的领域,它最强大的地方只是可以多处编辑,另外还有它的扩展性。后续开发时,应尽量选择最适合的编辑器,而不是牵强地改造Sublime Text。

  9. 目前Windows的Docker不适合用来做NodeJs,Jekyll博客的开发运行环境

    虽然可以用Windows Docker搭建Node Js代码或者Jekyll博客运行时环境的镜像,然后将Node Js网站代码或者Jekyll博客网站挂载到Docker的Container上,确实可以运行Node Js程序或者查看博客网站, 但是存在一个致命的问题是我们在Windows内修改博客内容或者NodeJs代码,Docker Container是不知道这个事情的,所以不能自动重新生成博客内容网站,也不能自动更新NodeJs的服务内容,Github上有方案用nodem进行包装来解决这个问题,但是我尝试之后发现无效,而Docker的维护者说这个问题的解决需要等Samba团队的人来实现在Windows上的文件系统的inotify机制,所以目前docker还不完善,不适合做这种运行环境,用Docker打造前端开发环境的计划只能暂时搁浅了。

  10. 隐式强类型语言的程序开发,文档提示真是太差,还是Java好

    python开发时, 不需要声明变量的类型,同一个变量可以向不同类型的对象,看起来非常方便,但是问题也随之而来,因为不知道变量的类型,所以IDE没法推导变量的类型,也就不知道变量有哪些方法,哪些属性,所以没法智能提示,经常不知道变量的方法及如何使用,只能查参考文档,这方面和Java这种显示强类型语言相比还是差了很多。

¥打赏5毛

取消

感谢您的支持,我会继续努力的!

扫码支持
赏个5毛,支持我把

打开支付宝扫一扫,即可进行扫码打赏哦

本篇目录