我的天

在没做过之前，不能觉得任何事应该会不太难，这种应该的想法会让你死得很惨。

静态blog的内容好了，模板也好了，但要放在那里托管呢？国内的没有备案肯定没门，付费的还得算流量。Gitee据说经常性习惯性宕机，本来我是倾向于CODING的，首先，那里要备案，其次，他们pages的服务器不在国内，于是非常有可能因为各种各样的原因，你还是访问不了或者速度很慢。网上提供了很多方案，但最多的还是GitHub Pages。我要玩静态blog，我要玩托管，我就应该从GitHub Pages开始。关于github这个东西，几年前我就开始见识过了，很多软件就是从那里来的，但到底要在哪里下载，在什么页面下载，我一直很迷糊。当时我并不明白开源的意义，所以下载回来一堆东西根本不知道怎么用。github上有非常多的用户，大家擅长的程序语言又各有千秋。开源的东西就是可修改但未封装，这就意味着我下载了一个不知道什么语言的脚本回来根本是用不了的。我不知道那到底是干嘛的，自然就不会去哪里研究。

我感觉GitHub Pages算是github给用户的一个自我介绍空间，github给用户免费空间和流量，允许免费托管的repo到底有多少个我什么都不知道，但用来撑起我的小blog应该没什么问题，毕竟我从来都不是个大流量的人。

不知道github是什么，不知道git怎么用，不知道为什么非得要用一堆命令行来解决问题。一句命令输入进去，有可能秒杀，也有可能屏幕开始跑马灯，因为我数据多，跑马灯可能要跑上几分钟。昨天做到最后步骤需要提交账号密码，提交数据的时候首先给我弹出的是窗口，但每次输入了都不行。接着就在CMD里继续让我输入账号密码。账号好理解，但密码的输入却是让我震惊。怎么输入都没反应，乱输一通也不行，我都怀疑是我电脑有问题了。后来才知道github的密码输入界面就是这样没有东西的，把密码输入完毕然后回车就行了。这么逆天的密码输入界面我还是第一次见识！密码等于是必须的盲打。经过这次以后，我脑洞里奇怪的知识又增加了。

网上教人怎么在GitHub Pages上用hugo做博客的教程很多，但当我真的要完全依照其中一篇实施的时候却发现到处都是问题。从安装hugo到虚拟单机测试这个流程我已经非常熟悉，通常这个部分都被讲得很详细，后续的怎么发布到github非常多的教程一句话带过。对那些本来就离不开git的人来说，那是简单到没必要说的事，但对我这个一片空白的人来说这是要了我的命！详细说怎么发布到github的教程也不少，有些甚至把CDN加速，自动部署脚本，域名绑定，双线部署等等高端的东西都说到了，但越是说得高端，越是会把小白最容易犯错的地方漏掉，比如新repo的文件名。有些教程看上去很有道理，但当你把那些语句复制粘帖的时候就会出状况，不是英文的地方用的居然是中文符号，在某些字体之下，那是很难靠肉眼分辨出来的，但贴到CMD里，那就铁定完蛋的节奏。教程写出来，一定程度就得考虑读者可能直接贴走，只能看不能操作，这到底算神马教程！

安顿好一切，那些我该懂的日常操作都懂了以后，我真心要亲自写一个小白教程！

数据太大，上传很慢，上传后网页打开很慢是我一直担心的东西，但原来这些我都想太多了，github上传数据的速度比我想象中快非常多。最终，我把静态博客部署上去了，并且绑定了二级域名。我的老blog终于合体后重新上线：https://yday.xlanda.net/，这里的链接叫做“青春无敌” XDDD

你永远都不知道纠结的路上会出什么状况。一路平坦不好玩，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的要求，但从完全不会到可以生成，而且大多还是合格的，能做到这个我已经很满意。

