刚才去Bloglines看了下。很久没有进Bloglines了，当时换用了GreatNews，后来又开始用抓虾。我还是比较懒的，虽然订的feed也就10多个，但是还是懒的看。GreatNews可以绿色化，装到U盘里就可以带着到处跑，不过他是使用SQLite数据库的，一更新就要重写数据文件，U盘狂闪，有点怕把我的U盘给搞坏咯。抓虾呢，还算不错，虽然他默认的CSS把分段<p>的上下距离都设为0了，看起来很不舒服，不过我们用的是Firefox嘛，很容易搞定。少了Bloglines的快捷键，多了只显示标题的功能，看一些新闻feed时，按下只显示标题，有感兴趣的按下标题右边的空白就可以单独展开这一项，非常的方便。只显示标题时，一页10个标题正好一屏幕，从上到下浏览一遍，点一下下一页就可以了，如果一直没有感兴趣的，鼠标可以一直停在下一页的按钮上。

我从Blogger.com的时代就开始使用FeedBurner了，FB提供的功能确实不错。转到WordPress后，我还是用FB烧录。6月开始用一个插件(参考《WordPress FeedBurner Plugin》)，可以把WordPress的feed地址自动转向到FeedBurner上的地址，这样也不用费心去修改模版里页面头部的<link>标签了，而且FeedBurner的订阅数统计也会比较准了。

今天在Bloglines和抓虾里看了下我的feed的订阅数，又研究了一下抓虾提供的所谓“抓虾订阅按钮”(在抓虾页面左下角)。这个订阅按钮和FeedBurner提供的显示订阅数的代码差不多，可以在网站上以图片的方式显示有几个人订阅了feed。输入网站地址"http://yskin.net"，提示找到4个feed地址。一时兴起，分别看了下4个地址的订阅数。

最后一个是评论feed的地址，不算。我的Blog还有一个feed地址是"http://yskin.net/feed/atom/"，这个在抓虾里订阅数为0。

看到这些，我突然想到，FeedBurner的订阅数统计会认哪些数据呢，是统计17，还是只统计10或6？(FeedBurner里显示我的Blog现在的订阅数是63，对我来说这真的是一个好大的数字了。开这个Blog随便写点东西，并没有想到有那么多人订阅，弄的我还满大压力的。以前没有压力，有时N天不更新，有时一时兴起，连续写上6个小时，弄出四五千字的一篇文章来，写完的时候才感觉到屁股坐的好痛，手心好多汗。现在有了点压力，再加上被linchanx训斥过更新速度太慢，所以现在超过3天不更新就有点怕怕，就会赶紧找点话题弄出篇文章来。)跑到FeedBurner里看了一下，抓虾的订阅数为10。

这说明，FeedBurner只认了"http://feeds.feedburner.com/Yskin"这一个地址的订阅数。也许现在可以得出FB只认自己地址的订阅数的结论？NO!再到Bloglines里看一下，"http://feeds.feedburner.com/Yskin"的订阅数是6，而"http://yskin.net/feed/"的订阅数是7。从上图可以看出，FeedBurner记录的Bloglines的订阅数是7。

由此可以得出结论，FeedBurner只记录最大的那个值。其实想想也是，keso在《FeedBurner统计与在线阅读器》里说过，FeedBurner记录订阅数的办法是要求rss客户端在User-Agent里写上订阅数。(我想以前看过有些小Blog订阅数几万的估计都是这样作弊的吧)那些rss客户端不可能一天只访问一次，所以FeedBurner只好记录这一天中，所有抓虾的访问中UA里最大的数值。WordPress FeedBurner Plugin这个插件是通过.htaccess文件，让别人访问feed的时候返回一个HTTP 302转向，从而转到FeedBurner上烧录的feed的地址上去。抓虾和Bloglines收到HTTP 302信号后会转而访问烧录过的地址，不过没有修改UA，仍然将原始地址的订阅数写入UA访问FeedBurner。而FeedBurner呢，他只知道访问的是这个feed，不知道是转向过来的。

