写了一篇文章，用<pre>标签包了一段代码，结果u'\xc9\xab'这样的代码里反斜线\自动消失了。这个事以前也碰到过，直接把反斜线打了两遍，发布文章后就会变成一个了，不过修改文章时，那一个反斜线又消失了。今天认真地查了一下，在WordPress源代码里逛得头晕，于是到WordPress Trac里拿"backslash"做关键词搜了一下，找到了3个月前有人报的bug：backslash disappears in <pre>。8月26号报的bug，现在也不处理，唉。

按照他的提示，在/wp-includes/functions-formatting.php文件里找到了wpautop()函数中的这句 $pee = preg_replace('!(<pre.*?>)(.*?)</pre>!ise', " stripslashes('$1') . stripslashes(clean_pre('$2')) . '</pre>' ", $pee);。按照PHP文档里stripslashes()函数的说明，它应该是剥去单引号、双引号以及反斜线之前的那个反斜线，不过实际操作中，这个函数好像把每个字符前面的反斜线都给剥去了。

这事好像很麻烦，好像PHP文档并没有说清楚，而众多PHPer都误用了。下面的 一条留言里提到:"If you want to deal with slashes in double-byte encodings, such as shift_jis or big5, you may use this"双字节的编码，除了ASCII和欧洲的那几个，其他的不都是双字节编码？晕倒了。

照着他的函数修改了一下，得到下面的函数：

function stripslashes2($string) {
  $string = str_replace(array("\\\"","\\'","\\\\"),array("\"","'","\\"), $string);
  return $string;
}

然后，把第83行的stripslashes(clean_pre('$2'))改成stripslashes3(clean_pre('$2'))就可以了。

今天照着《WordPress执行效率问题》一文检查了一下我的Blog首页执行的SQL语句。具体方法那篇文章里讲了，就是在wp-config.php文件里添加 define('SAVEQUERIES', true);，再在footer.php文件的最后加上一句<!--<?php var_dump($wpdb->queries); ?>-->。刷新Blog首页，就可以在页面源代码的尾部找到整个页面执行过程中所执行的所有SQL语句。

我的Blog打开的WordPress自带的cache功能，首页需要32次查询，执行时间1s多一点。查了一圈，就是我的Latest Comments插件占了9项，给它加了个cache功能，现在首页已经降到23次查询，执行时间也降到1s以内，8错8错。

很疑惑，为啥他说他有6万篇文章。我大概看了一下，不到500篇文章吧。而且他的大多数查询和我一样，耗时只有零点零零几秒，而查询wp_posts表的几条耗时很多。我的SQL查询语句耗时最多的也就0.01秒。好奇怪，难道wp_posts表被塞了太多垃圾？

一直用Windows自带的telnet程序登陆DreamHost的shell，不过Telnet连接中，用户名和密码是明文传输的。这年头，World Wide Web都诞生15年了，HTTP协议也有了使用SSL连接的HTTPS，FTP和Telnet之类的老协议也有相应的加密连接版本。FTP对应的是SFTP，Serv-U支持，不过好像没多少人用。Telnet对应的是SSH(Secure Shell)。Windows自带的telnet程序不支持SSH协议，找了一下，最有名的就属基于PuTTY的PieTTY了。PieTTY给PuTTY加了个图形界面，又增加了很多设置选项。整个程序就一个文件，下载下来运行即可。连上我的DreamHost shell，感觉速度比telnet快很多。telnet使用的是23端口，SSH使用的是22端口。或许大家都用telnet，少有人用SSH。又或者，SSH协议在加密传输的时候顺便进行了压缩。我把编码方式设置成UTF-8，这样在python命令行里输入的汉字就不再是GB18030而是UTF-8编码的了。
程序有英文和繁体中文两种界面，在我的Windows XP SP2里，繁体中文菜单的显示没问题，其他地方比如对话框就会乱码。程序支持阴影，支持透明，支持Glass Window Mode，就是不显示程序的边框、标题栏和菜单。

以前用telnet，在python命令行里，如果一条命令输错了就麻烦了，因为左右键、后退键、删除键都没有用，按下后只会出现些乱七八糟的字符。在选项里面乱调了一圈，每个选项都依次试一试，最终后退键盘正常了，还有bash里可以用HOME键了。另外只要选中一段文字，这些文字就会自动复制到剪贴板，再点一下右键，文字就从剪贴板里粘贴过来了，比起Windows命令行方便些。

只不过，软件的设置都保存在注册表，唉，不绿色呀。

