共计 1785 个字符，预计需要花费 5 分钟才能阅读完成。
背景 ：做科研须要根底数据，其中一部分只能到网上爬取。
工作：获取 360 图书馆外面某一个用户下有价值的医案数据，并保留到 access 数据库中，至于为何用 access 数据库，是因为前期查看、导出数据不便。
1 数据库表
用 pyodbc 驱动连贯数据库。其官网文档在：http://mkleehammer.github.io/pyodbc/
外面的文档比拟具体，间接用官网举荐代码就能够。留神，最初 cusr.execute(sql) 后别忘了须要 conn.commit()提交。
过后还遇到一个问题：零碎装置的是绿色版 office2016，odbc 数据源中没有 access 的驱动（通过 cmd 中运行 odbcad32 调出数据源窗口查看），起初折腾又给装置了一个 office2013，又去搞激活，各种杂事一通，真浪费时间，有时候想想，国人的软件之路真须要致力啊。
2 爬取页面内容
这部分很久前就爬取过相似的单页文档，比较简单，不过须要依据每个页面的特色进行提取。
3 列表获取
因为要爬取的栏目有 1000 多个页面内容，所有放在多个页面中，每个页面默认出现 10 条记录。如何获取这个 url 的列表是要害内容。
参考了：https://www.cnblogs.com/cokefentas/p/14731920.html
这位仁兄把思路过程形容的很分明，只须要依照思路，依据以后的内容进行剖析就能够了。认为因为本人前端弄的少，尤其是 js 这部分不是很熟，于是把这部分在浏览器的调试模式下再现了一遍，的确最初失去的 sign 是截然不同的。
注意事项：
python 中之心 js 代码，用到了 execjs 模型，须要如下装置：pip install PyExecJS
而后再运行如下语句：print(execjs.get().name)
如果后果是：JScript，阐明用的 Windows 模型的 js 编译环境，须要装置 node.js。
解决办法 ：
装置 nodejs，下载地址：https://nodejs.org/zh-cn/down…
默认装置，默认配置环境变量即可
敞开 PyCharm
再次执行上述 execjs.get().name 命令，发现曾经变为 Node.js (V8)
然而，又遇到了新的问题，在调试模式中保留的 js 文件，起初用记事本关上，再复制了生成 sign 的那段 JavaScript 代码保留，这时候在文件头带了一个非凡标记字符 \ufeff，导致总是编码报错：
这个解决办法有多种：
第一，能够参考 https://blog.csdn.net/u011045… 这篇文章，用 notepad++ 关上后，再以无 bom 头的模式保留。
第二，能够把读取文件的编码格局由 utf-8，改为 utf-8-sig。
utf- 8 与 utf-8-sig 两种编码格局的区别:
As UTF-8 is an 8-bit encoding no BOM is required and anyU+FEFF character in the decoded Unicode string (even if it’s the firstcharacter) is treated as a ZERO WIDTH NO-BREAK SPACE.UTF- 8 以字节为编码单元，它的字节程序在所有零碎中都是一様的，没有字节序的问题，也因而它实际上并不需要 BOM(“ByteOrder Mark”)。然而 UTF-8 with BOM 即 utf-8-sig 须要提供 BOM。
对于 \ufeff 的一些材料（引自维基百科）：
字节程序标记（英语：byte-order mark，BOM）是位于码点 U +FEFF 的对立码字符的名称。当以 UTF-16 或 UTF-32 来将 UCS/ 对立码字符所组成的字符串编码时，这个字符被用来标示其字节序。它常被用来当做标示文件是以 UTF-8、UTF-16 或 UTF-32 编码的记号。
4 ip 被封
在爬取到 34 页（每一页 10 条）的时候，ip 被封了，拜访不了 360doc。其实还是做了延时，然而 header 没有更换，不晓得其判断的机理是怎么样的，目前来看是单位工夫内的拜访次数超过，也有可能是 header 设置不合理。
别人对于爬虫冲破封禁的办法：https://www.cnblogs.com/junro…
https://cloud.tencent.com/dev…
没有方法，只能把每一页设置为 50 条，在调试模式中拿到 json 数据，手工去构建 url_list。
