月蝎研究

Blogger FTP 迁移工具发布

2010-03-04T17:22:00.001+08:00

今天下午 2 点左右，Blogger 专门发布 FTP 功能关闭及转移相关信息的 Blog “Blogger FTP Info”发布消息说 Blogger FTP 的迁移工具上线了。Twitter 上的 Blogger 官方帐号也同步发布了这条消息。

目前这个迁移工具还在试用和观察阶段，因此仅在“Blogger in draft”有效。如果你的 Blogger 是基于 FTP 发布且开启了 Blogger in draft，那么现在登录你的 Dashboard，就会发现如下图的一块提示信息，告诉你 FTP 发布功能将会关闭，建议迁移到 BlogSpot 或者用 Custom Domain 功能代替。

消息以及以上提示框中都提到，FTP 发布功能停止的期限是 2010 年 5 月 1 日，比起先前通知的 2010 年 3 月 25 日，期限又宽限了一个多月。

这则消息还提供了一个视频，用来指导用户如何使用迁移工具对 FTP 发布的 Blog 进行迁移。主要包括以下步骤：

用户选定一个 BlogSpot 二级域名或者 Custom Domain 的域名
如果是 Custom Domain，则需要把自己选定的域名的 CNAME 记录指向 ghs.google.com
Blogger 根据用户选定的方案和域名创建新的站点
Blogger 向原 FTP 服务器重新发布所有的页面，给所有 HTML 页面添加两条标签：rel-canonicial，用来指示页面的新 URL；meta-refresh，当读者访问旧页面时自动跳转到新的 URL。如果文章数量很多的话，该操作会花费很长时间。工具提供了一个选项，可以让该操作完成时发送邮件通知你。
Blogger 向原 FTP 服务器发送一篇新文章，告知所有的读者该 Blog 发生了迁移，同时也通知所有的订阅读者更新订阅地址
Blogger 随机请求一些原 FTP 服务器上的页面，确保迁移跳转的内容添加成功
迁移完成，读者用新的地址访问 Blog

总的来讲迁移过程还算简便，对原 Blog 的影响应该说也降到了最低。但其中涉及到重新发布所有页面的环节，对于文章数量很多的博主来说，这个过程及有可能会中断或者失败。至少最近几个月以来，我发布文章时，FTP 上传操作几乎没办法一次成功，更何况是重新发布整个 Blog。

我之前有篇文章提到 Blogger FTP 发布功能关闭的应对措施，因为 BlogSpot 和 Custom Domain 功能在国内都因被墙而无法使用，另外 Blogger 提供的 Layout 模版管理对于我来讲仍然不够灵活，没有对整个网站所有文件的完全控制权，因此我无法，也不会将目前 FTP 发布的 Blog 迁移到 BlogSpot 或者 Custom Domain。解决方案是利用 Blogger 提供的 Feed 接口将所有文章数据同步到本地数据库，然后自己写一些 PHP 脚本利用这些数据直接在服务器上生成静态 HTML 文件。这样，既可以继续使用 Blogger 网站来编辑文章，保存文章；读者访问时直接访问静态页面或使用本地数据库，页面打开速度仍然有保证；我也可以按照自己的方式随心所欲编辑模版，开发各种功能，可谓一举数得。目前这个工作已经开始了，加上 Blogger 又宽限些时间，因此一定可以赶在 FTP 发布功能失效前完成。

NOKIA 手机安装 MIDlet 时出现“Conflicting application”错误及解决

2010-03-02T16:36:00.006+08:00

最近发现在某些诺基亚（NOKIA）手机上安装带有 Push Registry 功能的 MIDlet 时，会发生安装失败的情况。错误信息有可能是“Push registry failure”(S60v3)，或者“Conflicting application”(S40v6)，出现这个错误的直接原因，应该是安装程序在执行 Push Registry 注册时失败，认为要注册的目标端口已经被其它应用程序占用。

实际的情况是之前安装过同样的 MIDlet 的旧版本并已经删除。然而，无论是软格机、硬格机，用 Nokia Software Updater 重装/升级 Firmware，都无法解决。

最后发现一个简单但有效的解决办法：

将 JAD Property 的 MIDlet-Push-1 中 Push Registry 的端口改成别的端口
这时 MIDlet 应该能够正常安装。如果你的应用并不在乎使用哪个具体的端口，那么到这里问题就已经解决了
如果应用必须使用之前的那个固定端口，那么将安装好的 MIDlet 删除（卸载）掉，将 JAD 中的端口再改回去，然后就可以正常安装了

Windows x64 下 Cisco VPN Client 的替换方案

2010-02-10T13:15:00.001+08:00

买了新机器，为了解决硬盘问题重装了系统，顺便装了 Windows 7 x64，绝大多数情况下都没有软件兼容的问题，唯独碰到 Cisco VPN Client 不兼容 Windows x64 且没有提供 64 位的版本。

Google 了一番，发现 Cisco 为 Windows x64 的操作系统提供了一个名为 Cisco AnyConnect VPN Client，但官网上需要特殊的认证用户才能下载，而几经搜索也没找到其它的下载网站。

最后，发现有个国外的论坛有人回复说用 Shrew VPN Client 可以正常的在 Windows x64 下运行。下载下来试用，发现真的不错。安装运行都很简单，关键是还能够直接导入 Cisco VPN Client 的 pcf 配置文件，不用花精力去研究参数配置。所以如果你也需要在 x64 的 Windows 下运行 VPN 客户端又无法安装 Cisco VPN Client，不妨试试这个 Shrew VPN Client。

西数 EARS 绿盘使用心得

2010-02-05T14:34:00.002+08:00

这周新配了台电脑，主板：微星 P55-CD53 / CPU：Intel i5 750 / 内存：金士顿 DDR3-1333 2G / 显卡：影驰 GTS250 黑将版 / 硬盘：西数 1TB/64M 绿盘（WD10EARS）。

买回来整体感觉非常好，除了这块西数的新技术 EARS 绿盘。从装 Windows 7 系统开始，到更新系统、安装驱动，系统反应都让人难以忍受。在我 06 年买的笔记本上装 Win7，仅花了不到半个小时，而在这台机器上花了一个多小时。另外用迅雷下载一个几十兆的驱动压缩包，点“开始下载”后，要过 2-3s 界面才会有反应。在使用过程中，硬盘灯大部分时候都长亮，开关机时间也很长，远比我的笔记本开关机慢，系统整体毫无性能可言。这完全不像一台 i 平台的电脑该有的情况。

经过多番搜索查找，到论坛上询问与讨论，做了如下改进和设置，现在虽然硬盘性能仍不尽如人意，但也算可以忍受。打电话到卖电脑的商家，说硬盘本身没问题不给换，要换也是同样型号的硬盘，因此也只能忍了。

这里分享一下我做的改进和设置，希望对同样使用西数 EARS 硬盘忍受暴差性能的朋友能有所帮助。

“高级格式化”技术和 WD Align 软件
从最近推出的 EARS 系列（有 1.0T/1.5T/2.0T 三个型号）硬盘开始，西数推出了一项称为“高级格式化”的技术，简单的理解，就是将传统硬盘每扇区 512 字节改为每扇区 4K 字节。由于 Vista / Win7 系统都能很好的管理 4K 的扇区，因此如果是在 Vista / Win7 下安装格式化，则不需要做任何特别的设置和操作即可发挥硬盘性能，而在 Windows XP 系统下，则需要用西数提供的专门的软件 WD Align。