2006年6月12日开始用的WordPress FeedBurner Plugin这个插件，之前一直是修改header里的<link>标签，指向FeedBurner上烧录过的地址。用了这个插件后，6月20日升级K2 SVN，正好把<link>标签改了回来。目前Blog上只有显示FB订阅数的图片指向烧录过的地址。现在看来，抓虾和Bloglines上，订阅两个地址的人差不多一样多。GreateNews和Firefox订阅数则不会有问题，他们不是在线RSS浏览器，FeedBurner只是根据IP数统计，每个IP算一次。如果希望订阅数更准一下，办法就是让大家统一订阅同一个feed地址。而当初决定使用WordPress FeedBurner Plugin这个插件，就是为了避免FeedBurner突然不能访问的事情发生。前几天FeedBurner刚出现过一次不能访问的事情，弄的很多人不知所措，迅速在Blog上通知大家更换订阅地址。还好只是封了一天，所以说是有惊无险。如果FeedBurner被单向封锁，国内不能访问FB烧录的地址，那么使用GreatNews和抓虾的订阅者会受到影响；如果是双向封锁，FeedBurner不能读取国内服务器上的RSS，那么FeedBurner将不能更新我的feed，所有订阅者都将受到影响。使用了这个插件，我可以在FeedBurner被封锁后迅速解除feed转向，访问"http://yskin.net/feed/"这个地址的RSS阅读器将会读到WordPress本身的feed。这个切换是悄无声息的，因为RSS阅读器是按照GUID区分文章的，这个查看feed的XML代码就可以看到。切换回来后，订阅者除了会发现新文章的下方不再有FeedBurner烧录加上的3个小图片，除此之外，不会感觉到有任何改变，包括旧文章重新显示成新文章等等。

所以，在此希望所有订阅者，修改订阅地址为"http://yskin.net/feed/"，不要使用FeedBurner烧录过的地址，这样的话，可以避免一些麻烦。我也会将侧边栏的FB订阅数图片的链接修改为指向原始feed，并加上订阅说明。Thanks.

我上网的线路应该是深圳电信，123cha查到的结果是“您的ip:[219.134.63.61] 来自: 广东省 深圳市 电信”。从2005年10月就开始在blogger.com上写Blog，当时基本上每天都要上blogger.com网站，一直到2006年4月1日完成往WordPress的迁移，在blogger.com上发表了最后一篇文章告知大家访问新Blog。当时我已经不能访问blogger.com，而且利用普通国外代理服务器也没法访问，感觉是典型的关键词屏蔽。每天通过Tor访问blogger.com的同时，我也会隔上两个小时就直接访问blogger.com看一下，期待着能立刻得到解封的消息。网络上可以看到很多文章都谈到“blogger.com被封”的事情，所以blogger.com被GFW关键词屏蔽，必须使用Tor才能登陆是我的基本认识。一直到现在，我一直对此坚信不移。

最近在wp群里，很多朋友因为my.donews.com的可定制性不强，又没有能力自己买个虚拟主机用WordPress架设Blog，于是又重投blogger.com的怀抱。他们都把Blog发布到blogspot.com上，并且利用pkblogs提供的突破限制的服务让大家访问自己的Blog。我偶尔问起blogspot.com被封，blogger.com本身又要通过Tor访问，那么无论是访客访问还是主人发表文章不是都很麻烦？谁知一群人告诉我，blogger.com一直都能正常访问啊，发布文章还很快呢。于是，我迷茫了，彻底的迷茫了，难道我这一年来的观点都是错的？仔细想想也是哦，blogger.com和blogspot.com是分开的，blogspot.com只是免费提供给大家用的只用于发布blogger.com的网站，而这些家伙只知道发布到blogspot.com里，连很流行的blogger.com搭配sitesled.com或者Blogger Spaces都不知道，怎么会用Tor这种东西？

