• 早年（大约九几年）我管理自己笔记的主要方式全靠普通的目录和文件命名。一般和一件事儿相关的东西会放在一个目录下，然后根据内容细分子目录和补充纯文本格式的简要说明。比如 Java 开发的学习资料会建立顶级目录“Java”，下面又会建立目录“Book”存放电子书等文档，和 Book 同级又会有 Gui 目录， Gui 目录下有 SWT 目录， SWT 目录下堆放示例程序和安装文件等等。如果文件积累多了，再在 SWT 下划分出 Soft 子目录专门存放安装文件。到读研的时候高级了一点，会把这种方式搭配桌面搜索工具（比如 Google Desktop ）一起用。在目录多了以致自己忘了一些东西放在什么地方的时候可以搜一下找一找。（说实话，我是经常忘的，所以经常要搜。。）
• 比目录方式高级一些的用过专门的笔记管理软件。真正重度使用过的是“良友收藏家”，可惜这个软件改叫“小蜜蜂”完全重写以后似乎慢慢消声灭迹了。当时觉得也是挺好用：单一数据库的存储方式，任何东西都可以靠粘贴弄进去，大文件也可以当作附件贴进去，搜索功能也还不错。问题在于数据库体积特别庞大以后不大容易备份和维护，再就是其他软件很难读取笔记管理软件里头的内容。结果在我很少使用 Windows 系统以后就不大碰这东西了。
• 在互联网兴起以后，大多数好东西都可以从网上搞到了。结果就是我的浏览器里头积累了大量大量的书签链接，多到浏览器都慢了。这样又不得不给书签划分目录和子目录。最后差不多我自己都快想不起来一个东西我给收藏到什么地方了。。再后来出现了 Delicious ，靠谱地支持书签同步和书签 Tag 。从此书签也就主要靠搜索去找，靠 Tag 去组织和相互关联。但又感觉不大容易把一堆相关的知识组织起来，形成系统的文档。
• 近年来很多牛人都是用博客来做知识积累。印象里还有的是早年看过 车东^2 ，近年来觉得 善用佳软 搞得不错。博客这个平台整好了关注度不错，书写方式的支持也挺丰富，也算便于查找。但总感觉如果在上面写得东西太多太杂会把文章分类搞得很复杂，文章标签也很复杂，组织性有限。所以我的博客现在主要还是写点自己唧唧歪歪、杂七杂八的东西。

最后长期重度使用的还是 Wiki 。我认为其中的根本原因在于：互联网现在是当今最大的知识库，而 Wiki 中信息的组织方式是最接近互联网的！使用 Wiki 可以很简单：新建 Wiki 页面说清主题，然后记录下网址或者干脆只记录有效的 Google 关键词就成。只要关键词合适，即使原始网址被删除了，就仍然可以搜索出更新、更靠谱的有用内容。或者也可以搞得复杂点，在 Wiki 里头条分缕析地写篇文章，把该记录的链接都记上，该贴的图都贴上，该上传的附件都上传了。甚至可以整合多个页面，编辑语法方便，搞成一本书也是可以的。简单来说，互联网的核心就是通过链接来组织各种媒体资源， Wiki 也是如此。

我查找一个东西的时候喜欢把有点关系的页面都留着，等页面比较多了并且事儿也查明白了，就集中整理到 Wiki 里头，将来再查特别方便，补充内容也很容易。我的火狐里头曾经就出现过长期同时开启2、3百页面标签的壮观景象。我现在自己用的 PmWiki ， 只需要 PHP 环境，都用不着数据库。在网上很容易找到可以部署它的空间，就能轻松拥有一个随时随处访问的个人知识库了。

要说 Wiki 的缺点倒也不是没有。它不如博客更新那么有条理，所以不大容易像知名博客那样长期获得关注。 Wiki 吸引访问，主要是依靠搜索引擎的，在意访问量的话，就需要下功夫加强 SEO 优化来弥补。或许，恰恰这样才是最“互联网”的方式！最后总结一下用 Wiki 作个人知识管理/笔记管理的优点：

• 随时互联网访问（本身就是个网站）
• 便于共享（地址贴出来就行）
• 编写内容容易（ Wiki 语法简单易用）
• 格式丰富、表达能力强（上传附件、图片，通过插件支持 Latex 数学公式等）
• 内容结构清晰（文章内章节结构、文章间的 WikiWord 链接）
• 便于查找/搜索（站内搜索及 Google ）
• 运行环境简单（ PmWiki 仅要求 PHP ，都不需要数据库）

附图似乎是维基百科中某一部分的链接结构。其中点的大小表示页面被编辑的频率，线表示页面间的链接关系。下面的图片来自：http://en.wikipedia.org/wiki/File:Visualization_of_wiki_structure_using_prefuse_visualization_package.png 。

××××

PS：什么叫忙呢？我想就是电影光下不看，博客有一大堆想法但是没功夫写。。

PPS：一直想通过手机更新博客，可是大段文章的输入手感还是跟电脑差太多。。

lighty中博客站点的配置文件要这么写：