西数官方网站 WD Align 下载页面详细给出了哪些情况需要使用 WD Align 软件的情况。我的这块硬盘当时装机时是装机师傅用 Ghost 分区然后克隆的操作系统，因此理论上并未发挥硬盘性能。所以特地在 Win7 下安装并执行 WD Align 软件。

安装和执行过程比较简单，根据提示操作即可。安装完开始执行，程序会自动检测系统中的 EARS 硬盘，确认执行 Alignment 操作后系统重启并进入 WD Align 软件界面。执行转换的过程不需要人工干预。我 1TB 的硬盘，只有 C 盘有大约 5GB 的数据，转换过程耗时约 30 分钟。转换完成后会自动重启，进入 Win7 系统，WD Align 软件自动启动，检查转换是否顺利完成，然后退出。

执行完 WD Align 的转换操作后，感觉系统性能有明显的提升。桌面窗口、菜单操作明显不像之前有那么多卡顿的感觉。

开启主板 AHCI 模式及 NCQ 功能
AHCI（Serial ATA Advanced Host Controller Interface / 串行ATA高级主控接口），是在Intel的指导下，由多家公司联合研发的接口标准。使用该技术可让 SATA 储存设备启用高级 SATA 功能，例如原生指令队列（NCQ, Native Command Queuing）及热插拔。

据 Wikipedia 资料：使用 NCQ 功能，通过硬盘固件、硬盘控制器以及操作系统三者的互相配合，改善硬盘内部磁区的读取顺序，可以提高硬盘效能约30%，亦能够轻微减轻硬盘损耗的速率。

从主板 P55-CD53 的说明书上可以看到该主板已经支持 AHCI 模式，而这块新出的硬盘以及 Windows 7 操作系统也理所当然的支持。于是我重启系统到 BIOS 中将 ATA 控制器模式由 IDE 改为 AHCI，重新引导系统，结果 Windows 7 蓝屏，并立即重启了。

纳闷之余搜索了一番，了解到 AHCI 必须在安装操作系统之前就开启，否则安装后 Windows 7 会认为没有使用 AHCI 模式而屏蔽相关的驱动。不过也搜到一篇文章，讲解通过修改注册表，再开启 BIOS 的 AHCI 模式，然后进入 Windows 7 后，系统就会自动开始安装驱动，从而开启 AHCI 模式。具体的注册表路径为：

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci

将值由原来的 3 改为 0 即可。

照此修改后确实可行，但 AHCI 开启后，HD-Tune、Everest 等软件均无法获取硬盘信息。想起在一篇论坛的帖子中有人提到，安装系统后再开启 AHCI，看起来好像是启用了，但实际对性能并无实际提升。想到目前反正系统也是刚装的，因此索性就在 BIOS 开启 AHCI 的状态下把 Windows 7 重装了一遍，顺便换上了 x64 的版本。

重装后 HD-Tune 和 Everest 都能顺利查出硬盘信息了，另外安装主板驱动提供的 Intel Matrix Storage Manager 软件后，可以查询到硬盘的 NCQ 功能已经开启。

至此，整个系统使用起来感觉比刚开始性能有不小的提升。窗口、菜单操作没有明显的卡顿，开关机速度也有非常明显的改观，至少比我笔记本上同样的 Win7 旗舰版要快。尽管从 HD-Tune 的读取测试，FastCopy 软件的文件拷贝测试来看，性能和速度比起网上给出的西数黑盘有较大差距，但这“较差的性能”已经到了一个可以忍受的范围内，毕竟绿盘的卖点是节能、低噪而不是性能和速度。

最后对于这块西数的新技术 EARS 绿盘，感觉买的比较后悔。或许作为仓库盘来用是不错的选择，但如果是系统盘，完全不值得推荐，价格相差仅几十元的 WD1001FALS 黑盘应该是更好的选择。

Blogger 将关闭 FTP 发布功能及应对措施

2010-01-25T13:04:00.001+08:00

Blogger Buzz 上周末发布消息称 Blogger 将于 2010 年 3 月 26 日停止 FTP 发布功能，原因是目前所有的活跃 Blogger 用户中，仅有 0.5% 的用户使用 FTP 发布，而 Blogger 用于支持这一功能的资源则远超过这个比率。

我的 Blog 从 2005 年开始就一直使用 Blogger 的 FTP 功能发布，已经有四年多的时间，也因为这样所以一直可以相对正常的访问。说“相对”是因为 blogger.com 域名被封，时不时的也会引起页面的外部 CSS / JavaScript 资源无法访问，Feed 内容无法访问引起评论失败等问题。现在 Blogger 官方宣布将彻底停止 FTP 功能的支持，将会对我这两个 Blog 带来四年来最大的一次冲击。

不过可以肯定的是，我不会关闭这两个 Blog，也不回搬家到别家 BSP。其实最近一两年，随着文章数量的增加，利用 FTP 发布已经变得越来越困难，平均十次发布，至少要失败五次。而按现在 Blogger 的机制，无论是发布文章还是有网友发表评论，首页、文章页面以及相关的标签页面都会重建，如果修改模版，则所有的页面都需要重建，这样高的失败率，让人很难觉得这是一个好用的产品。

由于页面代码优化的需要以及应对 blogger.com 域名从国内无法访问的问题，我已经建立起一套机制实现从 Blogger Feed 下载文章的数据保存到本地数据库，用 PHP 扫描页面进行 XHTML 修改以及用 AJAX 获取相关文章 / 热门文章的功能，现在其实要保持 Blog 继续正常运行，只需要：

在数据同步时将正文部分也下载
利用下载的数据在本地用 PHP 重写 Blog 内容，或生成静态页面

这样不但免去了等待漫长的 FTP 发布以及高失败率的问题，也让我维护 Blog 变得更加灵活。

离 Blogger 停止 FTP 功能还有大约两个月的时间，我想已经足够我做这些改进了。

用 Feed 实现 Blogger 分页

2009-09-21T15:18:00.003+08:00

使用 Blogger 建博客，一个很不爽的问题是在首页下方没有分页功能，这会直接导致有兴趣的读者没有办法方便的翻阅以前的旧帖子；而 Blogger 提供的模板，无论是老的 Template，还是新的 Layout，都没有相关的标签来实现这个功能，因此要加上这个功能，就只能继续 hack 了。

这两天利用 Blogger 的完整帖子的 Feed，配合 PHP 实现了这个功能。思路为：

读取原始的 index.html，把帖子的部分去掉，也就是 <Blogger>...</Blogger> 这段内容
读取以下 Feed 地址，解析出文章的日期、时间、标题、正文、标签等，按照原来模板的格式，用 PHP 输出到原来 index.html 放文章的地方
http://www.blogger.com/feeds/[blogId]/posts/full?max-results=[step]&start-index=[startIndex]&orderby=published
根据当前页码以及总帖数计算分页，在页面底部添加分页链接
如果有条件，可以利用 .htaccess 文件，将分页的 URL 由原来的
xxx.php?page=x
形式替换成对搜索引擎更友好的
/index/x
形式

如此一来，就可以在自己不存储任何文章数据的情况下，实现分页功能。当然，直到目前，以上的 Feed 地址仍然是被墙的，需要翻墙或者使用 HTTP 代理才能成功地获取内容。

phpMyAdmin 使用时 Apache 崩溃问题

2009-08-16T23:26:00.002+08:00