下午5点和linchanx聊了一下，他也说blogger.com一直很正常，于是我彻底崩溃，掏出Google到keso、幻灭、月光这些牛人的Blog上查找关于“blogger.com被封”的文章。月光博客的《Blogger.com可能解封了》里提到：“虽然Google Blogger长期被封，但是我们依旧可以利用Blogger的FTP发布功能来方便地使用这个服务”幻灭用的深圳电信ADSL，因为最近blogspot.com解封发表的文章 《是幸运还是愚弄？——blogger.com在中国解封？！》里的截图里，上方的blogger条显示正常。再看7月17日的文章 《Blogger.com被印度封杀》里又提到：“首先要声明一下，我一直以来所指的blogger.com被封杀，并不是说blogger.com这个域名无法访问，而是指在它上面开设的地址形式为“xxx.blogspot.com”的blog无法访问。”这下崩溃了，难道全中国就只有我因为rpwt而不能访问blogger.com？幻灭的话说明网络上已经不分blogger.com和blogspot.com了，凡是提到blogger.com被封的文章，也许作者指的是blogspot。

还有这篇文章里，很多人也在说“blogger.com从来没有被封过，被封的一直是blogspot.com。”不过欣慰的是，文章的标题是《blogger好了，blogspot.com还不行》，也就是说作者以前也不能访问blogger.com。keso的《Blogger解封？》说的是“封锁三年半之久的Blogger（blogspot.com）”，说的含糊不清。在下面的留言中也看不出端倪。

天哪，blogger.com到底封没封啊。我刚才又开了IE试了下，blogger.com,www.blogger.com,www.blogger.com/start都不能访问，tracert过去倒是可以，最终到达IP 66.102.15.100。奇怪的是，用nc连接却可以连接的上：

D:>nc www.blogger.com 80
GET / HTTP/1.0
Host: www.blogger.com

HTTP/1.1 302 Found
Date: Fri, 11 Aug 2006 16:11:52 GMT
Server: Apache
Location: http://www.blogger.com/start
Connection: close
Content-Type: text/html; charset=iso-8859-1
Set-Cookie: NSC_cmphhfs-fyu=0a14011b0050;Version=1;Max-Age=1800;path=/

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>302 Found</TITLE>
</HEAD><BODY>
<H1>Found</H1>
The document has moved <A xhref="http://www.blogger.com/start" mce_href="http://www.blogger.com/start"       >here</A>.<P>
</BODY></HTML>

D:>nc www.blogger.com 80
GET /start HTTP/1.0
Host: www.blogger.com

在第二次连接时，敲回车后并没有立即返回页面，不过多敲了几次回车后，返回了大段的html代码。不过IE和Firefox里都不能打开页面，IE提示“该页无法显示”，Firefox提示“连接被重置”。

My GOD,这到底是怎么回事啊。

Update：截包分析，用IE访问www.blogger.com。

一次完整的过程，从DNS解析，到"S","AS","A"的TCP三次握手，然后"AP"发送HTTP请求，接下来就是"R"，意思是Reset。Reset完还要A一下，问你R了没？这边回答，R了。

呼，起码我是正确的，确实被封了，只不过某些人RP好，呆的城市的网警比较宽容？

整整24小时前，K2 0.9发布。

又要忙活了，K2中文包，升级我的模版。

很久很久以前(大概2005年10月~2006年3月)，当时在blogger.com写Blog。当时blogger.com有中文界面，对中文用户也算是比较关心了，不过blogger.com的所有模版里都有一个问题，那就是<title>标签被放在<meta>标签前面。当title为中文的时(比如Blog名为中文或者文章标题为中文)，在IE下会出现显示空白页的问题。昨天Dre·J在群里又问到这个问题，今天过来好好研究一下。

这个问题存在于blogger.com中，WordPress中不存在。先说一下在blogger.com中这个问题的解决办法：在模版的<body>标签下面找到<title>标签，调整成这样：

<$BlogMetaData$>
<title><$BlogPageTitle$></title>

保证meta在前面就可以了。可以参考《感谢Yskin》和《UTF-8字符集网页在IE上会显示空白问题的解决方案》。

这个问题要从浏览器解析html的方式讲起。浏览器读取了页面的html代码后开始进行解析。解析前浏览器要先知道页面的编码方式，然后根据编码方式进行解码，然后才能开始解析。我大概想了一下，浏览器可以从下面3个方面得到页面编码方式：HTTP Header中的"Content-Type"项、返回的html代码开头是否有BOM、html代码中的meta标签。