$HTTP["host"] == "blog.elias.cn" {
  server.document-root = "/home/public_html/elias"
  magnet.attract-physical-path-to = ( server.document-root + "/rewrite.lua" )
}

这里能用magnet.attract-physical-path-to的前提是mod_magnet已经安装并启用了，否则在lighty的error.log会报错。Debian里mod_magnet是单独的一个包，叫做lighttpd-mod-magnet，安装以后就可以把mod_magnet加入lighty的配置文件了。

然后再在博客站点的根目录新建一个名为rewrite.lua的脚本文件，文件内容为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

function serve_html(cached_page)
  if (lighty.stat(cached_page)) then
    lighty.env["physical.path"] = cached_page
    print("Serving cached page: " .. cached_page)
    return true
  else
    return false
  end
end
 
function serve_gzip(cached_page)
  if (lighty.stat(cached_page .. ".gz")) then
    lighty.header["Content-Encoding"] = "gzip"
    lighty.header["Content-Type"] = ""
    lighty.env["physical.path"] = cached_page .. ".gz"
    print("Serving gzipped page: " .. cached_page .. ".gz")
    return true
  else
    return false
  end
end
 
attr = lighty.stat(lighty.env["physical.path"]) and lighty.env["physical.path"] ~= lighty.env["physical.doc-root"]
 
if (not attr) then
  lighty.env["uri.path"] = "/index.php"
  lighty.env["physical.rel-path"] = lighty.env["uri.path"]
  lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"]
 
  query_condition = not (lighty.env["uri.query"] and string.find(lighty.env["uri.query"], ".*s=.*"))
  user_cookie = lighty.request["Cookie"] or "no_cookie_here"
  cookie_condition = not (string.find(user_cookie, ".*comment_author.*") or string.find(user_cookie, ".*wordpress.*") or string.find(user_cookie, ".*wp-postpass_.*"))
  if (query_condition and cookie_condition) then
    accept_encoding = lighty.request["Accept-Encoding"] or "no_acceptance"
    cached_page = lighty.env["physical.doc-root"] .. "/wp-content/cache/supercache/" .. lighty.request["Host"] .. lighty.env["request.uri"] .. "/index.html"
    cached_page = string.gsub(cached_page, "//", "/")
    if (string.find(accept_encoding, "gzip")) then
      if not serve_gzip(cached_page) then serve_html(cached_page) end
    else
      serve_html(cached_page)
    end
  end
end

这个lua脚本源自tempe.st和thedomz.com，不过我对其中的第23行做了修改。原始版本永远不会对博客首页启用缓存，因为lua脚本仅在请求的原始地址不存在时才进行重定向操作，但首页也就是博客根目录总是存在的，因此也就永远不会被重定向到静态缓存。我对这一行的修改就是让脚本在请求的地址与站点根目录相同时也启用静态缓存重定向机制。

这样折腾完之后，调整一下站点的Permalink规则，使之不要掉进wp-super-cache的忽略规则里面，应该就可以了。在页面的html源代码最后，应该能够看到super-cache的时间戳。正常工作的wp-super-cache是不会在频繁刷新页面时每次都更新这个时间戳的。附带说一下，我这个博客是没有使用wp-super-cache的，本文提及的内容应用在了blog.laiyonghao.com。

