我的天

越是整理数据，越是觉得挺奇葩的。还记得一开始的时候，BlogBus只有分类，没有标签，后来多了标签，但分类没了，强迫把我们的分类全部变成标签。后来分类回来了，标签依然有，但分类只能选一个，标签可以好多个。这样的设计纠结了好长时间才终于确定了下来。后来当我用上WordPress以后，发现原来人家分类和标签都可以同时多个，但因为BlogBus的使用习惯，所以分类通常我只会选一个，而标签会搞一大堆。这是因为blog上的使用习惯，所以我在文件归档的时候也会用分类和标签，我的默认设置继续是分类只有一个，标签有一堆，用python的思路去解释就是某个文件跟某个分类是一一对应的，它们可以形成字典的关系。某个文件和某串标签是一对多的，如果要用字典表话。那堆标签得用列表去表达，于是在文件一开始的时候，就得引入特殊的字典模块。我也不知道为什么必须得有个分类。如果没有分类，全部都只有标签呢？其实也说得过去。文件完全按照时间排序。如果时间一样的话，就按照不同的文件号排序，因为文件号这种东西也是有一定的命名规律的。至于用什么关键词找到这个文件，则可以通过标签，所以其实我觉得标签和关键词是非常类似的东西。

当我在进行动态blog数据转为静态网站以后，我有点明白到。分类就像是定义一个人的一级目录。有些人的blog分类的命名非常有意思。对我来说，那肯定是花了很多心思才终于想出来的，对别人来说或许不这样。要快速定义一个人的话，用分类基本上就可以了。标签通常体现的是某个人的各种特征。标签使用的多少跟这个人的性格和特点很有关系。标签云是一种非常有用的东西，通过不同的颜色以及不同字体的大小就能体现出标签出现的频率，从而反映出这个人的特点。分类这种东西，像是自我介绍，是努力想出来，把自己介绍给别人的，而标签更像是无意之中积累回来的东西。我不知道别人的blog情况会怎样，基本上我的blog的分类是废掉的，因为绝大多数文章都被分类到烂日记，因为我的习惯是一天至少要有一篇日记，而烂日记每天也顶多只有一篇，如果大于这个数的话，我就会用其他分类。从前当我还非常勤快的时候，还有其他分类，但现在，每天一篇日记算是保底，也是封顶。只有一些非常特殊的时候，我才会有两篇或者以上的日志。从前的我，那些多于一篇的日志类型五花八门，而现在也就只有当我心血来潮的时候才会来一些，而通常，那都是专注于某个领域的。对我来说，分类能代表些什么呢？那只能代表过去我曾经做过的某些事。真能体现我个人特点的，只有标签云。到底我用过多少个标签呢？我实在记不清楚了，因为WordPress是个神经病的存在，有些标签我输入了，但是有错别字，我删掉了，但那居然也会保存下来。即便我没有按保存按钮，而有些时候，我真的敲错别字了，但是自己毫不知情。那个错误的标签也保留下来。一篇文章我会输入多个标签。基本上，想到什么相关就会往里面写，所以标签可能一大串，也正是因为这样，各种标签都会出现，所以只出现一次的标签在我的blog里，概率很高。于是就造成了一个比较搞笑的局面，我的分类是严重偏科的，而我的标签是海量的。如果某一天我要把这些东西选进我比较简洁的目录，我该怎么选择呢？标签肯定是不行的，但分类也很奇怪。所以大概那个时候，我就只能用日期做归档了，又或者选择用得最多的10个标签。

静态blog很伟大，但我觉得，我的东西、我过去16年的生活没那么容易在一个静态blog里全部展现出来。因为连我自己都说不清，那到底有多少东西。

我终于做到了用模板的方式以及我自己的数据生成静态网页。暂时我还不知道，那些放进去就能用的格式类东西应该怎么在生成网站的时候顺便一并放进去。肯定是有方法的。虽然现在我手动挪一挪也无所谓。我觉得那大概是一个获取文件，然后解压到目标位置的操作。

jinja的模板套用比我想象中简单。在进行我自己的操作之前，我复制了网上的一个教程的代码，发现真的很容易。模板本身也可以通过浏览器查看效果，这个非常棒。从前BSP不就是干这种事吗？无论是可视化编辑的，还是纯代码操作的，其实都是在设计模板。现在我也终于明白，为什么相比于其它核心功能，在模板方面，我为什么总感觉自己有那么多的经验，因为实际上，我的确在那个方面花了很多时间。现在我已经不记得BlogBus的模板是怎样的了，唯一的印象是他们用的是代码编辑。他们会给你一些核心代码的封装，你可以把那些东西放在指定的某些模板里。封装的东西以外的部分，你可以通过css，或者js去控制，但是封装在里面的，基本上就是一个无药可救的状态了。所以有些格式你觉得你应该可以控制得了，实际上你却做不到，因为封装在里面，已经把格式给写死了。不知道如果我在css那里强行加个important，能不能扭转局面，但显然，当时我根本不知道有important这种东西。css的important的确威力无穷，但是important如果经常用，就会破坏规则，也不好维护。不得已我才会用，即便用了，一个css文件里面，通常不会超过三处。

以前的模板设计，我只是能处理一些格式上的东西。现在，我自己写脚本生成静态网站。无论前台后台，我都玩了，我得顾及前台的模板形式。也要考虑后台的数据整合以及数据的架构类型。在用jinja模板之前，我用的是人肉低端的字符串合并。虽然实际上，我做的低端操作也是实现模板的功能，但就维护来说，这实在太困难了！如果一个网页里面有很多数据是动态的，我就不得不把网页切分为很多份。切着切着，我都不知道自己切到哪里了。就数据生成效率来说。我的低端做法效率会更高，至于为什么，我不知道。9498个页面，我的低端做法转化需要22秒，jinja模板只需要32秒。这个不是偶然事件，在进行9498个页面转化之前，我先进行了一个只有几个页面的测试。结果跟大数据的很类似，低端做法，要比高端做法快1/3。这其中的原因是什么呢？据说jinja已经是个生成速度自称为“快速”的脚本，如果是另外一些，可能更慢。9000多个页面才多10秒钟，任何人都忍受得了。就维护的便捷性来说，低端拼接的维护成本随便超过10秒,所以用jinja模板绝对是值得的。这让我想起了我最在行的邮件合并，用word和Excel联合起来批量生产东西。我不知道其他人玩这个能溜到什么程度，反正这个东西一直都是让我引以为傲的，当然了，这种技能，也是后天逼出来的，工作使然也。

一些我觉得可能挺不容易的东西，居然很轻松就被我攻克了，感觉非常意外。接下来，生成搜索引擎所需的索引，估计不是件容易的事。生成索引，最重要的是思路，而过程不过是一些机械操作而已，我必须掌握好那个思路！

你永远都不知道纠结的路上会出什么状况。一路平坦不好玩，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这种这么神奇的东西，大概我就不需要走这么多弯路了。

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

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

追求更好是没有尽头的。