做了一个小测试，使用Windows 2000 SP4操作系统，IE6 SP1和Firefox 1.5.0.5浏览器。所有文件使用DOS格式换行符。测试代码如下：

<?php
header("Content-Type: text/html; charset=utf-8");
?><html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>你好啊</title>
</head>
<body>
你好啊。
</body>

先不要前面的PHP语句，直接使用html文件，分无meta、meta在title前、meta在title后3种方式，分别做成GBK、UTF-8(no BOM)、UTF-8(BOM)三种编码方式的文件，再分别用IE和Firefox测试。我的Blog所在的服务器上，访问html文件时HTTP Header里Content-Type是Content-Type: text/html。第二遍测试加上PHP语句，用Header函数给HTTP Header中加上Content-Type: text/html; charset=utf-8，再把第一遍做的重新做一遍。

文件中有6个汉字和一个汉字句号，所以UTF-8(no BOM)格式比GBK格式多出7个字节。UTF-8的BOM占用3个字节，所以UTF-8(BOM)比UTF-8(no BOM)多出3个字节。经验证，所有数据都符合这个规则，所以各文件格式没有错误。

PHP不支持BOM，又因为BOM的3个字符在最前面，显示不包含在<?php...?>标签里，所以PHP引擎会3个字符输出，于是输出的html文件也有了BOM。所以这次测试中，为了修改http header而加入的PHP语句不影响最终输出的html文件的BOM。

从测试结果可以看出，浏览器(无论是IE还是Firefox)在解析页面时，首先取HTTP Header中的Content-Type项，如果有写明charset的话就认定页面的编码方式为charset指定的值。如果没有指明，则认定为默认值。根据上表，IE中文版的默认值是GB2312，Firefox中文版的默认值是GBK，不过IE的GB2312好像和GBK没啥区别。然后，浏览器会看一下有没有BOM。一旦发现有UTF-8的3字节BOM，则重新认定页面的编码方式为UTF-8。

然后是解码阶段，解码完成后是解析html的阶段。解析html的过程中，当解析到head部分的meta标签时，浏览器会根据<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />这个语句中的说明，重新认定编码方式为charset后面的方式，中断html解析过程，返回到解码步骤重新解码。

知道了这个步骤，再来看这个表：在加了Header语句设置了HTTP Header后，两个浏览器解析所有页面都是用的UTF-8方式，包括GBK编码的页面。(当然要正常解析GBK编码的文件，可以在title前加上个meta标签标明编码方式。)在上表的下半部分可以清楚的看到这一点。再来看上半部分，在没有加Header语句的页面里，首先浏览器认定页面编码方式为默认值GBK。检测有无UTF-8的3字节BOM，检测到的，认定页面编码方式为UTF-8，解码再解析html，一切正常。如上表所示，上半部分带BOM的页面都能正常显示。如果没有BOM，页面可能是GBK或者UTF-8(no BOM)格式，浏览器会先按照默认的GBK方式开始解码。页面为GBK格式时，无meta时正常，有meta时浏览器解析到meta标签会回头重现按UTF-8方式解码，所以GBK,meta在前或后，无论IE还是FF都是乱码。再看UTF-8(no BOM)的页面，无meta时FF用GBK方式解码下去，最终显示乱码，IE则解码出错，形成空白页。有meta时，Firefox找到meta后回头重新按UTF-8方式解码，所以无论meta在前或在后都是正常；IE则是在meta在前时能够和Firefox一样回头重新解码，当meta在后时，又是解析到title出错，返回空白页。

