php如何抓取网页数据库(1.实现前的思考(图)评论系统的改版 )

　　php如何抓取网页数据库(1.实现前的思考(图)评论系统的改版

)

　　关于如何实现楼内评论系统的具体操作1. 实施前的思考

　　经过一番讨论和网易云话题，我终于下定决心自己写一个评论系统。

　　在我们使用的众多评论系统中，最流行的是楼内楼，如*敏*感*词*、wordpress等。在此之前，1、2、3层一般是按时间顺序展示的。如果要回复某人，请使用@符号标记用户名，然后回复内容。但是，这有一个很大的问题。讨论问题不集中，其他用户不知道你在讨论什么。原作者在一楼发表评论。当你进来回复这个用户的评论时，已经是10楼了。作者再次回复你到20楼。其他网友看到10楼的时候，已经忘记了原作者说了什么。

　　

　　*敏*感*词*在改版之前就使用了这个方法，后来在新版本中启用了build方法里面的build。这样，就可以集中讨论某个话题。

　　

　　同时，知乎也对自己的评论系统进行了修改，但并没有将其重新设计成楼中楼，而是在每条评论后添加了一个弹出链接，并带有一个对话来查看对话，并且点击链接后会弹出一个弹窗。可以看到关于这两个人互动的所有评论。

　　按时间倒序显示评论或按正序平铺很容易实现，但难以阅读。分门别类地显示评论对用户的阅读习惯很友好，但可能难以实现。不过最后还是决定采用楼内建房的方式。虽然我博客的评论数也很差，但我还是决定实现它。

　　2. 数据表设计

　　先说一下前后端使用的语言和框架。考虑到页面渲染和更多的事件调用，前端使用vue框架。应该说vue并不是最好的选择。毕竟，对于一个评论前端的部门来说，这可能有点矫枉过正。，但是为了快速发展，也选择了vue。后端使用php语言，数据库使用mysql。

　　数据库表的设计既考虑到了以前数据的导入能力，也方便以后添加新的评论。这里我创建了 3 个表：文章 表、用户表、评论表。

　　在网易云线程关闭之前，导出了自己的数据（我说的数据已经丢失，不知道导出的格式是什么），我们来看看网易云中导出的数据的格式线：

　　

　　

　　从上面的数据可以看出，每个文章都有一个title、url和comment，每个comment都有自己对应的id、reply的comment pid、content content、comment的user。用户名、昵称和头像。这里我只提取主要信息并输入到数据库中。

　　2.1 用户表

　　用户表比较简单。原来的userid也要保存为字段，以便在导入评论数据时可以找到对应的用户。评论数据也导入后，可以删除该字段。新添加的注册用户不使用该字段。用户表设计：

　　字段类型说明

　　ID

　　整数

　　自增，主键

　　宽

　　整数

　　用户的原创用户标识

　　昵称

　　varchar(50)

　　昵称

　　头像

　　varchar(100)

　　阿凡达

　　状态

　　整数

　　健康）状况

　　设计好用户表后，将原创数据中的所有用户分别取出，然后以userid为key存入数组，也可以起到去重的作用。将获取到的所有用户数据存储在用户表中

　　2.2 评论表

　　在设计意见表时，主要考虑以下因素：

　　评论必须依赖文章和用户才能存在，所以评论的外键是文章ID和userid，留言板是文章内容为空的评论表单；

　　我想以后新的评论可以使用自增id而不是跟随原评论的cid生成新的评论id，所以这次评论表的主键是id，原评论id是仅用作字段宽度之一。构建建筑物与建筑物的关系，这些旧评论插入数据表时会有新的评论id；

　　楼内楼的评论在某条评论下，同时楼内楼内有互动回复。因此，这条评论的pid（parentid）表示当前评论在哪条评论下，replyid表示正在回复的是哪条评论；如果直接回复父评论，则pid与replyid相同，都是父评论的id。不是父评论，pid是父评论的id，replyid是回复评论的id；当pid或replyid为0时，表示评论直接发到文章。

　　所以我们的评论表单是这样设计的：

　　字段类型说明

　　ID

　　整数

　　自增，主键

　　宽

　　整数

　　注释掉原来的主键 cid

　　uid

　　整数

　　用户身份

　　回复人

　　整数

　　评论回复的评论id，否则为0

　　PID

　　整数

　　评论的父 id，如果不是，则为 0

　　援助

　　varchar(100)

　　文章 的标志

　　内容

　　varchar(300)

　　注释

　　创建时间

　　整数

　　评论时间的时间戳

