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

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

背景

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

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

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

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

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

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

使用Pip安装requests库,beautifulsoup,demjson,安装命令如下所示: bat pip install requests beautifulsoup4 demjson > requests是非常强大的网络请求库，使用该库可以模拟用户登录，自动管理Cookie，爬取页面; 有了beatifulsoup，访问html元素也非常简单；demjson 用于组织成json数据，还可以直接保存到文件，或者将文件里的json数据转换成内存词典对象 操作步骤 克隆我的 脚本仓库 : bash git clone https://github.com/cloudchou/PythonScripts

在cmd下进入到下载目录执行脚本UyanCommentBackuper.py ```bash ./UyanCommentBackuper.py

```

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

如果你也和我一样使用Jekyll，那么可以对备份文件内的评论时间进行修正，否则所有评论时间都是2016年。前提是你的博客文章里包含类似于下面这样的元数据,修正时间时会利用permalink数据和date数据 --- 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次全部导出来，自动进行分页跳转，但是实现起来会更麻烦一些。 Python爬虫
通过python爬虫技术实现登录，然后读取所有分页的评论数据，再转换友言的数据备份格式

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

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

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

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

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

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

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

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

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

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

写代码应先写架子，后实现架子的各个步骤

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

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

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

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

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

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

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

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

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

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。

目前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打造前端开发环境的计划只能暂时搁浅了。

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

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