最近笔记本的硬盘时常怪响，因此换了一块硬盘以防万一，系统重装了，因此开发环境 PHP + MySQL + Apache 也需要重搭。因为已经做过很多次，做起来轻车熟路，然而装好 phpMyAdmin 以后，在登入界面输入用户名密码点登入，居然弹出一个 Windows 应用程序进程崩溃的 report 对话框：Apache 崩溃了……

重新试了几次，仍然如此，换以前硬盘上的 PHP 目录（保证 PHP 的配置和以前一致），无效；换 Apache 版本，无效；换 phpMyAdmin 较早的可以正常使用的版本，无效；用 MySQL 官方的 GUI 客户端登录，可以读写数据，因此不是 MySQL 的问题，于是我就没辙了……

上 Google，发现很多人都有类似的问题，最早的帖子甚至可以追溯到 2003 年，然而没有看到一个有用的解释或者回答，但终究找到一个网页提到架设 PHP + MySQL + Apache 的时候，要保持 MySQL 的客户端连接库 libmysql.dll 版本一致，最好使用 PHP 自带的 dll。

想到这次设置 PHP 时，没有像以前把所有的 dll 都拷贝到 %windows_root%\system32 下，而只是直接的把 D:\PHP 加入到了 PATH 环境变量中。于是马上照以前的办法，把 PHP 包中的相关 dll 都拷贝到了 system32 下，再启动 Apache，进 phpMyAdmin，问题解决了。

用了一会儿，问题有时候仍然存在，于是又把 %Apache%\bin\libmysql.dll 删除（或改名），则问题解决了。但是在 phpMyAdmin 登入后，首页下方会提示说当前使用的 MySQL 客户端版本和服务器版本不相符，可能导致不可预料的结果。

如果各位对此问题有没有更透彻的解释以及彻底的解决办法，望不吝赐教。

Update 2010-02-10:

这个问题似乎和 MySQL 的版本有关。之前出现此问题的 MySQL 版本是 5.4 beta。最近在新机器上同样的架构和设置，只是 MySQL 版本为 5.1，没有出现该问题。

Google 宣布涉足操作系统：Chrome

2009-07-08T18:53:00.001+08:00

Google 官方博客今天早些时候发布文章，Introducing Google Chrome OS，Google 黑板报随后在下午也发布了此文的中文翻译：谷歌 Chrome 操作系统。

Google 自九十年进入人们的视线，到现在将近二十年时间，从名不见经传的小公司，已经成为世人瞩目的具有极大影响力的互联网巨舰。坊间曾一度传闻 Google 终将涉足操作系统领域，而前两年推出 Android 手机系统也被认为是对涉足操作系统的投石问路。而现在，终于为我们揭开了这层面纱，比想象中要来的早的多，快的多。

如果说 Chrome 浏览器足以让微软不安的话，那么 Chrome 操作系统对于微软可以说是一枚重磅炸弹。Google 在行业一项有着较好的声誉，其产品也从来不缺乏用户、支持者乃至狂热者。有人说 Google 越来越巨大，并不容乐观，因为极有可能发展成为第二个微软，最终变成另一个邪恶的垄断帝国。但就目前的形式来看，在微软的 Vista 叫好不叫座，强行推行仍无人问津，仓促推出 Windows 7；IE 系列一代不如一代，市场占有率持续下滑的今天，如果有另外一家公司为我们提供更有竞争力的产品、更新的理念、甚至一场革命，未尝不是一件好事。

当然，以上的担忧也未必就是杞人忧天。这就像一位骁勇善战的将军，为广大民众打败入侵的外敌，带来和平与繁荣，集权利、荣誉与威望于一身，最后到底是成为独裁的暴君，还是继续服务于人民的福祉？期待 Google 能够给我们一个正面的范例。

Gmail 结束 Beta

2009-07-08T10:19:00.002+08:00

Google 官方博客及 Twitter 上的 @google 昨晚都发布消息，称 Gmail、Google Docs、Google Calendar 以及 Google Talk 结束 Beta。“Beta” 标记将从这些产品的 LOGO 中去除，但无论是否 “Beta”，Google 都将继续对这些 WEB 应用程序进行创新和改进。

记得自己在 Gmail 刚推出的时候，就收到邀请注册了，并一度做为自己的主要私人邮箱使用，已经有很多年了。（据 Solidot 文章，Gmail 于 2004 年 3 月 31 日推出，所以到现在已经有 5 年多了。）

一项以及多项相关产品有如此长的 BETA 期，这是很少见的。加上我所在公司的其它部门曾经做过 Android 平台 API 的单元测试工作，据说该平台自推出后的很长一段时间，该 API 中 bug 非常多且 API 文档混乱。另外据我多年使用 Blogger 作为博客平台的经验，其 bug 之多也是在公众运营的产品中遥遥领先的。

尽管 Google 的创新能力和“不作恶”是另世人和广大互联网用户称道的，但以上事实也让我非常怀疑 Google 内部的代码质量控制。现在此四项产品的最终结束 Beta，应该可以说对 Google 的形象起到了长远的积极作用，也希望 Google 能为我们提供更多更稳定更惊艳的互联网产品。

让 Google 为你导游

2009-07-07T15:47:00.001+08:00

瘾科技消息：Google 实验室最近推出新服务 - Google City Tours。

这个服务利用 Google Map 作蓝本，在 Google Map 上加入了旅行导航。你可以在一个城市中加入不同的景点，然后让 Google 作导游，为你度身订造旅行路线。

Google City Tour 已经预先准备一些数据，像博物馆的开放时间、脚程时间等等。基本上可以帮你规划一条不错的路线，对背包客来说是一个不错的选择。因为利用 Google City Tours 来作一个蓝图，再更改自家行程，较从零开始更方便。

现在 Google City Tour 只有一些欧美主要城市的数据，未有加入亚洲城市。而且预设的建议景点也是博物馆，要加入其它的地点要手动加入。

看到这则消息，首先想到的就是今年 3 月在欧洲出差时，去巴塞罗那和罗马旅行的事情。由于人生地不熟，加上语言也不怎么通，所以在订好机票和旅店后，自己也花了大量的时间做功课，为紧凑的周末做好安排。当时如果有这项服务就好了，可以省去很多人工的查找和计算工作。

不过，从经验上来看，这项服务要能在手机上使用才方便。在欧洲城市旅游，如果不是跟团的话，通常都是徒步加市内公共交通的方式，很难想象时不时的掏出笔记本查看下一个景点的地点和方向。目前也还不太清楚这项服务是否能够用在手机上，不过倒不妨说说自己当时的解决方案。

先在 Google Maps 和 Google Earth 上实现查找了所有著名景点的位置并安排了路线，然后存成 KML 文件，并把文件放到可以公共访问的网站上。通过 KML 文件的 URL，可以把景点的位置和路线导入到 Google Maps，并以此共享给同行的其他旅伴。最关键的，是要有一部支持 GPS 的手机，安装好移动版的 Google Maps 后，可以通过 URL 打开之前准备好的 KML 文件，从而把路线安排导入到手机，这样，在旅行的时候，便可以随时拿出手机查询当前的位置，行进方向，以及要去的景点所在的位置。

当然，纸质的地图也是非常必要的，原因在于其一手机屏幕一般不够大，很难有个总体的概览，第二，最重要的，手机地图上的地铁和公交站信息可能不太完整，而通常当地提供的旅游用地图就有比较详细的公交地铁站的位置以及另外的线路信息，这对于徒步自由旅行来说，是非常方便的。刚出地铁站，可能一时很难搞清楚位置和方向，这个时候再掏出手机上的 Google Maps，通过 GPS 定位后，就知道自己的位置以及该行进的方向了。