所以，IE显示空白页的问题，很明显是因为IE的解码程序兼容性差。上网查了下，GBK的编码范围是0×8140-0xfefe。从GB2312-80开始，因为ASCII码的范围是0~127，首字位是0，所以GB2312-80使用双字节，并设置首字位为1。“GBK 亦采用双字节表示，总体编码范围为 8140-FEFE，首字节在 81-FE 之间，尾字节在 40-FE 之间。”[via]UTF-8中中文都是3个字节的，由于Unicode中中日韩的文字都混在一起，可以使用Windows自带的字符映射表查看CJK表意字符的范围，即为汉字的范围。(可以参考我的这篇文章里的图片)3字节的UTF-8编码是这样子的：1110xxxx 10xxxxxx 10xxxxxx，编码范围是8000-EFFF，首字节在80-EF之间，尾字节在00-FF之间。[ via]显然当一段UTF-8编码的文本被按照GBK方式解码的时候，由于有一些编码在GBK中不存在，造成解码程序出现错误。当UTF-8文本被按照GBK的方式解码的时候，前两个字节会被认为是一个字，后一个字节将和下一个字符结合。当<title>标签里的汉字数是偶数个时，勉强有3/4的概率通过解码程序(因为GBK的第二个字节要求是40-FE)，当有奇数个汉字的时候，最后一个汉字的三个字节的最后一个字节会和</title>的第一个字符<结合，而<的编码是3C，正好不在尾字节40-FE的范围中，造成错误。如果</title>标签前有多余的空格也会产生错误，因为空格的编码20也不在范围中。

再做一个测试，修改t12.html中title的部分，修改成两个汉字，再用IE打开发现不再是空白页，而是用GBK编码导致的乱码页面了。地址：s.html

所以，空白页的出现是不固定的。《UTF-8字符集网页在IE上会显示空白问题的解决方案》所说的“IE 解析网页编码时是 HTML 內的标识优先的，然后是 HTTP header ；而mozilla 系列的浏览器刚刚好相反。”是不对的。在网上搜索“meta的作用”，很容易就可以找到一堆meta标签的说明。比如《HTML中meta的作用》里提到：“meta是用来在HTML文档中模拟HTTP协议的响应头报文。”在meta标签中写和在HTTP头里写是一样的，这也是为了解决用普通HTML写网页的人无法自行定义HTTP头的问题。但是，meta是一个html标签，所以必须进入到html解析的步骤才能生效，而生效后，浏览器会退回几步，重新设置好HTTP头从头再开始解码、解析html。所以meta中写的内容会覆盖HTTP头里的内容，无论哪个浏览器都是这样的。如果象他所说的，mozilla系列浏览器是HTTP Header优先于HTML内的标识，那meta标签不就等于没有用了吗？这不符合html标准。

而《一个 utf-8 网页在 IE6 下的BUG》中所说的出现空白页必须的3项条件(1.title标签里的内容为中文其他双字节字符；2.指定网页编码的 meta 信息在 title 标签的下方；3.另存或转换utf-8编码时没有包括 unicode 签名 (BOM))基本上正确，不过不够全面，具体的原因我上面已经详细分析过了。还有BOM不能算签名吧，唉，就叫他BOM好了，Byte Order Mark，字节序标识，用于UTF-16编码的文件，在UTF-8编码的文件中不需要标识字节序，所以被用来标识这是一个UTF-8编码文件。

这个问题还是IE的兼容性问题，在解码的时候如果遇到错误的编码就中断解码。毕竟html代码是从网络上传输过来的，很可能传错几个字节，所以解码程序不必弄的这么严格吧。乱码页面起码让浏览者知道网页已经打开，有点经验的会知道切换网页编码，如果是空白页很可能被浏览者认为是网页本身就是空白的，从而放弃浏览。IE在html解析和CSS解析上容错性很好的呀，怎么解码这块会做的这么严格呢。某些天天喊叫IE兼容性好，IE能正常浏览的网页多的人，你看这个，这个，嘿嘿。

测试了一下，blogspot,sitesled,Blogger Spaces上的页面都是返回的Content-Type: text/html，所以他们都会出现空白页的问题。好像Apache默认情况下不会乱声明编码方式的，无论是国外的主机还是国内的主机。我的Blog的页面的HTTP Header都包含Content-Type: text/html; charset=UTF-8，后台的页面也都有，一般不会有问题。查了一下，WordPress自带的WordPress Default和WordPress Classic模版都把单独放在title标签的前面，可能WordPress开发组注意到了这个问题，K2模版则没有注意这个问题。blogger.com的模版也没有注意这个问题，难道老外都习惯了meta一起放在title下面？

