个人 Wiki 之殇

我一直都在寻找一种优雅的方式来管理我的知识。如果能够优雅地分享，那是最好不过。为此，我先后尝试了 Wiki，Evernote，Blog 等各种媒介。

大三那年，学习了冯志勇教授讲授的《知识工程》之后，我发现语义网的确是知识的良好载体。知识有定义有关系，定义之间通过关系互相连接而形成一张大网，当这张网足够大，覆盖面足够全，本体就形成了。

在当前的技术条件下，Wiki 俨然称为了知识的最佳载体。Wikipedia 已经称为世界上最大的百科全书，承载了全球有识之士的知识与智慧。

大而全的东西固然好，但是毕竟缺乏个性化，我还需要一个小而美的 Wiki，作为我的知识网络的载体，也让我把分享知识这件事变得更加简单。

大学的时候，我曾经尝试过在本地搭建 MediaWiki。然而这并不是一种科学的使用 Wiki 的方式。后来我一直没怎么折腾 Wiki，一个是因为没有那么强烈的管理知识的需求，另一方面是那时候搭建 Wiki 实在是一件吃力不讨好的事情。

直到最近，知识管理的需求又冒了出来，而我正好找到了 TiddlyWiki 这个界面优美，使用简单的 Wiki 系统，于是一个属于我自己的 Wiki 系统，James Pan's Wiki 就出现了。

在使用 TiddlyWiki 之前，我尝试过寻找 Knowledge Base 之类的东西。然而结果不尽人意。不是不支持静态部署，就是不支持中文搜索。

使用 TiddlyWiki 之后，我发现它也不像一开始想象的那么完美。首先是标注语言的问题。虽然我安装了 Markdown 插件，但是发挥 TiddlyWiki 的全部特性，我还是不得不去学习一个新的小众标记语言， WikiText 。

用了一段时间之后，WikiText 我也算是不陌生了，于是我开始思考一个问题：TiddlyWiki 是一个单文件的 Wiki 系统，随着我用它记录的知识越来越多，文件体积会越来越大，直到有一天，完整加载整个页面的耗时变得无法接受，我将它部署到互联网上就变得没有意义，于是我存放在 TiddlyWiki 中的知识将会和 TiddlyWiki 一起退化为一个单机系统。

一个空的 TiddlyWiki 就已经 1.8 MB 了，安装了必不可少的 Markdown 插件和 Mathjax 插件，再写上几个词条，页面膨胀就到了 2.2 MB。虽然我还不不知道一年之后这个页面会是多大，但是我已经能想象到它退化成单机系统的凄凉。恐怕这是所有的单页 Wiki 都绕不过去的坎。

其实 TiddlyWiki 提供了一个残缺的解决方案。对于使用 Node.js 本地部署的 Wiki，可以使用一些命令来导出静态站点，代价就是静态的 Wiki 页面没有 js，从此失去了搜索等一系列杀手级的功能。

假如我成功地 hack 了 TiddlyWiki，使它能够生成带 js 的多页面静态站点，那么我将直面一个问题：搜索。在静态网站上使用搜索有几种方案，一种是使用 Google 的站内搜索，一种是使用 Swiftype ，再有就是使用纯 js 实现的客户端搜索引擎，比如 lunr。

Swifttype 我是没用过，其他两种方案我都有尝试。先说 Google，使用 Google 的好处自不必说，坏处倒是有几个，也还蛮严重的。首先是梯子的问题，毕竟访问 Google 不是那么的方便；其次是爬取的时间、索引的权重之类的参数，没法控制。

然后说说客户端搜索引擎。自从 HTML5 兴起之后，前端技术开始有燎原之势。虽然纯前端技术能够实现很多原本应该由后端实现的功能，但是它也有着不小的局限。就以客户端搜索引擎 lunr 为例，lunr 借助 search_index.json 实现索引和搜索。

首先是 lunr 不支持中文搜索，而且今后很长一段时间都不会支持中文（中文在计算机的世界里真是二等公民，把它发展为一等公民的重任就落在了我们肩上）；其次，就算我fork 了 lunr 并让它支持了中文，分词之后生成的索引文件恐怕也是不小，如此一来将 TiddlyWiki 输出成多页面形式的意义就不大了，只不过是把难以接受的大文件从 Wiki 文件变成了索引文件而已。

也许这就是个人 Wiki 之殇。因为是个人使用的 Wiki，所以想要尽可能简单易用，不要有服务器不要有数据库。因为尽可能的简单，所以只能用平面文件来组织；因为尽可能易用，所以不能用强大复杂的技术；因为要好用要 eye candy，所以要用酷炫的客户端技术。因为不能用复杂的技术，加上没有服务器没有数据库，所以搜索功能和索引文件只能放在客户端。因为使用了客户端搜索技术，用户迟早面临单文件过大的问题。

最终，Wiki 的管理、搜索只能在本地进行，部署到互联网上的 Wiki 只能残缺的静态站点，没有搜索，没有互动，只有文本以及超链接。