我的天

我觉得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多个页面能正常绝对是奇迹。

你永远都不知道纠结的路上会出什么状况。一路平坦不好玩，5分钟就能所有问题，那是无聊的节奏。老blog的重新上线是我近段时间一直在纠结的东西。要做的事情很多，应该如何开展？做这些事的步骤应该是怎样的？谁轻谁重？

首先我做的是处理blog的核心——内容。文字我是有的，我有大把大把，但里面也有非常多连我自己都说不上到底是什么的东西。有可能长文被阉割了，但我自己毫不知情，有可能是消息从其它网站上复制粘贴过来了，带入了一些我根本没有意识到的乱七八糟代码，不同网站连换行都不一样。有些是“br”，有些是“br/”，有些是“br /”，有些是“BR”，有些是“BR/”，仅仅是“b，r，/，空格”的排列组合就有多得你想不出的效果。如果这在HTML里，都不是问题，但我做静态blog的第一步是从html到markdown，该死的“strong”在html2text的脚本里是不允许期间有换行的，在这个脚本里，连续两个br就能自动匹配正路的p，但如果遇到稀奇古怪的“/”和空格呢？在我的python转码脚本里，我用了很多行去处理那些排列组合的问题，正则的、非正则的替换用了好多遍，所以脚本运行速度只可能在我一次又一次的增加新规则之后变得越来越慢。理论上，这些东西都是不存在，但事实就是这么残忍。除了html的问题，还有yaml以及文件名字符要求的问题。转义字符出现就丑陋了。丑陋归丑陋，字符不对，那是直接编译不出来的节奏。出状况这种事简直不计其数。我也不知道自己到底改了多少个版本，理论上脚本修改这种事我应该放在坚果云文件夹里进行，但因为我生成数据的文件夹和我的脚本文件夹一致，显然那就太消耗同步流量了，所以我大胆地把脚本放在了坚果云以外修改，那是一个错手就没得救的玩命。其实我完全可以把输出的文件夹设置在坚果云以外的地方，但我就是没有这么干。要把BlogBus和点点的数据匹配为WordPress的格式，然后再用WordPress格式的数据转化为markdown。为什么我要有WordPress这个步骤呢？起码但我学会了XML到另一个XML的规律后，不静态blog的时候我还能退回WordPress，虽然那意味着我导入数据的时间将是个天文数字。没经历过这些纠结，我就不会深切体会到好好码字，不要不规范乱写的重要性。从前，尤其是一开始在BlogBus写blog的时候，我总把网上看到的东西直接复制到编辑器里，这样过于简单的操作让我付出了非常多整理的代价。后来的点点几乎没有这种问题，现在我更加是极少会直接复制粘贴网上的东西到我的blog里发布，即便有时会截取一段，基本上都是保证无格式纯文本的。现在我知道了，但当时我不知道，成长是需要付出代价的。我仅仅是在处理自己的东西，所有坑都是我从前挖下的。如果我是被迫要帮别人擦屁股，估计我早就把那个人诅咒死几万年了。

内容基本确定下来后，一开始我觉得应该不会太难的静态blog主题原来也不好找。首先是样式得对上眼，其次是渲染速度要快。有些主题连单机渲染都会让我的电脑崩溃掉，连测试都无能，真的是什么都不用说了。我几乎得出一个结论，如果某个主题大于5MB，基本上无需考虑了，那些10MB左右的，更加会让我电脑宕机。不是人人都会遇到这种事，宕机与否的测试基于我需要渲染的文章有接近3900篇，不是人人都有这样的体量，这还是建立在我已经放弃了6100多篇图片内容已经失效，光文字意义不大的文章上。

内容好了，主题好了，还得考虑把网站托管在哪里。要免费，要速度快，要可以绑域名，要服务器稳定。对一个女人，对一个习惯于货比三家的人，这实在又是一个大纠结啊啊啊。

折腾了一个晚上，打算关电脑睡觉了，突然想起好像今天自己的blog还没写。我把时间都耗在了什么地方呢？我正在校对其中一个老blog里的内容。

之前，我的关注点纯粹是格式的转换，先从BlogBus的XML转化为WordPress的XML，然后再从WordPress的XML转化为一篇一篇的markdown。纯粹技术的东西我已经几乎完成了，余下来的问题，需要在不断的转换之中发现，然后修正。今天我花了一个晚上搞的是校对从前那个blog导出来的内容。不知道从什么时候开始，我发现里面有些文章的正文是不存在的，是空白的，至于为什么，非常有可能是当时的文章我发布的时候其实没有成功，但是标题和其他内容已经有了，失败的纯粹只是正文。至于为什么不行，我当时也不知道。通常那些失效的文章，我都是批量手动粘贴发布的，可能是从一个网页，也可能是从一个word文档贴过去。在贴的过程中，自动带入了非常多的超文本格式，这个我之前已经吐槽过了。在格式转换过程中，我不得不费尽九牛二虎之力把那些转回来。其中那些空白的正文，这一次我想把资料填补回去。

