我的天

当所有现成的方法都解决不了问题的时候，我选择了自己写python脚本转换我的静态网站。花了一个下午的时间，居然还真做出来了。之所以可以这样，是因为我是站在巨人的肩膀上的，我用的是gitbook的格式，他们的静态网页是怎么整的，我就怎么整，毕竟在一个网页里面，哪些部分的数据需要动态变化，哪些需部分的数据无需变动是显而易见的。

之所以可以这么快，另外一个原因是我有了调试的利器。这一次，我用的是VS Code调试html代码。VS Code本来就很强大，昨天更新了个新版本以后，还自动内置了自动修改标签功能，之前这个功能需要用插件实现。大概因为要用这个功能的人实在太多了，所以还不如把它变成默认支持。默认也是需要设置的，不过那就不过是打一个勾而已。VS Code版本更新来得很及时，刚好在我需要用到这个功能的时候，他们就更新了。我还安装了美化格式的插件，这样的好处是，缩进空行什么的一键完成，虽然这个东西看上去很美好，但实际上也是有缺陷的，甚至导致我都不敢用了。因为他们为了好看做了一些不该做的事，超连接给我回车分行，并且在a和href之间再加入很多缩进，这样的话，超链接就不再是超链接了。我实在不知道他们是怎么想的，显然这是一个很大的bug。帮助我最大的是一个叫做live server的插件。这个东西可以虚拟出服务器，网页就可以直接在浏览器上实时更新了。这样的好处是显而易见的，因为这样的话，网站上的超链接全部都可用了，而不需要再按一个CTRL。那种感觉就像直接是在服务器上运行了。我觉得这个效果大概跟各种脚本建立虚拟服务器静态网站差不多。那些脚本除了建立静态网页到缓存，还开起了虚拟服务器。现在，我自己写静态网页，live server开启虚拟服务器。

从前用记事本或者Notepad++，写html的时候，标签配对从来是个大问题，虽然写好了以后，他们会提醒你标签到底配对到哪里了，但在写的时候一点都不智能。之所以这样，可能因为我一直没有去找Notepad++的相关插件。VS Code自带了智能配对的功能，当你写完半边标签以后，后半边自动跳出来了，而且标签你不用写全，写一部分他们就会提醒你，你即将要写的是什么，然后选择就可以了。这样的好处是，标签的配对再也不会出状况，而且标签也不可能写错了。当时我是在看某个介绍VS Code的视频的时候知道这个Emmet功能的，也正是因为这个功能吸引我，那天晚上就下载了个便携版。我不知道便携版和安装版有什么不一样，反正后来，VS Coe用得越来越多，安装版是必须的。如果从前就有VS Code，大概我的很多工作就不需要走那么多的弯路了。但话说回来，现在我写的是静态的网站，如果那是动态的，估计就没那么容易了，但是，就标签配对来说，VS Code还是相当棒的。

现成的各种方法用几个小时，甚至根本生成不出来的电子书是静态网站，我用120秒就搞定了。前提是我们的数据源不一样。我配给他们的数据源是9000多个markdown文件，而我自己使用的数据源是一个20多MB的XML文件。可以生成我梦寐以求的静态网页当然是件好事，但这些静态网页加起来，居然有接近8GB的大小，显然这就很逆天，没有哪个地方能供得起这样的数据。根本原因在于我的每一个页面里面都有一个800多KB的目录列表，排除那个目录列表以外，实际上每个网页文件的内容大都只有不到10KB。所以摆在我面前的是，我不能让那个目录存在于每一个页面，我需要做一个目录页，也就是归档页，我要把那个归档页的链接放到现在的目录那里，而现在的链接则放在归档页里面。只放全部文章的归档页又好像非常空旷，所以接下来，我得考虑把从前的点点分类重新带回。最终的目录那里会有全部文章归档，以及各个分类的归档链接。这个过程挺绕，是我让那些分类消失的，现在我又要把那些分类带回来。最简单的方式是我修改点点到wordrpess的转换转换，让那些分类重新回到分类那里，然后下一步的wordpress XML转化为静态网页文件才会流畅。

python已经成为了我的大杀器，我要学更多，让这杀器更厉害！