另外，这个是IE的bug，不过也不要认为你用的是MyIE、MyIE2、遨游Maxthon、GreenBrowser、腾讯TT就不会受到影响，他们都是以IE为核心的，IE的bug他们一个个都跑不掉。尽早投降吧，投到Firefox或者Opera的怀抱里来吧。

昨天中午12点40上网，发现访问不了Blog，ping了一下，DNS解析到的IP正确，但是服务器ping不通。以为服务器又出点小故障，但是想到百优的反应速度一向很快，估计过个10分钟，等服务器重启一下就好了。开QQ，到WordPress群跟大家说了一下这事，哪知大家都能访问，最后一致认为是我的rpwt。晕倒，赶紧从头开始查：nslookup，DNS解析正常；ping，ping不通；tracert过去，发现问题了。

C:\DOCUME~1\cface>tracert -d yskin.net

Tracing route to yskin.net [218.85.132.28]
over a maximum of 30 hops:

1   <10 ms    10 ms   <10 ms  192.168.0.1
2   <10 ms    10 ms   <10 ms  219.134.63.62
3   <10 ms   <10 ms   <10 ms  219.133.30.133
4   <10 ms   <10 ms   <10 ms  59.40.49.98
5   <10 ms    10 ms   <10 ms  58.60.24.30
6   <10 ms    10 ms   <10 ms  202.97.64.34
7    10 ms    10 ms    10 ms  202.97.41.145
8  61.154.236.157  reports: Destination host unreachable.

Trace complete.

查61.154.236.157这个IP，显示是“福建省 厦门市 电信”。直接ping 61.154.236.157，发现可以ping通，而且也是10ms。说明这个路由器好着，但是包过不去，可能是因为路由表出问题之类的吧。这样子的话，起码深圳电信的用户都访问不到我的Blog，不知道其他城市怎么样。到百优网站看了下，8月3号有个通知，说是“接厦门电信局IDC通知，218.5.76.*,218.85.132.*段的某些服务器网络故障，需要变更IP”。也不知厦门电信在搞什么，群里Dre·J说是在调整服务器为了学重庆那样上网需要备案，哈哈。昨天ping -t了一天，一直到晚上12点也没好，郁闷。今天中午1点上网时还是老样子，不过2点时好了，呼，终于可以上来处理一下评论了。

C:\DOCUME~1\cface>tracert -d yskin.net

Tracing route to yskin.net [218.85.132.28]
over a maximum of 30 hops:

1   <10 ms   <10 ms   <10 ms  192.168.0.1
2    10 ms   <10 ms   <10 ms  219.134.63.62
3   <10 ms    10 ms   <10 ms  219.133.30.133
4   <10 ms    10 ms   <10 ms  59.40.49.98
5   <10 ms    10 ms   <10 ms  58.60.24.30
6   <10 ms    10 ms   <10 ms  202.97.64.34
7    10 ms    10 ms    20 ms  202.97.41.145
8    10 ms    10 ms    20 ms  61.154.236.157
9   741 ms   751 ms   761 ms  222.76.222.142
10    30 ms    30 ms    30 ms  222.76.222.182
11    20 ms    20 ms    20 ms  222.76.221.50
12    10 ms    10 ms    20 ms  218.85.132.28

Trace complete.

Update：又从5点坏到6点，这次是11号222.76.221.50那儿过不去，郁闷。

8月6号下午4点，super37告诉我，自从更新到WordPress 2.0.4以后一直没有收到定时备份的邮件了。我到邮箱里看了一下，确实是升级之后就没有再收到了。

比较了一下，WordPress 2.0.4中，WP自带的WordPress Database Backup插件修改了3处。WP-cron插件没有动，仍然是1.4版本(插件里写成1.3版了，所以在插件页面会显示成1.3版)。看了一下，第三处最可疑，wpdbBackup_init()函数里添加了一条 if ( !current_user_can('import') ) return;这个函数写着init，自然是初始化用的咯。只要检测到当前用户不能执行import操作，就立即return，不执行下面的建立wpdbBackup类的对象的操作，等于是把整个插件屏蔽了。而WP-cron的原理是每次有人访问Blog的时候检测一下有没有到了时间又还没执行的任务，有则立刻执行。wp-db-backup插件修改以后，只要每天夜里12点以后，第一个访问的不是管理员，那么自动备份就不能进行。