昨天我终于用python写出了把点点转化为WordPress的脚本。这个东西我确信是可行的，因为python的转换过程中没有出错，这就证明没有遇到奇怪的事情。用别人脚本的时候，把转换好的文件上传到WordPress，我总会担心不成功，但我自己写的脚本，我知道该注意些什么，哪些参数是现在的WordPress必须要求有的，所以只要python的转换不出错，我的WordPress导入就不会有问题。因为点点的文章有9000多篇，要从后台管理界面导入到WordPress，会非常耗时间。如果一篇文章需要两秒，完全导入就需要5个多小时，所以我没有做这种事。我挑选出22篇，各个类型都有的，试验导入，结果非常成功，网页的效果也很好，完全按照我的意思生成了。我觉得如果要快速解决问题，估计我得在数据库端导入。之前把文章导入到WordPress，因为要尝试不同的版本，我得不断地导入删除，但删除的文章太多的时候，速度很慢。后来我暴力地在数据库那里直接写删除语句，结果秒杀就完成了。现在我发现了一个更干净的方法。直接把关联WordPress的数据库里的内容全部删掉，这也是一个秒杀的过程，而且绝对不会留下任何的手尾，比如文章删除了，但是分类和标签仍然在那里。可能某些东西已经不存在了，但是计数还停留在一个很大数值，之所以这样，肯定是因为我删除文章的时候不够艺术。与其让里面留那么多乱七八糟的东西，还不如直接把数据库清空。因为我这是单机上的WordPress，我纯粹只是用来测试。这样的删除是最快捷的。大概我从上周，才突然领悟出可以这样。别人之所以要在数据库里写语句删除文章或者标签，是因为不能删掉一些不应该删掉的东西，但我没有这个顾虑。既然在数据库层面可以快速的删除，那么理论上也应该可以从数据库层面快速的导入。之所以有这个想法，是因为我发现WordPress的插件有些是针对数据库的，有些是针对WordPress自带函数的，数据库层面的查询要自带函数快非常多。现在我已经学会了转换适配后台界面导入的文件格式转换。下一步大概我得学习一下如何在数据库层面进行导入。这么高端的做法，貌似之前我还没有听说过。在网站迁移的时候，的确是把数据库打包，然后重新放到别的地方的，但那个数据库是本来就已经存在的。从一个地方挪到另外一个地方，原封不动地，但是我却要把大量的数据以快速的方式导入到数据库，并且还得按照WordPress的脾性建立各种关联，显然这貌是非常不简单，但理论上应该可以做到。

我不知道我的python到底学成怎样了，但起码我可以用那个东西实现我自己的愿望。相比于书本的习题，我觉得实现自己的愿望更有成就感，虽然其中有很多问题完全只能靠自己，没有参考答案。虽然总的来说，脚本不是我一个人写的，我是站在巨人的肩膀上修改而成，但BlogBus和点点的结构还是有差异的。最幸运的是某些我不知道该用什么手段实现的东西前人已经给我指明了方向。昨天我只是把脚本写出来了，接下来我要把脚本优化，一些老是翻来覆去说的句子完全可以把那作为自定义函数。到底什么东西应该泛化，应该泛化到什么程度，这个我还没有想好。昨天之所以可以这么迅速地完成任务，大概是因为在我开始之前先做了个思维导图，明确了我到底要做些什么。基础数据有哪些，应该在哪里取数，需要判断的参数有哪些，各自的参数有什么特性，能不能合并同类项。之前我就写过类似的东西，但是跟思维导图比起来，之前我写的那个真的很水。有思维导图、有专业的思维导图软件，人的思路可以非常快地展开。整体定下来，下面的事情就只剩下一步一步地实现。我做梦也没想到，自己这次居然这么高效。某些我没有把握能快速解决好的问题，昨天不知道为什么很多都迎刃而解了。转换一个30多MB的XML文件，我用了16秒。转换出来的文件大小为22MB。我觉得应该可以更快，但怎么才能更快呢？文件里的数据结构是我没有考虑过的，我是不是应该从那里入手？一些相同的判断，大概我应该做一些合并。

追求更好是没有尽头的。