要把9000多篇文章，准确来说，是9498篇文章生成一个静态网站实在太难了。如果只是几天，哪怕是几百天，放在哪里，用什么表达，都不成问题，无论是哪个编程语言都可以做到，只是快慢有所不同而已。到现在为止，我已经试过三种编程语言了，首先是go，然后新都javascript，最后是python。

go对应的是hugo，hugo的建站速度是最快的，但快的代价就是电脑的所有性能都会被用到极限。生成网站的时候，CPU飞到顶，内存一直往上走，最后当我看到内存到达90%以上，CPU的使用率反而下降，说明已经到顶了。因为我在做建站服务器测试，那些虚拟的东西全部都放在内存里，显然，我8GB内存的小电脑没办法在某些模板之下，hold住这9000多篇东西，但并不是所有hugo的模板都做不到，有些简单的模板可以做到。另外一些，别说9000多，一两千，都很困难。具体反映出来的效果就是建站的时间很长，其次是内存封顶，结束时间遥遥无期。

第二快的是python。python是我的老熟人了。而生成静态网站，我用的是mkdocs。这是一个python脚本，但实际上脚本自己又调用了很多东西。所以你以为你只是装一个脚本就完事，但实际上你得连串装一堆脚本。只有几个markdown文件的时候，mkdocs建站是很快的，但没到达hugo那种秒杀的地步，但是就建站构成来说最简单的。初始化以后，会自动生成了一个配置文件和一个文件夹，你把markdown文件放到文件夹，然后建站，就可以看到网站的雏形，虽然那个效果肯定不是你想要的。配置文件只有一个，所以也没什么好让你发挥的地方。正是因为够简单，所以我觉得，对那些纯粹写作的人来说，而且，是纯粹写书的人来说，mkdocs这个东西要比hugo实在。但其中一个不友好的地方是mkdocs自带的搜索对中文不友好。搜索英文的时候杠杠的，但是中文就无能为力。如果丢进去mkdocs的文件非常多，到达几百几千的时候。你会很崩溃，跟hugo不一样，mkdocs的CPU的使用率永远只耗尽我其中一个CPU，所以CPU的使用率永远只是25%，至于内存，貌似我一直都没有看到变化有多大。生成一个几页的网站，需要几秒，生成一个200多页的网站，需要十几秒。但是生成一个2000多页的网站，却需要1000多秒。为什么会有这种指数式的增长呢？我觉得跟他们的搜索索引有关。总的来说我觉得gitbook和mkdocs的思路类似。他们会建立一个json文件。而那个东西我感觉就像是一个字典。之所以能自带站内搜索，就是因为他们建立了这个东西。读取写入其它文件，再怎么慢，也有个限度，而且是匀速的，但是如果要不断的增加字典内容，把新的文件内容全部写入到json里，然后存起来，这就很变态。思路很简单，但执行起来的时候相当费劲。

其中一个让其更加费劲的地方在于，但markdown文件非常多，就肯定有一个不断打开文件关闭文件的操作，还得递归某个文件夹里面的所有东西，想想都知道这有多累。但如果有个大文件，全部都已经结合在一起的话，就没有这个烦恼。之所以我有这种感觉，是因为之前我写了一个脚本，专门用来输出9498篇文章的标题与文件名，作用是造一个目录。当时我没有把脚本输出文件的代码缩进，结果仅仅输出目录，居然需要20多秒。目录很小，但是运行时间却跟我把全部内容都输出一样过。昨天我才发现缩进的问题，那就意味着每次增加内容，文件都打开写一遍。这就意味着那个文件被反复的打开关闭9000多次。紧紧减少一个缩进，等于把写入的次数从9000多变成1，于是那个运行时间就缩短为了6秒。读取一个二十几MB的XML文件并输出目录仅仅需要6秒。可想而知，如果不是频繁打开关闭9000多个markdown文件，而是直接用完整的一个大XML文件生成json，速度会相当快。那不就是跟字典类似的东西吗，简单到没朋友。如果我不想进行全文搜索，我只需要进行标题搜索，事情会变得更简单。简单到跟我生成那个目录没啥区别。

经过了这一番折腾以后，让我明白到明细数据与汇总数据使用起来真的很不一样，虽然就总量来说，二者是等价的。