不知道WordPress开发组加这一句干嘛，难道是被WordPress 2.0.3的import bug吓怕了，所以到处加是否可以import的检测？数据库备份插件检查import导入权限干嘛呢，奇怪。没办法，先把这行注释掉，等着看今晚12点能否正常备份。在WordPress Trac报了个bug：Scheduled Backup in wp-db-backup plugin doesn't work，看能否有回应。

我的Blog的文章正文部分宽度只有500px，如果文章里加了一幅宽度超过500px的图片，无论是IE还是Firefox下都会出现撑破页面的情况。

2006年6月5日，我在调整Blog的CSS。因为K2模版是老外做的，很多地方显示的并不好看，于是找了个CSS中文手册，边学边调。K2默认的CSS里，文章内容内的图片的CSS中有一项"max-width: 100%;"，查了一下，说是限制对象的最大宽度。于是就在自己的CSS里把max-width这一项设置为500px，在Firefox里测试成功。

今天上网看到shura的留言，赶紧到IE里测试了一下，果然页面被撑破了。再上网一查，原来Firefox和Opera都支持max-width，但是IE不支持。google max-width IE，发现有一篇很好的介绍如何在不支持max-width的IE里实现相同效果的文章《max-width in Internet Explorer》，详细说明了用IE提供的expression命令执行Javascript代码来实现max-width效果的方法。还有2003年11月的一篇讨论组文章max-width in I.E.，里面有用expression的两段代码，都可以实现max-width效果。

看看我的代码吧：

#primary .itemtext img {
    max-width: 500px;
    width: expression(this.clientWidth > 500 ? "500px" : this.width);
}

前几天域名的NS服务器更换IP，换完后我用nslookup查看了一下，ns1可以解析到IP，ns2解析不到。

在深圳电信和四川电信的DNS服务器上不断地查我的域名，大概有1/3的时候解析不到IP。set q=ns后再查，发现每次返回的ns服务器顺序并不一样，有时ns1在前，有时ns2在前。

一般网上的说法是，ns1是主DNS服务器，ns2是副DNS服务器，刚才咨询了域名提供商的客服也是得到这个答案。但是现在我觉得，DNS服务器并非安装顺序查询的。DNS服务器在接到解析请求的时候，缓存里找不到时，就去查这个域名的ns服务器，然后在这些ns服务器里，随便挑一个出来连接过去查询。象www.google.com,www.yahoo.com这些域名，一般都有五六个ns记录，如果每次都去第一个ns记录查学，那ns1也太可怜了！

上网查了下DNS服务器的工作原理。在微软网站找到一篇 《DNS 查询的工作原理》，详细讲述了DNS查询的过程。浏览器拿URL去本机DNS缓存和hosts文件里查，查不到送第一个DNS服务器。DNS服务器先查自身区域(也就是说如果当前DNS服务器是该域名的ns服务器的话直接返回)，然后是缓存，再查不到进入递归过程。具体过程如下图所示：(盗链自微软网站)

接下来是递归查询的过程，如图所示(同样盗链自微软网站)。所谓递归查询，并不是说一级一级网上查询，比如深圳的DNS向上问广东的，广东的问全国的。图片里查询的是example.microsoft.com，DNS服务器进行递归查询，首先是先问那个点"."，就是".com"的点，点"."说我不知道，不过我知道"com"的名称服务器，给你。拿到"com"的名称服务器，连接过去问，你有没有"example.microsoft.com"的IP？"com"说我没，不过我有"microsoft.com"的名称服务器，给你。再连接"microsoft.com"的名称服务器，询问"example.microsoft.com"的IP，得到"example.microsoft.com"的名称服务器。再连接"example.microsoft.com"的名称服务器，得到"example.microsoft.com"的IP。然后该DNS服务器赶紧给这边的客户——浏览器返回"example.microsoft.com"的IP地址，顺便问一句：“你等急了吧？”这就叫递归查询。