昨天我的确好不容易找回了那些资料，也进行了填充，发现效果还不错，但是原始导出的那个BlogBus文件就不再原始了。接着，我发现那些有正文的文章其实也不完全可信，因为正文的内容不知道为什么只有一部分，不是全文。难道发布以后，我没有好好一个一个浏览过吗？还是说点发布之前，我看到的东西的确是完整的，BlogBus没有给我单篇文章字数的限制，但是实际上发布的只是部分。我的问题在于，有可能发布出去以后，我没有在前台校对一遍，但是也有可能我校对过了，当时看是没有问题的，但是当我在BlogBus后台把自己的东西导出的时候出了状况。一开始我觉得可能是我自己的问题，但后来我发现，断字断得好神奇，一个单词可能只剩下头两个字母，显然，如果是我复制错误的话，不会有这么低级的东西，顶多我会漏掉一些段落。现在搞清楚到底是我人为的错误还是BlogBus阉割了我的东西已经毫无意义。所以，我只能一篇一篇地校对文章的开头和结尾，确保是完整的。一些篇幅比较短的文章，暂时我还没发现断尾的现象，但是，对一些比较长的文章，断尾是必然的。纯文字有100K以上那些文章，通常BlogBus只留给我一半的内容，余下的那些消失了，而且还不告诉我。我记得从前选择BSP的时候，我知道有一些是对单篇文章的字数有限制的，到达一定程度以后就会告诉你，超过多少字了，请你重新修改，否则不能发布，但BlogBus没有这个限制，起码在一开始我选择他的时候没有。另一方面，我觉得之所以这样，会不会跟他们数据库的存储模式有关。如果他们数据库的某个存储单元顶多只能100K，我在那里输入了150K的文字。当然多出来的那些就不可能被保存下来，这纯粹只是我的猜测。几十上百篇文章，一个一个去检查头尾是否齐全，格式有没有乱套，这是相当累人的。虽然那些最原始的东西我还有，但绝大多数那些东西我都是保存网页的。现在那些网页已经不能在Firefox里打开了，用Chrome也不行，于是我只能使用IE，而且是兼容视图模式。我不觉得当年我用保存网页的方式把文字记录下来有什么毛病，我只是不明白为什么现在的浏览器不允许我打开那些老东西。

如果当年就有markdown这种这么神奇的东西，大概我就不需要走这么多弯路了。

上周五我才开始研究静态blog。我选定的基本是hugo，因为这个东西生成网站的速度非常快。暂时我只是在本地操作。一开始的时候我不知道那个生成网站的命令窗口必须一直开着网站才能浏览，关掉的话就开不了了。之所以不了解这个，大概我还没研究过hugo的原理。之所以我在本地测试WordPress的时候可以一直开网站是因为虚拟的那个东西其实一直都常驻我的电脑。同样是本地测试，静态网站的生成速度以及网页打开速度比WordPress快非常多。如果只是几篇文章，生成网站的速度是毫秒级的，基本上就是一眨眼的功夫。昨天我测试了，生成200多篇文章的网站，也非常快，只需0.5秒。但是，如果网站有9000多篇文章呢，到底需要多长时间生成？这个我还没测试出来。因为我那9000多篇文章还没有完全符合的hugo框架的要求。

要用Hugo建立静态网站，如果是从零开始，当然很简单，按照他们的规则去写就可以了，但对我来说，我不是从零开始的，之所以用这个东西是因为生成速度快，而且可以挂在免费的空间上面。因为我的老blog很多，所以我必须要找一个这样的地方。如果我仍然使用WordPress，显然就非常浪费资源了。静态网站跟动态网站最大的区别，我觉得是静态网站不自带评论功能。几乎可以这么说，静态网站如果不外挂，是无法交流的。因为我挂的是老blog已经早就不去更新了，从前那些挂着blog的BSP都已经全部没了。我会在静态blog上留下可以交流的链接，如果有需要，访客可以找到我的blog，然后留言。这样的好处是起码你还能找到我，但坏处就是，你不能在你感兴趣的那个地方直接留言。去到我的blog还得解释你是从哪里来的，这就比较麻烦。但换个思路，我把那些已经不存在的东西重新又翻出来让你见到，其实已经很不容易了。

hugo的建站不难，但是如何把核心内容转化为hugo适配的不容易。我要把XML格式的大文档转化为一篇一边的markdown文档，这个星期我都在折腾这个。我本想直接用一个python脚本解决所有问题，因为理论上这是相当简单的操作，但是我却发现能搜索的python脚本，根本不适合我。有些已经老掉牙了，用的是python 2的版本，我试着转版本，让失败了，因为我实在不知道，里面的某些操作到底在新版本里是怎么个整法。