接下来，或许，我真的会像网友所说，自己写一个脚本，把已经进行wordpress标准格式化的XML转为一个静态网站。

天下大势，分久必合，合久必分。这次我算是深切体会到了。

我觉得gitbook和github两个东西是很容易连在一起的，如果我把东西推上了github，自然而然gitbook就会自动同步过去，但实际上，我太天真了，因为我看到的gibook并不是网友们所说的那个。我看到的gitbook实际上已经是第2代。被各位网友津津乐道的gitbook是第1代。第1代的东西还在，但已经不允许新住户加入了。我开始知道有gitbook时候，注册时已经是第2代了，所以无论我费尽多少心思，想在第1代的gitbook里登陆都是无能的。第2代的gitbook简直是一个神奇的存在。我甚至有点不知道该如何去写东西了。

前天我做了个小实验，把几篇markdown放到github里，然后同步到gitbook，非常容易就显示正确了。但我不知道，那只是让我上尝点甜头，因为接下来，当我想把大部队部署到上面的时候，根本无效。一开始，我把9000多篇文章都传到github之后，然后自动往gitbook里输送，结果花了一个晚上，进度条一点反应都没有，一直卡在50%，没有成功也没有失败。昨天我试着只搞4000多篇，结果还是50%卡住，最后我甚至只用了1000多篇，有时可以，有时不行，有时说数据传过去了，但实际上展示界面什么内容都没有。我怀疑是不是我的readme和summary没做好，所以我手动做了那种东西，结果发现还是不行。readme没什么技术难度，至于summary，难道summary太大，读取不了？所以我又把summary删减了好多。到底我是要先做summary还是先做内容呢？如果只有内容，没有summary，会不会内容就无法展示出来呢？最终，我先把summary和两个很简单的文件扔上去，确认没有问题以后，再扔十几篇东西上去，然后就卡住了。没告诉我到底是哪里卡住，什么原因卡住，反正就卡住了。起码昨天我还有卡住的信息，而前天晚上卡住了也不告诉我一声。我试过直接使用zip上传，结果发现，上百篇一起都不行，只能几十篇，文档用zip上传到那里以后，标题没了，所以目录那里完全只是我的文件名。即便我有那么好的耐性，一个一个小压缩档上传，我也没办法一个一个页面改文件名啊！压缩档上传的方法也不行。

我实在搞不懂这个第2代的gitbook。当这些东西我都搞不成以后，最终我想到gitbook之所以有这个名字，肯定是因为可以用git来管理。所以我下载了个node，然后试图安装gitbook，但失败了，不知道为什么出现满屏的错误代码，最终我只能放弃。还记得，从前用点点的时候，他们第2代的模板就是基于node的，所以那时我的电脑上有安装那个东西。我也不知道这个东西需不需要环境配置，通常来说，都得这么干。但貌似这次还真不用，只不过用的方法麻烦一点，每次都要转一下目录。之所以之前没有用gitbook的本地命令行，而选择去上传文件，是因为我觉得大概用不着再装一个安装器，但是，当我觉得现有的方法都不行，我只能用最传统的实现的时候我才发现，原来有第1代跟第2代之分。第2代的gitbook彻底了没有git的功能。虽然他们的网址有迷惑性。最终，即便我可以用本地的脚本生成静态的电子书网站，我也再也不可能把那托管到gitbook上面了，但我还可以选择其它地方可以托管。晚上，我真的又配置了一个本地命令行的gitbook，接着我发现gitbook的虚拟服务器在生成静态网站的时候居然会卡死！卡死的时候不会告诉你我卡死了，因为什么原因卡死。这样太不人性化了。这简直让人连debug的机会都没有，因为不知道bug在哪里。所以接下来我只能一点一点地把文件加上去，然后才好找出到底是哪个文件整出来的幺蛾子。

文章最后，我试验证明gitbook本地版是个没用的东西，起码对我来说没用。生成9页内容需要9秒，生成50多页内容需要80多秒，生成600多页内容每一页至少要一分钟。这样没有效率的东西，可以直接扔了。如果仍然是用这种处理数据的方式运行，github推送给gitbook的9000多个页面能正常绝对是奇迹。