所以强烈推荐纸质传统地图加手机 Google Maps 来配合使用，不过记得要给手机充足电，有必要的话另备一块电池。GPS 和 GPRS 同时开启，可是很耗电的。

模板标签生成奇怪 Javascript

2009-07-01T13:07:00.010+08:00

昨天由于有新的评论，有一篇帖子的页面被重新生成，然后页面就出现了一些奇怪的问题。仔细查看源代码后，发现在生成页面的时候，模板里面所有的 </Blogger> 标签的画面，都被加上了一段奇怪的 JavaScript 代码：

<script type="text/javascript" src="http://www.blogger.com/static/v1/common/js/327583163-csitaillib.js"></script> <script>if (typeof(window.attachCsiOnload) != 'undefined' && window.attachCsiOnload != null) { window.attachCsiOnload('ext_blogspot'); }</script>

重新发布了几次仍然是这样，因此推测可能是 Blogger 做了更新。在 Google 上搜索了一下，发现很多 Classic Template 的使用者都发现了相同的问题，并且报告在 Blogger 的 Google Groups 帮助讨论组，如这篇帖子，还有这里，以及这里。虽然有很多网友提出了各种临时的解决办法，但看起来都不尽如人意。

个人认为 Blogger 这个新的功能添加得不够专业。先且不论是什么功能，光是直接在</Blogger> 标签后加入 <Script> 就不可取，因为 Blogger 这一对标签里面包括和帖子相关的数据，页面上凡是需要帖子标题、ID、时间等相关信息的地方都会用到这一对标签，它可能出现在标题、正文甚至其它的 JavaScript 中（例如我就需要通过这对标签取得帖子的 ID 并作为参数传给 JavaScript 函数）。

目前暂时通过人工编辑 HTML 去掉了相关的 Script，如果近期 Blogger 不能解决这个问题的话，就只有另外写 PHP 程序来自动处理了。

Update July. 2, 2009:

在这篇帖子中一位来自 The Blogger Team 的用户提到，这的确是他们发现的一个 bug，将很快被修复。让我们拭目以待吧……

Update July. 8, 2009:
这位来自 The Blogger Team 的用户提到，他们已经在 Blogger 的 Known Issues 网站上记录了这一问题以便跟踪。从该帖内容来看，他们只认为问题只出在不该在 <title></title> 之间输出 script 内容。难道他们不知道这一对 <Blogger></Blogger> 还可能用在用户自己定义的 JavaScript 中吗？

GFW 开始识别 WEB 代理

2009-06-19T19:02:00.001+08:00

之前提到用 HTTP 中转的办法解决了评论的问题，今天发现 Blog 上所有的评论又失效了…… 开始以为是因为页面直接引用了 www.blogger.com 域名的某些内容而导致撞墙，但仔细分析后发现，我的 HTTP 中转直接不能访问了，而且之后我的 HTTP 中转程序所在的域名也会在一小段时间内无法访问…… 但同时，用该中转能够访问原本没有被封的内容，比如 Flickr……

考虑到传入的目标 URL 参数是用 Base64 和 URL Encode 方式处理的，不存在任何加密，而且这和大多数的　WEB 代理相同，所以推测是现在 GFW 能够识别用 Base64 编码的内容，如果该内容刚好是被屏蔽的网址，则阻拦该 HTTP 请求，并且屏蔽该请求所在的域…… 从而让公众无法通过 WEB 代理访问屏蔽内容。

当然，解决的办法也简单，如果不能简单通过 Base64 decode 得到一个 URL，那么它也就无从判断是不是被屏蔽的网址了……

我起先想直接把原网址按位取反再 Base64 就行了，结果同事说我作为一个 IT 人士这么干太低级了…… 他们说用 RSA 吧，但是也犯不着这么兴师动众吧……

还是 Liuming 小弟比较聪明，提供了一个比按位取反高级，又比 RSA 简单的办法，那就是……

两次 Base64…… >.<"e;

Google 邮箱收到 Bing 发来的邮件

2009-06-04T11:01:00.003+08:00

今天早上 Google 邮箱收到 Bing 发来的题为“Discover Microsoft's new Search services”的邮件，声称微软发布了新的搜索引擎服务，并提供了新的 webmaster 工具 www.bing.com/webmaster。

然而，由于众所周知的原因，Bing 在当下无法访问，微软在这个时候让 Bing 上线原本已经不合时宜，现在又在这个把邀请邮件发到 Google 邮箱，提供一个无法访问的链接，实在是为微软感到可惜。

既然如此有诚意，还是用代理打开来看看吧。从界面和内容上看，与微软先前的 Live Search Webmaster Center 如出一辙，加上里头已经有了我两个 Blog 的 Sitemap 信息，可以看出这个 Bing 就是从先前的 Live Search 改头换面升级而来。这大概也是为什么 Bing 上线第一天就能够搜到“月蝎研究”和我的另一个 Blog “今日无大事”。

微软新推出的 Bing Webmaster 工具

开始以为微软的邮件发到 Google 邮箱是为了故意挖取 Google Webmaster Tools 的用户，但后来发现由于 Bing 就是原来的 Live Search，而早先我已将自己的 Google 邮箱登记为 Live Search Webmaster Center 的联系邮箱，所以这次是我自己以小人之心度君子之腹了。

另外，微软的邮件中，还提到了 Bing 搜索引擎相关的 API www.bing.com/developers 以及提供支持的讨论社区 www.bing.com/community，有兴趣可以看一下。

某墙疯了

2009-06-03T10:28:00.002+08:00

那墙一定是疯了…… Blogger 被封这个倒也在预料之中，毕竟这是常有的事，封着封着咱就麻木了。可是昨天开始 twitter.com、live.com、bing.com 都不能访问了，就连好不容易解封的 flickr.com 也在其列，直接导致我的 Blog 上的照片全是红叉叉……

可怜那 bing.com，前天中央电视台新闻还在大张旗鼓的给它做宣传，昨天刚上线一天，我想这两天人们应该是蜂拥而至来看一下微软这新一代和 Google 叫板的搜索引擎，正是保证稳定性争取良好公众印象的时候，结果就被封了。等过几个月解封的时候，不知道还有多少人记得 bing.com，也不知道中央电视台会不会配合微软再做一次新闻？

还有 flickr，害我不得不写程序把所有页面里的照片网址找出来，用 HTTP 代理的地址替换掉，才能保证网页上不是满目疮痍。不过也认了，反正不封从电信访问也爆满，早该改成这样了……

另外，昨天 home.live.com 也不能访问，但今天又恢复了，不知道是微软公关的效果还是刚好这个部分临时故障。home.live.com 这个微软基于 Live 的社交网络社区可以通过 Feed 和插件把 FaceBook、WordPress、Twitter、Flickr 等知名服务以及自己 Blog 的发布消息全部整合到一起，还是有点意思的……

墙疯了，网封了……

Update 2009/06/08 15:30:

从成都网通访问来看，Flickr 和 Bing 都已经解封了。据 Twitter 上有人说 Twitter 也解封了，但是我自己试了一下还是不行。

另 Blogger 和 Blogspot 仍然无法访问。

评论功能修复

2009-05-26T18:47:00.003+08:00

刚刚发现 Blog 的评论功能不能用了，提交后一直显示等待。查了一下，发现是 GFW 的问题。