1. 首先，这个脚本是有程序版本要求的，SimplePhpBlog 0.4.8左右的版本应该没问题，WordPress则得是2.3.*，版本不对的话脚本会报错。
2. 先用WordPress程序完成初始安装；
3. 执行“./WordPressImport.pl -noratings -host localhost -user 数据库用户名 -password -wp_password WordPress的admin密码 -database 数据库名 -import sphpblog的所在目录”，然后按照提示输入数据库访问密码即可。
4. 如果报错，通常是因为缺少Perl的必要运行库引起的，已知应该会用到Data::Format和DBD::mysql，可以考虑使用cpan安装。
5. 登陆WordPress后台，检查数据正常之后，可以将WordPress升级到最新版本，并安装喜欢的插件。
6. 建议安装并激活Word Press里面的bbcode插件，因为我遇到原先SimplePhpBlog中使用的一些编辑语法可能未被完全转换，比如有些url链接仍然是用的bbcode语法。激活bbcode之后移植过来的数据基本上又可以正常显示了。（BBCode 1.0.1版本对标签的解析存在一点Bug，会生成带多余等号的链接地址，参见关于本站页面的说明。
7. 目前文章中引用站内图片路径都是错的，所以显示不出来。把原先SimplePhpBlog里面images目录整个传到WordPress的“wp_content/uploads”目录下，然后修改并执行以下sql语句来修复站内图片链接：“update wp_posts set post_content = replace(post_content,’src=images/’,'src=http://www.YOURSITE.cn/YOUR_BLOG/wp-content/uploads/images/’)”。于是图片也能正确显示了。这里的写法和WordPress自带的媒体库管理工具一样，使用的是该死的绝对路径，将来修改博客的域名或地址时还得再重新改站内图片路径。
8. 这样日志、评论、展台都能够被正确移植过来。也许因为我的文章分类信息全是中文，迁移后的文章全部变成没有分类了，可以试着用Word Press的“Batch Categories”插件来批量调整。但我在修改了默认分类的名字之后，Batch Categories就死活搜索不出来已有文章了，最后我手工一个个调整的文章分类。建议尝试一下在导入SimplePhpBlog数据后，在旧版本的WordPress上使用“Batch Categories”试试，如果调整成功了再继续升级WordPress。

Ps:转换完了感觉有一点不满意：友情链接是按字母排序的，恐怕有些兄弟姐妹难免会对排座次有意见。

前些天留言时自称ID：liuwei的同学与老板对我博客的看法是完全一致的，抛开我个人需要因此而自省的启发意义不谈，这说明liuwei同学具有靠谱的科研素养和认真努力的主观愿望，是个培养的好苗子。

当然，老板对我在博客上写搞到了什么好东西这种事情提出了一些看法，我觉得老板说得很深刻。只是，我的本意也只是简单说明“我是如何选择并使用解决一个问题的工具的”，比如上一篇我的意思就是从事计算机科学研究，那么苹果出的笔记本会是一种不错的工具。只是恐怕因为我对文字驾驭的效果不佳，以至于这样的意思没能写出来。总之还是应该反省一下，考虑的一个方向是仔细点儿整理Wiki上的内容，搞得靠谱点儿。

此新闻从驱动之家网站看到。

至于为什么Blog的名字里还有一句“谁和谁或是自己”，我却是实在想不起来了……

这两天偶尔浏览，发现一个04年出现的叫做simple PHP blog的程序，简单易用、而且使用的人很多，目前虽然不是很完善，但是对中文的支持还不错，程序改进也不慢，所以犹豫了一天，决定暂时更换为这个blog程序了。pmwiki的blog模块我还是要等，但我估计在05年之内可能还不会很完善。至少05年，我会用simple PHP blog了，用了再说。

也许有人会问我是怎么把pivot中的数据转移入simple PHP blog的，我的答案很简单，是手动贴过来的：在本地架设php服务器，先把系统日期修改为与帖子时间差不多的日期，然后一个一个把帖子和评论手动贴过来。没办法啊，pivot的后台访问模块的代码我实在看不懂……好在目前要贴的东西不多，花了一下午时间算是搞定了。体会是：simple PHP blog目前的文字样式表达能力还不大令人满意，至少，这个东西应该支持直接贴html代码才好吧。

现在看来，很多时间都花在更换程序和转移数据上了，所以具体的东西都没什么进展……

本条目的正文部分给出此问题的解决办法。

首页的模板中有这样一行：<title>[[weblogtitle]] » [[title]]</title>，我的Pivot设定的标题正好是中文而且是UTF-8格式，这样，当浏览器用GB2312编码来解释这一行的时候，[[title]]也即我指定的标题会变成乱码，而且把“</title>”的左半个括号吃掉，于是<title>标签没有被关闭，后文关于页面编码设置的部分、页面正文部分均无法被正确解析。

我们的目的是：即使使用GB2312来解析<title>这一行，那么仅应该是标题本身的文字成为乱码，但是</title>标签不要收到影响。于是我在“</title>”前面加了一个空格，也即原来的行变成这样：“<title> [[weblogtitle]] » [[title]] </title>”。注意，“[[title]]”和“</title>”之间有一个英文空格。

如法炮制所有模板文件中的<title>行，重新生成Pivot中的所有页面，于是问题解决：大多数时候浏览器可以自动使用UTF-8格式显示我的Blog上的内容了，即使强制用GB2312显示，也能显示出乱码，而不是容易让人以为没有这一页面的空白。

事实上，最近Pivot的支持论坛上已经有不少讨论如何让Pivot支持亚洲语言的办法了。其中有个叫envia的韩国人做了很多工作，而且最近给出了一个让Pivot支持韩文的补丁。对PHP有经验的兄弟不妨直接参考他的方法来搞定中文。我的方法不如他的完善，但一定可以工作，否则你也就不会看到我这个Blog了（我采用的是Pivot1.14版本）。

根据他的工作结果，我进行了简化（并不是说简化更合理，而是为了方便，以及，我能够理解……）。需要完成下面几个步骤：

　1，在Pivot的所有源代码中将函数"htmlentities"修改为"htmlspecialchars"； 　2，在pvlib.php文件中，把函数"entify"和"unentify"的函数体都注释掉； 　3，把pvl_chs.php另存为UTF8编码格式（Windows自带的记事本就可以完成这件事情），并更名为pvl_chs_utf8.php； 　4，修改Pivot的所有网页模板，把"ISO-8859"这样的编码信息全部修改为"UTF-8"。 　5，照一般步骤安装Pivot，在语言设置中选择使用pvl_chs_utf8.php。 这样，Pivot就能工作在UTF-8格式下了，评论能够正常显示了。

我的这个方法的局限性在于无法让搜索功能正常工作，或许得借助Google完成这件事情了。