　　表中的aid（标识文章）可以是文章的url、文章的id或者其他任何可以唯一标识文章的东西。这里我们使用文章的uri作为唯一标识，比如上面数据中的文章，我们使用/node/2017/02/20/node-express-forum.html来标识文章. 其他 文章 也是如此。

　　在将这些评论写入表格时，我们还应该注意，在原创数据中，每条评论对应一个用户。在我设计的系统中，用户和评论是分开的，只有uid用来关联他们。新用户和新评论都使用自己的自增主键。因此，在将原创评论存入数据库时​​，需要将原创userid转换为新用户表中的主键id，并统一新旧数据。

　　

　　文章表不解释。

　　3. 具体实现

　　前端部分主要负责展示每个文章的评论，同时允许登录用户添加评论。

　　3.1 显示评论

　　我们为每条评论添加了一个文章标志，前端可以根据辅助获取当前所有的文章评论。但是，我们的评论要以逐栋建筑的方式显示，我们不能简单地将数据平铺在页面上。我们在2.2中也说过，pid为0的评论都是直接发给文章的评论，这些评论应该显示为一级评论；如果pid是其他数据，则必须是属于注释的，应该显示为建筑物内的建筑物。

　　同时，无论是一级评论还是楼内楼的评论，都可能有分页，所以分页也要在这里处理。

　　所以最后我们在前端得到的结构应该大致是这样的：

　　

　　前端拿到接口返回的数据后，就可以渲染页面了。在头像的处理中，也考虑了https环境，所以返回的头像链接都是以//开头的形式。

　　3.2 参与评论

　　如果用户对 文章 或评论产生共鸣，需要留言讨论，我们需要用户能够添加自己的评论。

　　评论的类型，如果细分的话，可以分为3类：

　　我这里的前端实现参考oschina（Open Source China）的comment方法。直接评论文章就是直接在顶部的评论窗口中输入；回复其他评论时，使用弹窗回复。弹窗回复的好处是页面不需要滚动，用户对评论的感知也可以停留在这个位置；同时，用户输入评论也无需添加各种不必要的小输入框。

　　3.3 登录

　　在登录问题上，我也纠结了很久，是使用自己的登录系统，还是使用第三方登录，还是用户无需注册登录，输入邮箱和昵称即可评论？

　　如果使用自己的评论系统，需要自己开发注册登录流程，比较麻烦，对于想要回复一句话的用户，可以干脆放弃注册；如果您只需要输入您的电子邮件地址和昵称即可发表评论，我会考虑到可能从用户那里引出的无限评论，无法控制。所以最后还是考虑接入第三方登录。这里我们选择使用微博作为第三方登录入口，以后会考虑添加github账号登录。

　　关于如何访问微博第三方登录，我们下一篇文章再讲。文档齐全。对于不熟悉的开发者来说，一开始可能会有些迷惑，但应该问题不大。

　　3.4 添加邮箱功能

　　用户登录第三方成功后，名字旁边有一个小输入框，可以让用户输入邮箱地址来接收回复提醒。此输入完全是自愿的，您仍然可以在不输入电子邮件地址的情况下发表评论。也被认为是这个站点是一个流量极低的小站点。用户可能会心血来潮发表评论，然后想到这个网站，但我不知道如何找到它。于是想到了增加邮件提醒功能，防止大神评论沉入海中。

　　3.5 特别注意

　　前端部门引入了vue框架，每一个文章页面都加载了评论模块。为了防止评论模块中的vue库影响外部资源（比如版本冲突等），我先把全局变量给了wzVue，然后注销了vue：

　　

　　同时，在评论功能完成之初，只要用户进入这个页面，评论就会被加载。但是有一个问题，用户不一定能看到你的文章到底部，不一定能看到你的评论。因此，文章 改为按需加载。只有当用户滚动到底部并有阅读评论的意图时，才会加载评论。

　　最终结果是这样的：

　　

　　4. 摘要

　　作为前端开发者，只用后端知识开发一个博客评论系统似乎很简单，整个框架的设计也很粗糙。同时缓存系统不熟练，无法立即更新评论信息。这个系统还有很大的改进空间。欢迎大家对蚊子（邵兵）提出更多的意见和建议。

　　写这个文章的时候，想着以后版本修改的时候，可以通过同步加载评论的方式来完成。生成文章后，更新频率极低，甚至变化不大，然后缓存评论的内容。每当有新评论时，当前 文章 的缓存将被删除并重新加载新评论。数据，然后缓存新的数据，这样在评论数据更新量比较低的时候，可以缓存更长的时间，同时也有利于搜索评论内容的爬取。