自 5 月 16 日，Blogger 及托管站 BlogSpot 再次被封，导致域名 blogger.com 以及 blogspot.com 全部无法访问。而我的评论系统，是靠通过 Blogger 的 Feed 地址，由 AJAX 和 Blogger 之间通讯实现读取；由 AJAX 直接向 Blogger 的评论表单处理 URL 发送 POST 请求实现提交。这两项功能都是基于 www.blogger.com 域名的。前者所用的 Feed 地址由于先前早已被封，并通过朋友在 DreamHost 的主机上放了一个 PHP 的中转程序，所以评论列表功能一直可以用，但是评论提交是直接 POST 的，www.blogger.com 被封，所以评论自然就失败了。

没办法，刚刚改进了一下我的 HTTP 中转程序，实现了 POST 的功能，现在评论功能已经修复了。只是整个数据流程要经历“本地网页 » blog.windia.net » DreamHost » www.blogger.com » DreamHost » blog.windia.net » 本地”这样漫长的路径，因此提交评论可能需要数十秒的时间，但聊胜于无吧。希望 GFW 早日放过 Blogger，这样功能就能完全恢复正常了。

另外，修改了一下模板，把 blogger.com 上引用的 CSS 以及 JS 文件的地址都改由 DreamHost 上的 HTTP 中转读取，这样在打开 Blog 页面时，浏览器不用再等待这些文件的 HTTP 请求超时，速度应该能快不少。

收缩 Outlook 的 OST / PST 数据文件

2009-04-27T22:32:00.001+08:00

今天发现 Outlook 里一年多的邮件都没有存档了，数据文件 outlook.ost 已经涨到了 500 多兆，于是执行了一下存档操作。存档的 .pst 数据文件一下子多出了 300 多兆，但奇怪的是原来的 outlook.ost 文件却没有减少。

搜索了一下，找到了有关的信息。OST / PST 文件是 Outlook 的数据文件，随着收到新的邮件和保存旧的邮件，这些文件会越来越大，当永久删除邮件和其它内容时，空间就会被空出来，直到收到新的邮件，这些空间就又被分配使用。处于安全的考虑，这些空余的空间不会立即被释放。当空余的空间占到文件总量 20% 以上以后，Outlook 会自动在系统空闲的时候执行收缩操作。所以在我执行存档操作以后，原来的 outlook.ost 文件没有立即缩小。

如果要手动执行收缩操作，可以如下图提示操作：右键单击要收缩的数据文件对应文件夹的根目录，选择“Properties” » 点击“Advanced...”按钮 » 选择“Advanced”标签 » 点击“Offline Folder File Settings...”按钮 » 点击“Compact Now”

[转]小姜杂谈：浅论英文字体

2009-04-22T13:59:00.001+08:00

在瘾科技上看到这篇文章，虽然寥寥几句，但是把字体的基本结构讲得非常清楚，因此特地摘录下来。另外由于原文可能是港台繁体中文的，用词和大陆简体中文不太一样，因此做了一些转换。

英文字体？反正就是在 Arial 和 Times New Roman 之间选一个嘛，偶尔想俏皮一点的话，就拿 Comic Sans MS 出来就好了，哪有什么值得写一篇文章的？小姜完全不是这方面的专家，但收集各种字体也算是小姜一个小小的爱好，所以多年来也学到了不少东西。虽然大家用到英文的机会不大，但其实英文字体里好玩的东西还不少呢！让小姜带大家一起来看看吧……每个字体都有五条线……

这五条线，决定个一个字体的性格。Mean line 和 Base line 之间的距离叫做“x-height”，这个高度是一个字体中的英文字母 x 的高度，也是没有向上、向下伸展的部份的小写字的主体高度。Base line 向下有一条 Decender line，是 g, j 之类有向下伸展的笔画的字母延伸的极限。反之，向上延伸的部份，包括 f, b 的字母向上延伸的笔画和 i, j 的点的极限，则称为 Ascender line。最后还有一条 Cap line 是大写字母向上延伸的极限，在许多字体中（像上面的 Times New Roman 就是）Cap line 的高度会略低于 ascender line，但也有一样高的。Mean line 和 Ascender line 之间的距离叫“Ascender”，Base line 和 Decender line 之间的距离叫“Decender”，Base line 和 Cap line 之间的距离叫“Cap height”，而 Ascender line 和 Decender line 之间的距离则叫做这个字体的“Point size”，也就是我们在选字号的时候说的几 pt。

为什么说这五条线决定字体的性格呢？通常 x-height 占 point size 比例愈高的字体，放在内文里的时候看得比较清楚，但放在标题就很难看。反之，x-height 占 point size 比例小的字，就比较适合当标题。以下面这个例子，小姜找了两种类似的字体，但左边是设计来当标题用的（Garamond），而右边则是做内文用的（Times New Roman）。注意到 x-height 的分别了吗？

应用在真实世界，会变成这样：

有注意到下面的一组字看起来比较大吗？实际上小姜是用一样的 pt 数下去设的（大字是 96pt，小字是 12pt），为什么会这种差别？因为先前说过了，pt 数管的是字体从 Ascender line 到 Decender line 之间的距离，所以当 x-height 比较短（即 ascender 和 descender 比较长）的时候，通常字体设计师会减少每个字母的宽度，以避免字母变形。直接的结果就是虽然 pt 数一样，但 x-height 短的字会看起来比较小。下面是个比较极端的例子：

左边的字体是 Park Avenue，右边则是常见的 Tahoma。在设定上两者的 pt 数是一样的，但右边的 Engadget 看起来显然大多了！

其实字体和排版当中能讲的题材还有不少，如果有机会的话，再来和大家分享啰！

另外，在文章后面的评论中，有网友推荐了一个用中文写的关于字体排版印刷的 Blog：Type is Beautiful / 字体排印，内容专业、丰富而又深入浅出，不管是编辑、平面设计师等专业人士用来参考或者非专业人士用来拓宽知识面，都非常值得推荐。

Blogger 的评论 Feed 中去掉了 URI

2009-04-20T11:15:00.001+08:00

最近发现每篇文章下方评论的作者都没有了 URL 链接，即使是我自己确认添加了链接的回复评论也是如此。

因为评论的现实是利用 Blogger 基于 JSON 格式的 Feed，于是仔细研究了一下 Blogger 给的 Feed 的内容，发现 author 字段里面的 uri 属性被去掉了。

评论链接有效的时候，Feed 中关于作者的 JSON 代码是这样的：

"author":[{"name":{"$t":"Gregory"},"uri":{"$t":"http://blog.windia.net"}}]

而现在改成了：

"author":[{"name":{"$t":"Gregory"},"email":{"$t":"noreply@blogger.com"}}]

其中无论是谁评论，email 字段的地址一律都是 noreply@blogger.com。另外也看了 XML 格式的 Atom 输出，uri 属性也同样被替换成了 email。

Google 会做如此变更，目的还不得而知。如果是和反垃圾评论信息有关的话，链接的内容仍然可以放在评论正文中。

另外，blogger.com 网站上的评论页面仍然可以正常显示作者的链接，因此这个信息应该还是存在于 Blogger 的数据库中的，只是没有在 Feed 中输出。

Update at 18:41 on 2009/04/20:

下午发现这个 Blog 的评论作者链接显示正常了，而我的另一个 Blog 今日无大事还是没有链接，打开 Feed 的内容下来分析，发现 author 字段的内容已经又更新了，新的内容为：