或许可以开始玩玩BBS了，比如传说中的ptt，hoho

今天开始看书学python。虽然2005年10月就开始关注python了，还订阅了python邮件列表，但是一直没开始学。DreamHost自带python，输入python命令默认启动的是python 2.3.5。另外还有python 2.4.1可以用。我只是个初学者，知道新版本新增的内容都是我现在用不着的，知道哪怕N年前的python 2.2也够我用的了，不过总想弄个最新版来玩玩，嘿嘿。

找了《在dreamhost上安装自己的python》，又找到DreamHost文档-Python。照着一步一步安装。

安装步骤如下：

wget http://www.python.org/ftp/python/2.5/Python-2.5.tgz
tar -zxvf Python-2.5.tgz
cd Python-2.5
./configure --prefix=$HOME/lib --enable-unicode=ucs4
make
make install

首先用wget命令下载，然后tar命令解压，然后安装。DreamHost文档里的说明没有加--enable-unicode=ucs4，我查了一下，这个是表示python内部表示unicode的编码的方式为UCS-4，而非UCS-2。在 这里查到，可以用sys.maxunicode命令检查当前python编译时使用的参数，返回1114111为--enable-unicode=ucs4，返回65535为 --enable-unicode=ucs2。我看了一下，DreamHost的python 2.3和python 2.4都是ucs4，那么我也用ucs4吧。

python 2.5已经安装好了。如果想把python 2.5设置为默认版本，那么做下面的设置：

mkdir $HOME/bin
mkdir $HOME/bin/python
mkdir $HOME/bin/python/bin

ln -s $HOME/lib/bin/python $HOME/bin/python/bin/python

然后，在$HOME.bash_profile里加入一条：

export PATH=$HOME/bin/python/bin:$HOME/lib/bin:$PATH

重新载入配置文件：source ~/.bash_profile，再敲入python命令，显示：

Python 2.5 (r25:51908, Nov 23 2006, 19:51:08)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

安装好了，现在我有4个python可以用：

[burns]$ python2.2 -V
Python 2.2.3+
[burns]$ python2.3 -V
Python 2.3.5
[burns]$ python2.4 -V
Python 2.4.1
[burns]$ python2.5 -V
Python 2.5

python 2.5向下兼容不知道怎么样。为了学python，找了vim中文文档看了一下，以便在shell里修改文件，免去ftp来ftp去的麻烦。不过好像python代码没有被自动Highlight啊，不是说vim支持代码高亮么？花了两个小时研究了下，最终知道该在.vimrc里加一句"syntax on"，555~～用vim打开了C++,python,PHP代码看了一下，加亮的好难看呀...

昨天在V2EX看到有人问“python里怎么用unicode字符”。在网上查了一下，这事好像比较麻烦。Unicode的事我大概知道，找到 这篇文章，大概看了一下，大意是说：python里，unicode是一种类型，上面安装时的--enable-unicode=ucs4参数就是把unicode类型设置为UCS-4编码格式。而string类型则是bit流，没编码类型的。这和PHP很象啊。他们之间的转换时，string会被指定一个默认编码方式，可以用 sys.getdefaultencoding()函数看到。所以，要么设置python环境的默认编码方式，要么手工encode和decode。另外，源代码中的 u'字符串'，在python console里，那个u并非函数一样可以把后面的字符串转换为Unicode编码，console里的字符串应该是不做转换，直接按字节设置成UCS-4。

>>> s=u'\xc9\xab'
>>> s
u'\xc9\xab'
>>> len(s)
2
>>> type(s)
<type 'unicode'>
>>> print s
色

而Windows的console里默认编码应该是CP936，所以在python console里直接用u'字符串'这样是不行的，print命令检测到这是一个unicode类型的变量，就会将其转换为CP936再显示出来。而py文件里的源代码，则可以在文件开头指定文件编码。对于u'字符串'，python会自动将其按照该编码方式转换为UCS-4，就像 limodou所说的。

#!/usr/bin/env python
# -*- coding: UTF-8 -*-

另外还查到一句话：python在启动时会自动执行site.py这个程序，然后会自动将sys.setdefaultencoding这个方法删除。因此你可以通过reload(sys)，然后就可以使用了。[ via]

So，和WordPress一样，python文件还是尽量用UTF-8编码的好。

今天看了精神奕奕的两篇文章：《Apache2 使用 mod_gzip 增進傳輸效能》和《Apache2 使用 mod_deflate 增進傳輸效能》。看起来这是位WordPress前辈啊，05年初就开始接触了WordPress。