经历XML转化为另外一种格式的XML之后，我对XML这个东西算是有点了解了，我个人觉得输出markdown其实要比XML格式互转简单一些。XML互转只需要输出一个文件，但是markdown要生成无数个文件。python的操作之中，我最生疏的就是文件处理。输入输出那一章书我觉得自己根本没毕业。现成的python脚本无法满足我，我得自寻出路。幸好有一个叫做html2text python模块拯救了我，这个东西解决了从html到markdown的转换，所以正文最核心的东西的转化已经不成问题了，虽然里面还有一些说不准什么时候会出现的状况，但总体来说效果不错。XML的格式转化如果有一些我不想转义的东西，我还能用cdata把那些都圈起来，圈起来以后就没烦恼了，但是用markdown文件在hugo建站，必须有一个YAML的开头，而那个东西是有严格的格式限制的。篇名、分类和标签都必须严格符合这些要求。因为我的网址输出用的是python的时间戳，完全是数字，所以没烦恼，一开始的时候，文档的文件名我用的是时间加篇名，但因为片名的幺蛾子太多，所以，我选择了用纯粹的时间，单位精确到秒。如果不是手动设置过时间，不会发生重复。接下来我需要做的是整一套替换列表。把里面严格限制不让用的东西全部整理一遍。这样才能保证hugo的网站里能生成了我的全部东西，而不会有些不合规则的直接被屏蔽掉。WordPress没有这种烦恼，顶多出来的东西乱码而已，只要我把可能乱码的东西全部cdata。简直爽歪歪。之所以可以这样，是因为我把数据导入到WordPress的时候，软件默认把我不规范的东西规范化了，现在这个步骤，我完全得靠自己。

虽然现在我生成的文件还不能100%的符合hugo的要求，但从完全不会到可以生成，而且大多还是合格的，能做到这个我已经很满意。

昨天晚上我又花了好些时间为我的小米平板1选一个Markdown阅读器。如果这是我的手机的话，非常容易就解决了，因为坚果云Markdown完美解决了所有问题，但不知道为什么，虽然还在他们的安卓兼容范围之内，但是坚果云Markdown在小米平板1上打开md文件的时候会一片空白。那到底是为什么，我没搞懂，但是可以肯定的是，无论是在MIUI 9还是在MIUI 6都不行。我之前之所以选择坚果云Markdown，是因为那个东西是我试用过所有app安卓下，不需要任何设置，直接就能读取我手机或者我内存卡上面的md。这样的设置，看书的时候就很方便。其它阅读器，你可以在文件夹里通过某程序打开，但显然就不那么方便了。安卓系统里传统推荐的软件MarkdownX也不错，非常有可能不少Markdown编辑器都是抄他的。

有些Markdown编辑器是所见即所得的格式，他们觉得是很酷，但实际上会让人很眼花，因为Markdown的符号和Markdown转化后的样式都体现出来了，尤其像我这种不是为了写，纯粹为了看的人。坚果云Markdown之所以好，是因为它的编写和预览在同一个区域。一个转换按钮就可以从编写到达预览，文件打开后默认界面是预览。这样就完美解决了手机小屏这个问题了。不少安卓Markdown编辑器沿用的是电脑的那种，半屏编写半屏预览，所以明明我的小米平板要比我的手机大很多，但是被分了一半以后，阅读区域还是很少，这简直就是搞死人的节奏！我试了好多个Markdown编辑器，在预览这方面，很多都做得很一般。有些的确是全屏显示了，那问题是反应速度很慢，比如iA Writer。安装Firefox后，可以通过安装插件来实现阅读md文件。在手机上我觉得这是没有问题的，但是，当我在平板上这么做，生成的那个文件，字体就变小了。浏览器本身是可以通过手势扩大字体，但是那样的话阅读的时候就要不断左右移动页面，太烦了。我没有在Firefox安卓版的设置里找到自选字体大小。有一个选项是可以适应系统字体大小的，但系统的字体大小跟我阅读时的字体大小怎么可能一致呢？所以我真的不知道他们是怎么想的，无论是那个插件，还是Firefox本身，为什么我要在浏览器里使用可转换md格式插件，肯定是因为我要把那当做是阅读器，阅读器的字体这么小，叫人怎么看呢？折腾了一大轮以后，最终我选定一个2016年豌豆荚已经不再更新的MarkdownEditors。这个东西几乎可以这么说，是高仿MarkdownX的，功能和界面很类似的，但是那个东西更小巧，而最重要的是，虽然不可以在软件里选择打开手机上的东西。但是从手机的文件夹打开md文件后你可以在那里全屏预览。不好的大概是如果文件里面有编程语言，你无法高亮显示，还有一个不好就是当你打开了文件，哪怕只是打开预览之后要关掉，都会问你要不要保存。对比了装了插件的Firefox和MarkdownEditors，后者的字体大一些。这两个软件我都在小米平板1上留下了，因为说不准什么时候需要互补一下，因为Firefox中md文件的编程语言是有高亮的。

如果以后我能神通广大，我觉得我会自己动手写一个代码阅读/编辑器。