"author":[{"name":{"$t":"Gregory"},"uri":{"$t":"http://blog.windia.net"},"email":{"$t":"noreply@blogger.com"}}]

目前是 uri 和 email 都有了。接下来怀疑另外一个 Blog 显示不正确是缓存问题，没道理用同样的 Feed 接口，不同的 Blog 站点内容格式不同。通过添加一个无意义的附加参数改变 Feed 的 URL，则两个 Blog 都能正确显示评论作者的链接了。之前缓存问题，是由于国内目前 Feed 的地址被墙，我通过另外一台在国外的服务器帮助取得内容再 forward 过来，缓存在那边，所以刷新无效。

看来这应该是一个 bug，只是被 Blogger 很快的修复了…… 在 Known Issue 网站上并没见到相关的说明。

SAMSUNG 手机安装 MIDlet 出现“内容不匹配”

2009-04-17T22:04:00.001+08:00

昨天通过 OTA 方式从 Apache 服务器上在一部 SAMSUNG SGH-L760 上安装 MIDlet，下载完 JAD 确认安装，开始下载 JAR 之前，手机报错说“内容不匹配 (Content mismatch)”。同样的 JAD 和 JAR 在另外一个主机上就能成功下载安装，而且这一组 JAD 和 JAR 在同服务器上另外一个 HTTP 服务应用上也能成功安装，一时觉得纳闷。

开始怀疑是端口问题，因为出现安装错误的 Apache 服务器是运行在 82 端口上的。但是同样是从这个 Apache 服务，另外一部 SonyEricsson K610i 就能正常下载安装，而且如果是端口问题，没道理 JAD 能下载而 JAR 不能。

然后开始怀疑是 JAR 文件的 Content-Type 问题，因为在确认安装的界面上，有显示应用类型是 application/vnd.sun.j2me.java-archive。打开 Apache 的配置文件 /etc/httpd/conf/httpd.conf，发现没有定义 .jad 和 .jar 文件的语句，于是添加如下两行：

AddType text/vnd.sun.j2me.app-descriptor .jad AddType application/vnd.sun.j2me.java-archive .jar

然后重启 Apache 服务，问题解决。MIDlet 成功在 SAMSUNG SGH-L760 上安装了。

Erlang 程序设计

2009-02-06T15:16:00.013+08:00

过完年后接了新的工作范畴，要接触到 Erlang 语言。虽然我可能不会直接参与 Erlang 的开发，但是作为我负责的内容，必然是要了解的。

想到前段时间在大笨熊的 Blog 上看到过一篇关于 Erlang 书籍的文章，去找了出来，可巧是他认识的人翻译的。到卓越上搜了一下，竟然只有这么一本书，既然没得选，那就它吧……

等我买回来看了再分享跟多的心得……

Google Friend Connect 开放注册

2008-12-05T14:44:00.002+08:00

前天 Google 官方 Blog 报道，发布了其 SNS 项目 Google Friend Connect，大笨熊的 blog 也提到这条消息。今天收到了 woainiuniu 的邀请，在这里谢过了。现在似乎已经开发注册了。

Google Friend Connect 可以让网站管理员在他们的网站增加一些社会性的功能，允许访客注册并加入到网站，显示自己的头像图标，查看其他已经加入的访客以及他们在 Friend Connect 上的活动。全部工作只需要简单复制粘贴几段代码即可，不需要复杂的编程技术。网站应用了 Friend Connect 以后，可以给网站添加各种 Widgets 实现评论、留言、投票等功能，这种类似的小工具也在不断的增加中。

本站已经注册并添加了 Friend Connect 功能，左边栏较下方的“Friends”便是，欢迎各位朋友加入本站。如果您自己也有一个 blog 或者网站的话，也可以加上这个简单易用的 Friend 功能。

在左边栏较下方的“Friends”区域点击 'Join This Site' 按钮即可通过 Friend Connect 加入本站

Blogger 用户如何安装 Friend Connect？

如果你用的刚好是 Google 的 Blogger 而且是 Blogspot 或者 Custom Domain 用户，那要如何安装 Friend Connect 呢？这看起来是不可能的。因为安装过程要求用户上传两个 html 文件到网站根目录下，而我们显然不可能直接上传文件到 blogspot 服务器。

但事实比我们想象的简单，会有这个疑问是因为 Friend Connect 那个安装界面解释的不够清楚。事实上，当你在注册并安装 Friend Connect 时，如果提供的网站地址是一个 BlogSpot 网站，或者其 Custom Domain 的网站，那么这两个文件就会被自动上传。也就是说你可以直接跳过这一步，什么都不用做，在 finalize 的时候直接就通过验证了。

什么？你问这么隐秘的事情我是怎么发现的？呵呵，好吧，其实我是 Google 到了这篇文章：How to install Google Friend Connect on Blogger。

你博客的 ping 列表真的全在工作吗？

2008-11-15T01:01:00.002+08:00

我们知道在博客发表文章时，可以利用 XML-RPC 技术将更新通知到各种 Blog 的服务商、搜索引擎等，好让它们主动来抓取，从而提高博客文章被收录的速度和范围。

Google 的 Blogger 不像 WordPress，后者提供了一个方便的 Update Service，只要将 Blog 服务商公布的 XML-RPC 接口地址填进去就可以方便的在发布的时候 ping 这些地址。Blogger 只是在 Settings » Basic 有一个“Add your blog to our listings?”的选项，解释说选择了“Yes”，Google Blog Search 以及 Weblogs.com 就会来收录，除此之外并没有一个可以设置 ping 接口地址列表的地方。

我强烈怀疑 Blogger 这个选项的作用，因为曾经有很长一段时间 Google Blog Search 都没有收录我的文章，后来为了确保收录效果，每次发布文章后我都手工 ping，于是通常 5 分钟内文章就会被收录，而 10 分钟左右，Google 的网页搜索也会收录这篇文章（观察到的最快纪录为 8 分钟）。但是每次都要手工去 ping 确实很麻烦，于是今天就琢磨着自己用 PHP 写一个简单的 XML-RPC 客户端来做这个工作，顺便还可以把其它主流的 ping 服务地址加进去，批量执行。

结果是不试不要紧，一试吓一跳。我参考 Weblogs.com 和 Google Blog Search 提供的标准 ping 操作 API 文档写了一个 XML-RPC 的客户端，测试了一下主流的 ping 服务地址列表，发现其中有很大一部分都不能正常工作。

http://blogsearch.google.com/ping/RPC2 http://rpc.pingomatic.com/ http://api.my.yahoo.com/RPC2 http://api.moreover.com/RPC2 http://rpc.newsgator.com/ http://rpc.weblogs.com/RPC2 http://www.feedsky.com/api/RPC2 http://ping.feedburner.com/ http://rpc.technorati.com/rpc/ping http://ping.blog.qikoo.com/rpc2.php http://blog.iask.com/RPC2 http://www.xianguo.com/xmlrpc/ping.php http://www.zhuaxia.com/rpc/server.php

以下就来一一看一下 ping 这些地址得到的具体结果。

以上这些地址中，能够完全按照标准 API 正常工作的有：

http://blogsearch.google.com/ping/RPC2 http://api.my.yahoo.com/RPC2 http://api.moreover.com/RPC2 http://rpc.weblogs.com/RPC2 http://rpc.technorati.com/rpc/ping

以下是其它有问题的 ping 接口的具体情况。

http://rpc.pingomatic.com/