文章介绍了使用mod_gzip模块和mod_deflate模块压缩传输数据，提供传输性能的方法。WordPress本身支持gzip压缩输入，不过仅限于WordPress输出的页面，比如Blog页面以及WordPress后台页面等等。而其他地方，比如模版的js文件和CSS文件，因为这些文件不用被PHP引擎执行，没经过WordPress的处理，所以没有压缩。不过，K2模版的几个js是特例，因为他们都是做成PHP文件，包含了wp-blog-header.php文件，并在文件启动了gzip压缩。

我的服务器安装了mod_deflate模块，到Apache 2.2 文档里看了一下，找到 mod_deflate模块的文档。精神奕奕的文章里说的DeflateCompressionLevel等命令都不能在.htaccess文件里使用，只能用AddOutputFilter命令[ via]。于是在.htaccess文件里加上：

<ifmodule mod_deflate.c>
AddOutputFilter DEFLATE css js txt
</ifmodule>

这样，当传输以css,js,txt为扩展名的文件时，Apache将使用mod_deflate模块对其进行压缩后再传输。这三种文件都是文本格式的，压缩起来效果明显。还有html和xml文件也可以压缩，不过我的网站上基本没有这两种文件。Apache应该是按照最终要读取的文件的扩展名来判断的，刚才关了WordPress的gzip压缩，然后加上了在.htaccess文件里加上了html，发现我的Blog文章页面并没有被压缩。而这种压缩是在PHP等脚本解析程序执行完了之后才进行的，如果WordPress没有gzip压缩功能，倒是可以利用mod_deflate来对页面进行压缩，hoho

测试了一下，K2自带的style.css文件，未启用前Content-Length是15914字节，跟文件大小一致，启用后Content-Length只有4415。WordPress 2.0.5的/wp-admin/wp-admin.css文件，原来大小是15047字节，启用DEFLATE后Content-Length只有3990。

这个效果还是很明显的，对于网络传输速度不太好的服务器还是有点用的。而默认压缩等级没法调，因为我用的是虚拟主机。现在也不知道该怎么看服务器的默认压缩等级，不过看精神奕奕的效果：启用前12911字节，启用后3342字节，大概效果也差不多。

昨晚在DreamHost的shell里wget了一个文件，想传到我的ftp上，却又急着回家吃饭。用ftp命令put上去，一断开连接，传输就停止了。觉得Windows都有at命令，Linux应该有定时执行的功能吧。上网查了一番，找到这篇活用Linux的后台任务，原来只要在命令后面加上&符号就可以让任务在后台运行了。不过，这只是让任务在后台执行，断开连接一样会被结束掉。又找到这篇《用nohup命令让Linux下程序永远在后台执行》，介绍了nohup命令和ncftpput程序。于是用了这么一条命令：

nohup ncftpput -u yskin -p *** ftp.server.com /wwwroot 123.zip&

执行后，用jobs命令查看到他正在运行，然后用exit命令退出shell，ftp到我的ftp服务器上，发现文件大小在不停地增加。今天早上上网，发现文件已经传完了。HOHO，自己睡觉让机器干活，真爽。

好像jobs命令只能显示当前连接中的job，退出后再telnet进去就显示不出来了。另外有一个小发现，ftp服务器上的文件时间被设置过了，看来ncftpput程序会自动设置上传文件的时间呀，我用过的ftp客户端好像都没有这样的功能，以后有空要查一查。

正在看QQ聊天记录。现在懒得开QQ，隔几天登陆一下http://group.qq.com看WordPress群(8191389)的聊天记录。腾讯个小气鬼，一点纯文本的聊天记录也只给存7天，小气死了。

11月14号，levis/强龙(16723852)问，怎么WordPress后台的评论页面不能翻页啊？我看了一下，确实不能翻页，只能显示一屏20条评论。我都没在意过这件事，因为评论不多，而且我又每天上网检查，很少有机会查看20条以后的评论。在WordPress源代码里看了下，好像有评论开始位置的设置，但是这个功能没有做全。

在http://域名/wp-admin/edit-comments.php这样的评论页面里可以查看最新的第1~20条评论，在URL后面加上 ?&offset=1，回车，这样就可以查看第21~40条评论了。后面的依此类推。呃，还是有个小bug，第二页的序号21~40显示成20~39了，呼，以后要引以为戒呀。