英文wiki中的DNS条目有一幅图片，也满直观的，附在下面，如果你看不到，那么你一定不知道什么是自动配置脚本，什么是foxproxy插件吧，嘻嘻。

另外可以参考一下 《Solaris - dns名称解析过程》和 《知道如何区分DNS查询类型》

综上所述，一个域名的NS记录就是存放在上级域名中用来记录该域名的DNS服务器的。然后每个NS记录都要保证能解析到IP。现在很多公司的ns1和ns2分别连电信和网通的线，为了确保能解析到IP，我觉得这没什么用处，电信和网通的DNS服务器之间的连接还算通畅。如果一个ns服务器连接不上倒没关系，如果连接的上却解析不到IP就麻烦了，DNS服务器不会去重试另外一个ns服务器，而是直接返回没有IP。我的域名已经搞好了，管理员帮我把域名解析到新网的DNS服务器ns.xinnet.cn上，这下速度嗖嗖的。前几天在FeedBurner上修改设置，改完一项点save的时候，FB都会说“貌似你的domain不存在”，而且每天都会收到FeedBurner的报告，说找不到yskin.net。以后应该不会再有这种问题了。

刚升级了WordPress 2.0.4。

7月29日，WordPress 2.0.4就发布了，光顾着升级WordPress 中文包，再加上这两天FTP速度不行，ping上1000ms，所以拖到现在才升级。

网上流传着很多五步升级WordPress的文章，基本都是翻译自WordPress Codex:Upgrading WordPress。现在，从2.0.3升级到2.0.4的说明也已经更新了： Upgrade 2.0.3 to 2.0.4，总共9步。其实也不用那么麻烦，WordPress安装包里不包含wp-config.php,.htaccess等文件，不用担心被覆盖掉。我又没有用WordPress自带的模版，也没有修改WordPress自带的那三个插件，所以直接上传WordPress 2.0.4安装包里的所有文件，又把wp-db.php修改后上传更新。这次更新没有变更数据库的结构，所以进后台后没有弹出要求确认升级数据库的页面，自然也无需自行去wp-admin/upgrade.php页面更新。

前段时间WordPress被曝出有很严重的bug，参见我的文章：《好像Wordpress又有一个bug被发现了》。在这个时候发布2.0.4，恐怕也是想尽快修正这个bug，以避免更大范围的损失。我查看了一遍 在2.0.4中被修正的bug的列表，并没有提到这个bug。比较了一下WordPress 2.0.3和2.0.4的文件，wp-admin/admin.php中增加了一条：if ( ! current_user_can('import') ) wp_die(__('You are not allowed to import.'));wp-admin/admin-db.php中修正了默认分类不是ID为1的分类的问题，加入了 current_user_can('edit_users'))的判断，还将plugin的相关信息全都trim了一下。

Update：可怜的WordPress 2.0.3的bug，唉！

今天晚上想测试一下，就在我的服务器上新装了个WordPress 2.0.3的测试Blog。安装完后，为了避免cookies的影响，切出FF，换用IE进到测试Blog的主页。注册->到邮箱收密码->登陆。然后导入，刷新首页，成功。我汗...

拿朋友的Blog做了下测试，没有其他Blog的数据库，就想找个RSS 2.0。直接down了我在FeedBurner烧录的feed，用UE修改了下，只保留第一篇文章。点导入，于是就成了这样：

一点问题都没有，FeedBurner烧录时加上的评论数的图片也在，汗。没升到WordPress 2.0.4的赶紧升级，开着允许用户注册的赶紧关了，事态严重啊！

今天早上开始，feedburner就一直不能访问，看keso的文章《FeedBurner被封？》，说是电信用户都不能访问了。再看williamlong的文章《FeedBurner挂了》，唉！

今天这么不爽，feedburner被封，365key暂停服务24小时，空间断了20分钟，好了以后执行时间很短，但是网络速度很慢，还有域名的第二个ns服务器解析不到IP。真是郁闷的一天。

熬啊熬，晚上11点半了，准备要走了，随手刷新了一下feedburner，居然可以访问了，速度还很快哩。williamlong说希望不要象上次Technorati一样垂死挣扎一下。唉，如果最终封掉了，没办法，我就开始骂吧。