这是一个十分有名，被博客界所有人争相 ping 之的地址，但是，真的有人见过它返回正确的结果吗？我试了很多次，无论是请求 weblogUpdates.extendedPing 方法，还是weblogUpdates.ping 方法，无论是提供两个参数还是三个、四个参数，它返回的 HTTP 头永远只会是“501 Not Implemented”，正文部分没有任何内容。我另外还试了 http://rpc.pingomatic.com/RPC2 和 http://pingomatic.com/ 两个地址，得到的结果一样。

http://rpc.newsgator.com/

这个地址存在大家的列表中，我感到非常诧异，因为这个域名都已经不存在了，我换了很多个 DNS 服务器都不能解析出它的 IP 地址。后来发现了 NewsGator 的另一个 ping 接口：

http://services.newsgator.com/ngws/xmlrpcping.aspx

经过测试，这个是可以正常工作的。

http://ping.feedburner.com/

起先 FeedBurner 的接口很长时间都不返回，纳闷了很久；细查之下，发现 ping.feedburner.com 这个域名做成了 feeds.feedburner.com 的 CNAME 纪录，而众所周知后者已经被墙，所以实际上这个 ping 接口是没有办法直接通知到的，除非发起 ping 动作的客户端在国外运行。

http://www.feedsky.com/api/RPC2

Feedsky 趁着 FeedBurner 被封在国内很是火了一把，可是做事情的态度和质量还是和人家有差距。首先是没有实现 weblogUpdates.extendedPing 方法，而在请求 weblogUpdates.ping 方法时，返回的结果也很不稳定。有时是正常的结果，有时会以错误码 304 将整个 Feed 的内容放在 message 字段中返回，有时又干脆什么都不返回。

http://ping.blog.qikoo.com/rpc2.php

这个似乎是奇虎官方给出的地址，而几乎网上搜到的所有 ping 列表中都有它。奇怪的是，这个地址根本打不开，HTTP 状态码为 404。我曾经猜测是不是大家在传抄过程中不小心弄错了大小写，于是也试了 RPC2.php, RPC.php, rpc.php，结果都是 404。

http://blog.iask.com/RPC2

新浪这个表面看起来很不错，相应速度很快，返回的 XML 格式也很标准。可是无论怎么提交，返回结果都是 flerror: 1; message: sorry,failing。以至于让我怀疑，这个接口背后的后台程序真的有在运作吗？

http://www.xianguo.com/xmlrpc/ping.php

发出请求大约 5 秒钟后，返回如下内容：

Fatal error: Call to undefined function xmlrpc_server_create() in /opt/lamp/code/common/rssreader-common-2008-11-12-14-31-18/topgene/feed/xmlrpc/server.php on line 15

怎么？PHP 的扩展库都还没配置好就当公共运营的服务器了？而且还直接把错误信息输出到页面上，服务器路径信息一览无余。鲜果啊鲜果，让我说你什么好哇！

http://www.zhuaxia.com/rpc/server.php

抓虾比鲜果好点，至少还返回了，只不过不知道返回的是啥。返回结果如下：

<?xml version="1.0" encoding="utf-8"?>
<methodResponse>
<params>
 <param>
  <value>
   <boolean>0</boolean>
  </value>
 </param>
</params>
</methodResponse>

如果说你看不懂 Weblogs.com 的英文文档倒也情有可原，但是照着 Google 的中文文档依葫芦画瓢总会吧？自己想当然的随便弄一下就完事了？

由以上可以看出，大公司终究还是大公司。令人深思的是，这些不能正常工作的接口中，几乎全是国内的服务商，其中有些暴露出来的问题，更是令人汗颜。

Google 手机地图 2.2.1.5 发布

2008-11-07T15:22:00.000+08:00

最近几天在国内的 IT 媒体纷纷报道 Google 手机地图发布了最新版本。原本还在纳闷九月底的新闻怎么现在大家才反应过来，后来看到 Google 黑板报消息，Google 手机地图 2.2.1.5 发布了。和之前发布的 2.2.0 版本相比，除了已经有的“我的位置”、“行车路线”和“公交换乘”功能意外，显著的改动就是增加了“实时路况”功能，可惜目前只支持北京和上海两个城市，希望支持的城市能够逐渐多起来。

在自己的手机上试装了一下 Symbian S60 v3 版本，中文版安装时显示的系统版本号为 2.02(1)，之前版本为 2.02(0)；安装完毕后“关于”界面显示版本号为 2.2.1.5。测试地点和上次一样，而这次利用 GPRS 基站信号定位的地点比上次更接近于实际位置，相差大约为 20 米，可能是因为所处位置并不在道路上。上次定位于实际相差至少 100 米，不知道这次版本升级对“我的位置”定位是否也做了改进。

由于“实时路况”功能尚不支持成都，开启后显示“正在加载路况信息……”不久显示“无此处的路况信息可用”。待以后支持成都市地图后再行测试。

另外顺便也安装了一下英文版，版本号为 2.02(0)，仍然和上次一样，安装后 About 页面显示版本号 2.2.0.13，但功能上也多出了“Traffic Info”选项，开启后出现的情况和中文版一致。

向微软 Live Search 提交 Sitemap

2008-10-28T17:35:00.001+08:00

作为 Webmaster，您一定知道 sitemap；您应该也知道使用 Google 的网站管理员工具来提交 sitemap 让 Google 收录您的网页；您或许还知道 Yahoo! 具有同样的站长工具（及其英文版）。

最近发现微软还在 beta 测试中的 Live Search 也推出了这样方便站长的工具 Webmaster Center。

微软 Live Search 的 Webmaster Center

和 Google 及 Yahoo! 的类似，以上 Webmaster Center 工具会让您提供网站的入口地址和 sitemap 地址，然后 Live Search 会提示您下载一个 LiveSearchSiteAuth.xml （文件名真是个微软特色十足啊）文件，其中含有和网站对应的校验码。上传至您网站的根目录，使其能够用

http://www.mysite.com/LiveSearchSiteAuth.xml

这样的形式访问到即可。过一段时间 Webmaster Center 就会自动处理您提交的 sitemap 了。

对于已经录入过的网站，可以在 Site List 页面上的站点列表中点击网站地址的链接进入每个网站查看具体信息，包括摘要、属性、抓取问题、反向链接、链出链接、关键字和网站地图等信息。当网站地图发生改变时，可以通过 Ping 地址

http://webmaster.live.com/webmaster/ping.aspx?siteMap=[your sitemap web address]

来主动通知 MSNBot。

相信有了这个工具后，我们的网站就更容易被 MSN 和 Live Search 收录了。如果您的网站有 sitemap 而还没有提交给 MSN，不妨试一下这个办法。

挑战 XHTML 的 Strict 标准

2008-10-24T10:37:00.004+08:00

我的 Blog 网页在 Doctype 声明上一直使用的是 XHTML 的 Strict 标准，当初在模板制作完成时是校验过的，可是随着后来无数次的修改、内容添加，现在已经不能通过 W3C 的语法校验了，加上 Google Blogger 在发布页面的时候似乎也并没有考虑目标模板的 Doctype 标准，也部分导致校验的失败。

经过一个下午的努力，终于基本上解决了所有 XHTML 的语法问题，总结如下。

<a> 标签没有 target 属性

在 Strict DTD 里面，超链接 <a> 标签没有 target 属性，因此不能利用 target="_blank" 这样的代码来达到新开页面打开链接的目的。为了实现同样的功能，通常的办法是用 rel="external" 来替代 target="_blank"，然后用如下 JavaScript 代码来处理链接：