另外，可以查看一篇文章的所有评论，只要在文章管理页面点那个评论数就可以了。比起在所有评论里一页一页的查找，这样还方便些。如果在查看文章时要看看某个评论的具体信息，比如评论者IP什么的，只有拿着文章的ID，输入 http://域名/wp-admin/edit.php?p=ID号即可。不知道ID号？以管理员身份登陆进WordPress后，在文章页面，把鼠标移到编辑文章的那个按钮上，然后看一下状态栏就可以了。

今天看到这篇文章里提到的在Bloglines里认领自己的feed的功能，顺着他的提示找到车东的《find me: bloglines》。

Bloglines提供的这个功能挺不错的，不过6月30号就出了这个功能，却好像没多少人提起过，看来用的人很少啊。进入Bloglines，点页面右上角的"Account"，再点击"Publisher Tools"，即可进入"Claim Feed"页面。点"Begin Claim"按钮，填入自己Blog的地址，点下一步，Bloglines就会在数据库中搜索出所有指向这个Blog地址的feed，列表显示出来。选择要认领的feed，点下一步，Bloglines会给出两个字符串，一个Claim Key，类似<!-- ckey="4E9CFF29" -->这样，要求发到一篇新的Blog文章里，以便feed里收入这个key；一个user key，类似<!-- ukey="7A0BED31" -->这样，要求写入Blog模版，以便输出到Blog首页里。这两步做好了以后，点击"Verify My Claim"按钮，Bloglines服务器将对这两项进行检查，如果检查通过，这个feed你就成功认领了。