function externalLinks() {
  var linkArray = document.getElementsByTagName('a');
  for (var i = 0; i < linkArray.length; i++) {
    var link = linkArray[i];
    if (link.getAttribute('rel') == 'external') {
      link.target = '_blank';
    }
  }
}

然后将该 externalLinks() 函数添加到页面的 onLoad 事件中。如：

<body onload="externalLinks();">

<img> 标签必须添加 alt 属性

对于 <img> 标签来讲，alt 属性是必须的。给图片添加 alt，一方面当图片因为各种原因无法显示的时候，能给访问者以提示；另一方面也便于搜索引擎判断图片的内容，以及更准确的建立索引。

<img> 标签没有 border 属性

<img> 标签是没有 border 这个属性的。我们通常会加上 border="0"，主要是因为把图片放在链接标签 <a> 里时，浏览器会加上一个链接默认颜色的边框，而这通常是多余的。在 Strict 标准中，不能用 border 属性来去掉边框，而只能使用 CSS 控制。同样 align 属性也是不存在的，要实现 absmiddle 这样的目的，也只能用 CSS 代替。

<blockquote> 标签内必须使用 block 级别的标签

<blockquote> 标签用来在页面上表示引用的内容，例如，最常见的，引用代码。我通常习惯将代码的内容放在 <code> 标签中，而这个标签是 inline 级的，不符合 Strict DTD 的要求。<strong>、<b> 等同样会导致问题。符合要求的 block 级标签包括：<address>, <blockquote>, <del>, <div>, <dl>, <fieldset>, <form>, <h>, <h2>, <h4>, <h5>, <h6>, <hr>, <ins>, <noscript>, <ol>, <p>, <pre>, <script>, <table>, <ul>。

不能使用 <embed> 标签

这个问题最容易出现在引用外部媒体文件时，例如 MP3 音乐、视频等。很多资料推荐同时使用 <object> 和 <embed> 来增强媒体引用元素的浏览器兼容性，但是很不幸的，Strict DTD 并未定义 <embed>。其实我们完全可以不使用 <embed> 一样能够兼容浏览器。例如 Youtube 给的代码一般是这样的：

<object width="425" height="344">
  <param name="movie" 
         value="http://www.youtube.com/v/uhsjNTEJD3c"></param>
  <param name="allowFullScreen" value="true"></param>
  <embed src="http://www.youtube.com/v/uhsjNTEJD3c" 
         type="application/x-shockwave-flash" 
         allowfullscreen="true" 
         width="425" height="344"></embed>
</object>

这样无法通过校验。我们可以改成：

<object type="application/x-shockwave-flash"
        width="425" height="344">
  <param name="movie" 
         value="http://www.youtube.com/v/uhsjNTEJD3c"/>
  <param name="allowFullScreen" value="true"/>
</object>

实体用法问题

在 XML 中，实体的写法是 &entity;，以一个 & 符号开头，一个分号结束。因此，Strict 标准的 XHTML 里面不允许出现任何单独的 & 符号，即使是在 URL 中用来分隔查询参数。需要用到这个符号的时候，要用 & 来表示。通常一个实体用法的错误会同时导致 5 个校验时的错误，当解决以后，这 5 个错误会同时消失。由于 Blogger 在发布页面时 URL 直接使用了 & 符号，因此会直接导致 Strict 标准的 XHTML 校验失败。

重复的 id 值

对于 XHTML 标签来讲，id 属性的值必须唯一，如果一个文档中出项重复的 id 就会导致问题。出现这种问题，通常是把 id 属性放在了 Blogger 模板会循环输出的部分。

另外，Blogger 提供的模板中，backlinks 那一部分会导致 4 个不同类别的问题。凭心而论，Blogger 模板在 backlinks 这一块的代码实在写的很烂，用了三个不同的 js 文件，用 JavaScript 输出 CSS，不但使得不同模板之间难以更改这一部分显示的样式，也导致了很多 XHTML 的语法校验问题。例如 Blogger 自己的 Buzz，打开任一个文章的独立页面的源代码，Doctype 声明赫然是 XHTML 1.0 Strict，然而 backlink 那一块的代码不用校验也能看出漏洞百出。

Blogger 目前版本的网站出自著名设计师 Douglas Bowman 之手，其本人对 XHTML 以及 CSS 有着非常深刻的研究。在设计之初，Blogger 还没有 Backlinks 的功能，显然这个蹩脚的 Backlinks 是后来由其他人加上去的。不知道 Bowman 先生在看到这一幕后会做何感想。

Google 黑板报用的是同样的 backlink 代码，不过比 Buzz 知趣的是它的模板干脆去掉了 Doctype 声明。只不过作为 Google 旗下的网站，页面连 Doctype 声明都没有，也是一件汗颜的事情。

言归正传，以下列出 backlink 这部分代码导致的问题以及解决方法。

<div> 和 <dl> 之间的嵌套问题: 在 Blogger 给出的默认模板代码中，是用 <dl> 来实现反向链接列表的；可问题在于，他们将 <BlogItemBacklinks> 放在了 <dl> 之内，而在生成页面时，会将 <BlogItemBacklinks> 这一对模板标签替换成一对 <div> 标签，从而导致 <div> 被嵌套在 <dl> 内。在 Strict DTD 里，<dl> 标签内只允许出现 <dt> 和 <dd> 两个子标签。解决办法是把 <BlogItemBacklinks> 放到 <dl> 外面，当然这样虽然让 XHTML 语法通过校验，但实际的运行结果，会导致每个反向链接条目会占用一个 <dl> 块，而不是预期的放在循环的若干个 <dt> 和 <dd> 中。通过 CSS 可以解决条目之间间距的问题。如果要完美解决这个问题的话，就只有自己重写 Blogger 提供的 JavaScript 函数来改变这一行为了。
<script> 标签的 defer 属性: 在 Blogger 用模板生成页面时，除了将 <BlogItemBacklinks> 替换成一对 <div> 以外，还会在开标签的 <div> 之前加上一个 <script;> 用来引入相关的 JavaScript，同时给出了一个 defer="true" 属性，然而，根据 Strict DTD，defer 属性只能有一个值，只能是 defer="defer"。
<noscript> 内只能用 block 级别标签: 在生成以上 <script> 标签的同时，Blogger 给出了一个 <noscript>，用来当浏览器不支持脚本的时候显示一个 Blog Search 的链接。可是 <noscript> 标签内只能用 block 级别的标签，直接用 <a> 这样的 inline 标签是不行的。
模板占位符问题: 在模板中这段关于 backlink 的代码中，Blogger 用了一些模板标签作为占位符。通常模板标签会在生成具体网页时替换掉，但这里的占位符不会，它们要在实际生成 backlink 条目时被 JavaScript 程序换掉。但是在做 XHTML 语法校验时，这些占位符以 HTML 标签的形式存在于代码中，而又显然不属于 XHTML 定义的范围，从而导致校验失败。解决办法是将它们的尖括号转移，写成诸如 <$BlogBacklinkTitle$> 的形式，这样既能够被 JavaScript 成功识别，保证功能正常，又能通过 Strict 语法校验。要特别注意，其中 <$BlogBacklinkDeleteIcon$> 不要转义，这个模板标签是在页面生成时被替换的，而不是 JavaScript 的数据占位符。

最后，Google 黑板报最近也发布了一篇关于互联网标准性的文章，这篇文章也提供了很多关于改进网站 HTML 代码的参考信息。