我的Blog地址搜出来4个，用keso的地址(http://blog.donews.com/keso/)试了下，好像可以搜出来很多呀。除了我自己用的评论feed，我的Blog的feed总共有3个订阅地址。大概看了一下，3个地址的Bloglines订阅数分别是：

而在FeedBurner后台里，显示Bloglines的订阅数为13。

3个地址都验证过以后，即可对他们进行管理。正如"Claim Feed"页面上方说明部分所说，你可以修改feed的Description部分，修改feed的标识图片和图标(Favicon)，设置是否允许Ask.com和Bloglines搜索这个feed。最重要的是，你可以设置这个feed为另一个feed的副本。比如，我想让大家都订阅http://yskin.net/feed/这个地址，我就将另外两个地址设置成这个地址的副本。设置好以后，回到Bloglines，我原先订阅的http://feeds.feedburner.com/Yskin这个地址已经自动改成新的地址了。

明天再过来看效果，这下，以前用FeedBurner转向插件后的遗留问题终于给解决了。看Bloglines的新闻里说，"If you set up a 301 redirect, Bloglines will automagically set that feed as a duplicate to the new feed after a week or two."FeedBurner转向插件以前用的是302，是在.htaccess文件里利用MOD_REWRITE重定向的，2.1版以后用的是307。看来不用301是对的，要是用了，feed订阅地址就全转向FeedBurner烧录过的地址了。

车东的文章里说，抓虾也有类似的功能，不过要手工给管理员提交申请。唉，真麻烦呀。刚去抓虾看了一下，我的原始feed有34个订阅，FeedBurner烧录的有22个，另外RSS 0.92和atom还有分别有三个和两个，而FeedBurner只认了28个。希望抓虾也能尽快完善这方面的功能呀。

Blog系统(比如WordPress)，为了兼容各种RSS Reader，提供了RSS 0.92, RSS 2.0, Atom三种feed输出。后来，我们又因为流量，以及为了feed地址固定，而使用FeedBurner烧录feed，让大家都订阅烧录过的feed。再后来，因为怕FeedBurner被封，我们又用FeedBurner转向插件，把3个原始feed地址转向到FeedBurner，这样可以在被封以后立刻停止转向，避免因feed地址变换而损失用户。现在，我们要处理订阅者分别订阅4个feed的问题，希望所有人都只订阅那个RSS 2.0的原始feed。唉，这个小小的feed咋这么麻烦呢。

Update：Bloglines的订阅数已经更新了，现在是17+11+2=30个。FeedBurner那边也更新了。不过，Bloglines的30个完全比不上抓虾的34+22+3+2=61个。抓虾在最近开始读取feed的任何更新，不再象以前那样只读取初始文章而不管文章更新了。这样好，除了GFW的问题不能读取Technorati的feed以外，抓虾和Bloglines也没什么区别了。

今天在风言疯语之IT罗盘那里看到：中文Wikipedia解封了。原来其他语言的Wikipedia早已解封，中文维基百科现在也解封了。试了一下，中文维基百科果然可以访问了，就是速度还是有点慢。中国大陆地区访问Wikipedia都是连接到Wikipedia设在韩国首尔的服务器211.115.107.162。刚才在百度搜索了一下， site:wikipedia.org可以搜索到76页。维基媒体基金会或许应该考虑扩充一下韩国的服务器群，以便应付大量中国网民的访问，还有疯狂的百度服务器的访问。在中文Wikipedia主页看到：“2006年11月12日，中文维基百科成为第12个拥有十万条条目的维基百科语言版本。”[ via]中文维基百科的logo也换成了庆祝达到100,000条目的logo。(虽然做的有点粗糙，呵呵)唔，难道这次解封是对十万条目的献礼？

中文维基百科从2005年10月被封到现在，整整一年多了。期间说过很多次解封，但愿这次是真的。以后写wiki再不用偷偷摸摸的了。现在中文维基百科条目数已超过十万，不过还比不上英文Wikipedia的148万条目。这次解封以后，应该会有更多的大陆网民开始写Wikipedia。虽然Wikipedia还是有一些问题，尤其是英文Wikipedia里问题更严重。发表在纽约客的 《Wikipedia之狂想》一文中介绍了一些，我也在后面写了一些对中文维基百科的看法。不过，虽然有这样那样的问题，Wikipedia还是在持续发展着。我们可以提出Wikipedia的不足，甚至不看好这一模式，不过我们不能否认那么多维基人做出的这些成就。也许一些条目写的不怎么样，不过还是不可否认Wikipedia上一些好的条目给我们带来了很多帮助。我们中文维基百科前面还有11位，分别是：英语、德语、法语、波兰语、日语、荷兰语、意大利语、葡萄牙语、瑞典语、西班牙语与俄语。争取能早日赶上他们。

刚才上去编辑了一下WordPress条目。发现这个条目在这几个月被编辑过几次，看来WordPress还是有很多人关心的。在英文Wikipedia中WordPress条目的讨论页里看到一句话:"Did you notice how Wikipedia and Wordpress's favicons are similar ?"[ via]哈哈，还真象耶：Wikipedia;WordPress

到我的pac文件里把wiki的几个域名都删除了，呼。这几个域名原来在第一行，现在第一行变成blogger.com了，另外还有BBC，还有最近新加的Technorati和flickr，我的pac文件还是很长啊，555~～

Update：上午11点，编辑了一个条目，写好点修改一下，就突然就上不去了。等了半个小时，一直连不上，nc连接立刻返回，看来又是被发了reset信号了。不过很奇怪的是，Wikipedia所在的211.115.107.162被封了，upload.wikimedia.org所在的211.115.107.163却没被封。改了一下hosts文件，把中文英文维基百科的域名全指向美国的IP:66.230.200.100，访问就正常了。真是○○××

Update2：下午两点，好了，速度还很快嘞。

Update3：又封咯，哈哈。zh.wikipedia.org不行了，upload.wikimedia.org还行，显然是被封了IP。66.230.200.100也连不上，够狠，TNND。

花了点时间写了一个小插件，以解决中国大陆服务器因无法访问Technorati导致WordPress后台Dashboard页面超时的问题。

因为国内无法访问Technorati，当进入WordPress后台Dashboard时，页面因读取Technorati上的RSS而超时。有时会显示空白页，有时则要花30秒钟才能打开页面。很多人需要在Blog主页点登陆后台来进入WordPress后台页面，这样登陆后会自动进入Dashboard页面。我在Firefox里会一直开着一个WordPress后台的页面，每天下网的时候保存tab列表，第二天上网时再打开。由于有cookie记录登陆信息，所以很少进Dashboard页面。可能有些blogger经常在网吧上网，所以才需要经常这样进后台。

解决办法嘛，手工修改/wp-admin/index.php文件，把Incoming Links部分注释掉是个好办法。[via]还有可以每次登陆后台时用一个后台其他页面的地址，比如http://域名/wp-admin/edit.php。

今天突然想到，可以学Kill Preview插件的办法解决一下这个问题，于是写了这么个小插件，取名叫 Kill Incoming Links。试了一下，应该没啥问题，hoho

Update：升级到2.0，基本全重写了，学Feed Control插件，激活插件和停用插件时自动配置WordPress，使得插件激活后Dashboard中的Incoming Links部分立刻不显示，插件停用后Incoming Links部分立刻恢复。

顺便设置feed的cache的寿命为1天，使得另外两个feed不再频繁读取。

更多信息，请访问Kill Incoming Links主页。