经过一晚上的不懈努力，分析比较不同国家、不同机房、不同主机商、不同价格……最后放弃了香港（试用了Scicube的空间，很失望）、新加坡、日本等亚洲空间，最后仍然选择了美利坚。因为看来看去，还是美国的此类服务最实惠，性价比最高，并且最重要的是，现在的延迟情况已经越来越理想，已经可以达到150ms以内了。

看了点论坛，总结下来就是美国与大陆之间延迟最小（仅仅比较延迟，带宽、速率之类的其实我不是很关心）的几个机房依次是Fremont的“几个”机房，西雅图和达拉斯。似乎Fremont这个地方有好几个机房，不过延迟还是存在一定差异，但都在200以内。所以最后我选择了一个150ms左右的，效果相当不错，打开页面的体验比原先提升了不少，wordpress没有以前那么卡了嘎嘎~

购买的也不是美国的主机商，是国内的一个合租，看起来还挺不错的。作为行内人，此类合租的主机计划利润空间都很大，不过有一点好的就是可以用很便宜的钱买一个够用的空间。于是我买了最便宜的新手套餐，100元，600M，月流量6G，可以Addon 3个域名。经过这几年的统计，发现其实就一个小博客，几十MB的空间都用不完，所以现在600M完全绰绰有余了，放图片全部可以flickr（yupoo毕竟还是有中国的传统，开始狗比倒灶了。。）。

总体搬家还算顺利，顺便也把没用的文件整理了一下，瘦身不少，cPanel也用的很熟练，一会儿就搞定了。不过期间附加域名的时候（Addon Domains）出现点问题。显示系统自动开设中出了点问题，导致我不能附加新的域名上去，后来联系了管理员终于解决。不过cPanel对域名解析的验证又把我给卡住了，又是个狗比倒灶的东方网景不让修改DNS Server的地址，无奈之下，想了很多办法。

最后在绝境中求生存，发现了一个连DNS Server都不用修改的方法，可以快速通过cPanel的域名检测：那就是暂停域名解析，让cPanel检测时发现域名完全无法解析，那么就理所当然的通过了（cPanel检测域名的目的是为了防止恶意指向，这点现在国内真的应该学习一下，省的老是错杀老百姓哎）

终于一切搞定，一件大事完成。有意也想购买此空间的朋友可以与我联系~暂时还是不打广告了哈。

先看下使用mouseout的效果：

我们发现使用mouseout时，鼠标只要在容器里一移动，就被出发了hide()，其实是因为mouseout事件也会影响到子元素，也就是事件可能被同时绑定到了该容器的子元素上，所以鼠标移出每个子元素也都会触发我们的hide()。

经过网上一番调研~从jQuery 1.3开始新增了2个mouse事件，mouseenter和mouseleave。现在我们使用mouseleave事件，这个事件在jQuery手册上好像并没有提到…囧
我们来看一下mouseleave事件是否能够解决这个问题。

好了，我们的问题解决了，需要的朋友各取所需吧。

本文参考了jquery中解决div mouseout事件冒泡的问题

.transparent{
filter:alpha(opacity=60);  /*支持 IE 浏览器*/
-moz-opacity:0.60; /*支持 FireFox 浏览器*/
opacity:0.60;  /*支持 Chrome, Opera, Safari 等浏览器*/
}

那么很显然，我们就只能换个思路，把这个input元素复制一个，然后将原来的删除。
在IE下复制元素的时候，其中的值是不会被复制的，所以就达到了清空文件域的目的了。
而在Firefox下，其中的值也会被一同复制，那么我们就顺便清空一下就做到兼容了。
代码如下：

var file = $(":file");
file.after(file.clone().val(""));
file.remove();

使用表单文件域（input type=”file”）时，在PostBack中使用Request.Files获取不到文件。研究了半天，发现在input标签中使用runat=”server”后，是能够正常获取的。但是为了前端的元素ID不被修改，我尽可能不使用runat=”server”。

网上查阅了一下，最终让我找到了原因。用了高级货之后，忘本了呵呵。

要让form能够传递文件的话，必须要在form标签中加入enctype=”multipart/form-data”

<form enctype="multipart/form-data" ID="form1" runat="server">
      <input type="file" name="filename" />
</form>

在input 中使用了runat=”server”，那么ASP.NET会自动处理这些事情，而如果我们要自己DIY，就得记住这些啦！

我想了想，在博客这几次迁徙中，有好几个环节可能导致这些数据的泄露，这兄弟正好捡了个皮夹子，要托工信部的福，让他好不费功夫拿到了我这个“收视率”爆低的博客，内容还挺杂，难道是他和我臭味相投么？

这兄弟技术还是可以的，能改的都改了，可惜在文章的排名上，他可能就比较糟糕了，我的许多文章都能在google第一页搜到，而他的这些文章可能10页开外都不见踪影。

干IT这行，需要的是积累，享用别人的成果往往会让自己止步不前。

2010年我有空还是换套模板吧呵呵，这套模板也用了好多年了，新的开始确实要有一个新的态度了。

其实本站是备过案的，只是迫于各机房的备案申报机制以及服务器的问题（服务器是朋友的，我没理由每天催着别人），所以一拖再拖，让我最后下决心把博客搬到了美利坚的国土上。。无奈啊，速度虽慢，倒还稳定，就这样凑合着吧，日后有机会还是要弄一台自己的服务器。

就着这次大迁徙，顺便也把博客升级到了最新版。不过Google Adsense貌似要停一个月了，竟然PIN码没收到。。晕，重新申请一个，又得等好久。

不过这个HostGator的空间是去年暑假时候买的，没多少时日了，下一步计划可能会搞一个日本的空间，因为最近发现日本网站速度挺快的，价格似乎也不是那么贵。希望中日关系不会影响到互联网。。。

测试了各种可能性，最后我保证了aspx与html也输出完全一致（内容本来就一样，就是格式不同），不过仍然失败。

排除了各种可能，判断很有可能是VS在输出aspx的时候出现了问题。网上查阅了一下，发现果然如此。

原文：

要你原先做的html+css没有问题的话，改为aspx后，.net环境在编译后让html的编码格式改为了utf-8。而你的css文件没有进行相应的变更就会出现css失效的问题。

仔细检查css文件是否出现乱码，最简单的方法就是先将css文件中的中文注释删除掉。

or 在web.config文件中加入下面代码：

<globalization requestEncoding=”gb2312″ responseEncoding=”gb2312″/>

原文地址：http://blog.csdn.net/ytmf007/archive/2009/07/20/4363348.aspx

 

经过测试，在Web.Config中的<system.web>中加入以上代码，页面布局恢复正常。:lol

既然是编码问题，我检查了CSS，全都是ANSI编码，并且在其中混有中文注释(-_-)，罪魁祸首找到了。当然了，配置web.config是一劳永逸的方法，所以推荐使用此方法。

近日忙于求职，所以博客也很久没更新了。不过由于最近正在学习ASP.NET，所以还是有很多问题需要记录的。

出错的地方到了，就是在第二步插入数据时报错了，页面上会提示类似于以下内容的错误信息（省略了大部分信息，重点突出关键行）：

WordPress database error: [Incorrect string value: '\xCD\xF8\xD5\xBE\xB9\xA6...' for column 'option_value' at row 58]
INSERT INTO wp_options (option_name, option_value, autoload) VALUES ('siteurl', 'http://*.edu.cn/jx2009', 'yes'), ('blogname', 'My Blog', 'yes'),
...........................................
 ('upload_path', 'D:\\��վ����\\��ѵ����/wp-content/uploads', 'yes'),
...........................................

我们可以看到upload_path这一项的值中间含有“�վ”这样的乱码（可能乱码形式不一样，总之是乱码），这个应该是PHP的问题，也总就是那utf-8和gb2312之间的事情了。当务之急不去研究那些编码问题，而是找到简便的解决方法。经过观察，其实WordPress的upload_path字段并不需要储存完整的路径，后台可以将这个路径直接设置为“wp-content/uploads”，那么在安装时候我们也可以直接把上传保存路径设置为这个，不需要读取完整的绝对路径了。

具体解决方法：找到wp-admin/includes/schema.php，第188行

//$upload_path = WP_CONTENT_DIR . '/uploads';      //这一样我把他注释掉
$upload_path = 'wp-content/uploads';   //直接给upload_path重新赋值，指定为这个路径。

保存文件后，清空数据库，重新进行安装，错误不再出现，一切正常。后台测试上传图片，正常！问题成功解决。

span{display: block; width: 110px; height: 40px;}
span:hover{background: 0 -40px;}
span.button-1{background:url(../images/tabs/button_1.png);}

这样测试出来的结果跟我预期的不一样，我想在span.button-1定义背景图片，然后在鼠标经过时hover显示悬停效果。本应该是会移到背景的第40像素开始显示，可是仍然只显示原始图像。
经过多次测试，终于发现是由于伪类的书写顺序不正确造成的。网上查阅了一下资料，的确伪类有明确的书写顺序规定，如果错了的话就可能造成显示结果不正确。
后来分析一下我的CSS，发现可能是由于最后一行button-1的样式把hover的background又给覆盖了。于是把伪类放到最后，也就是必须将伪类写在本身选择器之后。问题解决。

虽然我的这个问题和伪类之间的顺序并不是很相关，但是这些伪类之间的顺序还是值得关注一下的，省的以后又出现同样的问题。
顺序如下：

a:link
a:visited
a:hover
a:active

总结一下就是LVHA，听说这个叫爱恨原则，LoVe/HAte，便于记忆吧呵呵。

很高兴在关于非WP目录下的.php文件显示文章摘要或者别的WP信息的方法一文中找到了实现方法，也很容易上手，放在一个空白的测试页中运行成功。

不过当我把WordPress的永久链接(Permalink)形式从默认改成了任何伪静态形式，文章列表调用就失效了，显示空白。

后来查阅WordPress支持论坛，似乎也有人遇到过由于更改了默认的永久链接设置而造成列表调用失败的问题，不过作者似乎自己解决了该问题。问题主要可能是出现在将WordPress安装在子目录下，如/blog/，而在永久链接设置的地方是不需要指定目录的。然而在自行外部调用的时候就出现了问题，这个可能是WordPress设计上的一个BUG吧。

我尝试了一下加上了目录的路径，/blog/%postname%/，这样设置以后列表调用成功显示内容，只不过，在WordPress中的所有永久链接地址就出现了2次/blog/，不过这个却不影响使用，只是不好看而已。囧

由于我也是第一次接触wordpress的开发，所以并不是很熟悉那些函数接口，在查阅了手册之后发现可以使用自定义的查询方式，使用query_posts来调用，结果使用了这个方法以后，问题解决。

具体代码如下：

<?php
        $loca="/blog";//这里定义你的WP目录
        require_once( dirname(__FILE__) . $loca.'/wp-load.php' );//注意这里是wp目录下的wp-load.php
	wp();//这样wp的加载就完成了，我们不需要加载模板。
?>
<?php
query_posts('showposts=3');   //就是这里加了一句query_posts，这样也可以实现调用条数的指定。
while (have_posts()) : the_post();
?><div>
<?php the_excerpt();?>
</div>
<?php endwhile; ?>
<!--导航开始-->
<p align="center">
<?php
global $paged, $wp_query;
if($paged>1)
echo '<a href='.str_replace($loca,'',get_previous_posts_page_link()).'>&laquo; Previous Entry</a> ';
if($paged<$wp_query->max_num_pages)
echo ' <a href='.str_replace($loca,'',get_next_posts_page_link()).'>Next Entry &raquo;</a>';
?>
</p>
<!--导航结束-->

PS：这个方法只能用在同一个站点下，不同域名，也就是跨站的情况下，是不能使用这个方法的，如果跨站的话还是只能使用javascript方式调用。JS调用可以采用Feed to JS来实现。

为了避免URL不统一，当然要做URL Rewrite，用301永久重定向来让Google知道哪个才是我提倡的地址形式。

网上大部分都是Apache上的配置方式，即.htaccess的，当然与ISAPI_Rewrite 2的语法会有所不同，但是手动转换了一下仍然存在问题，可能是我水平不够吧。
后来在寻找WordPress插件的时候无意中看到一个插件的介绍页中提供了ISAPI_Rewrite和.htaccess的规则：

来自：Trailing Slashes, IIS and F5 / Big-IP

ISAPI_Rewrite 2:
RewriteCond Host: (.*)
RewriteRule ([^.?]+[^.?/]) http\://$1$2/ [I,RP]

ISAPI_Rewirte 3:
RewriteCond %{HTTP:Host} (.*)
RewriteRule ^([^.?]+[^.?/])$ http\://%1$1/ [NC,R=301]

来自：Two WordPress plugins you don’t need and shouldn’t use

Apache .htaccess:
RewriteCond %{REQUEST_URI} ^/[^\.]+[^/]$
RewriteRule ^(.*)$ http://%{HTTP_HOST}/$1/ [R=301,L]

看起来是2个作者用了2种方法来实现的，反正我们也不求甚解，只要能用就好。

今天还找到个方法来避免重复内容的产生，有兴趣可以看一下使用权威链接(Canonical URL)避免重复内容

这个功能将会自动在页面中添加权威链接的<link>标签，关于这个您可以阅读使用权威链接(Canonical URL)避免重复内容

有了这个功能可以在一定程度上避免重复内容的产生，不过我还是使用URL Rewrite做了重定向来添加URL末尾的斜杠，做到万无一失。

当然期间还碰到了All in one SEO pack升级错误，提示：

Call to undefined function admin_url()

后来查阅了资料，发现是由于WordPress版本过低造成的，我比较偷懒，2.5.2用了好久了。
这次正好英文站用的最新的WordPress，于是趁这次机会升级到了2.8.2。
升级完成后All in one SEO pack插件成功激活。

通常情况下，我们认为下面这几个URL地址指向的是同一个页面（首页）：
www.example.com
example.com/
www.example.com/index.html
example.com/index.php

但从技术角度来看，这些URL都是互不相同的。对于上述的URL，Web服务器完全可以返回完全不同的内容。而如果这些URL地址所返回的内容（也就是显示的内容）都一样时，Google需要从这些URL中选出一个具有代表性的，而忽略其余的。那么这个被Google选中的URL，就是一个标准化的URL。Google选择的这个过程称为“标准化”。标准化这一词原本是Google的内部词汇。

Google是怎么URL标准化的？

通常，Google是根据外链数量来判断哪个URL为标准化URL。

URL标准化有什么意义？

同一URL出现多个版本(如read.php?id=1和read.php?id=1&page=1)，同一位置出现多个URL形式(如list.php?companyname=xxx和list.php?companyid=123)，及大小写问题等都可能导致在搜索引擎中出现相似页面，从而影响网站在搜索引擎中的表现。

我们知道，搜索引擎是喜欢原创的东西，或者说喜欢不同的东西，而不喜欢重复的相似的内容。他们希望提供给用户更好的搜索体验，因此，他们也会对相似的页面进行筛选。我们能做的就是让把一些可以避免的重复页面统一起来，让搜索引擎只抓取最主要的一个。

怎么样才能使URL标准化呢？

使用301转向（301 Permanently Move）来实现URL标准化，搜索引擎蜘蛛来抓取时，这些页面全部指向了那个希望被抓取的页面，并且通过301的HTTP状态码（永久重定向，对于搜索引擎是友好的），这样搜索引擎就知道那个页面才是主要的，那么这些非主要页面以后就不会被抓取，或者说抓取后忽略。

怎样来做301转向呢？

对于Apache的主机，我们可以使用.htaccess来实现。但是对于国内大部分主机来说，都是Windows平台的，使用IIS作为Web服务器，我们必须使用ISAPI_Rewrite来进行URL重写。关于如何使用ISAPI_Rewrite来做URL重写，请参阅：利用 ISAPI_Rewrite 做301永久转向

另外的方法：使用权威链接(Canonical URL)避免重复内容，最近发现的。09/07/23

URL 重写就是把传入 Web 请重定向到其他 URL 的过程。

比如浏览器发来请求http://www.steveluo.name/category/english-site/，服务器自动将这个请求中定向为http://www.steveluo.name/index.php?category_name=english-site  关于URL重写的相关内容我们将在以后的文章中详细介绍。

我们知道在Apache中有mod_rewrite来实现URL的重写功能（URL Rewrite），然而IIS并没有自带这个功能，因此我们就需要使用第三方组件来实现。其实目前有好几种IIS下的Rewirte组件，都是通过ISAPI筛选器来加载然后实现URL重写的。

用得比较广泛的一个是ISAPI Rewrite，基本上国内支持Rewirte功能的Windows网站空间都采用了该组件。ISAPI Rewrite组件有免费版以及商业版，免费版只支持全局httpd.ini配置（不能对每个站点进行单独设置，除非通过加载不同的dll来实现，比较麻烦。）而商业版支持用户自定义httpd.ini文件，只要放在站点根目录下就能生效。这个大大方便了用户自己修改URL重写规则。

ISAPI Rewrite是一个基于正则表达式的强大的URL处理引擎，他使用起来基本上就像Apache的mod_rewrite，但是他是专门为微软的Internet Information Server (IIS)设计的。

ISAPI Rewrite是一个使用纯C/C++编写的ISAPI筛选器，所以速度是相当快的！ISAPI Rewrite使你可以自由的规划网站的URL。

ISAPI全称为Internet Server Application Program Interface。

ISAPI Rewrite 2 产品地址

ISAPI Rewrite 3 产品地址 

3.0版本主要特性是支持采用Apache的 .htaccess文件来在IIS中使用 mod_rewrite。这个特性使得IIS和Apache在日常应用的Rewrite上的区别基本消除了。

国内大部分空间商都没有关注到商业版这个非常方便的功能，只为用户设置全局重写规则，这样会影响服务器性能，以及当某些规则比较复杂时，会造成冲突，给用户带来不便。

安装篇：

ISAPI Rewrite在安装上相当方便，如果你下载的是安装包，只需要按照提示进行安装即可。而如果你下载的是压缩包，那么只要将文件夹解压缩的任意目录，然后在IIS站点的ISAPI筛选器中添加ISAPI Rewrite的dll即可。

这里要注意的是：必须给予ISAPI Rewrite所在目录IIS_WGP组的读写权限，否则你的网站就会直接Service Unavailable，应用程序池遇到错误而停止。在事件查看器中可以找到相应的错误。

使用篇：

安装成功以后，接下来就要看看怎么用了。我们这里只说一下最简单的应用，因为大多数人只用URL重写功能来实现SEF（搜索引擎友好），以及简单的防盗链的功能（可以参考利用 ISAPI_Rewrite 实现防盗链）。如果您有兴趣了解一些深入的功能的话，可以去看一下官方的使用手册。

我们需要对ISAPI Rewrite编写URL重写的规则，将这些规则写在httpd.ini中，用户访问时，就能实现URL重写。

编写Rewrite规则需要我们对正则表达式有一定的了解，推荐大家看一下《30分钟正则表达式入门教程》。当你了解了正则表达式以后，如何编写规则请参考官方使用手册以及一些例子，相信很快就会上手。

ISAPI Rewrite 2使用手册

ISAPI Rewrite 3使用手册

当然，网上有很多别人写好的Rewrite Rules（重写规则），我们可以方便的使用，因为大部分程序所使用的URL重写规则是一样的，比如Discuz!, WordPress等。

当我们已经写好了httpd.ini以后，将httpd.ini放在相应的位置后就能使用了（免费版放在ISAPI Rewrite安装目录中，商业版只需要放在需要重写的站点根目录下就可以了）。

但是很多人都不知道如何设置域名解析来实现，原因主要在于各域名注册商的管理面板设置方法并不统一，不像DNS域名解析设置泛解析方法都采用*号。

这里以笔者个人使用过的经验列出几个常用注册商管理面板的空主机名添加方法：

• 新网：添加一个名为noprefix的主机名
• 新网互联：新网互联的MyDNS系统有纯域名解析的功能，直接在这里添加A记录即可。也可以添加包含主机名的记录，将主机名留空，直接添加，系统会自动添加到纯域名记录中去。
• DNSPod：留空会自动填写，以@为主机名。
• ENom：同DNSPod，使用@为主机名。
• Name.com：留空添加即可。
• Godaddy：以@为主机名。默认就有，只需要修改一下IP即可。

笔者使用过的就这些，以后接触到更多的会测试并及时更新列表的，希望能给需要的人带来帮助。同样，希望大家使用过其他面板的能够告诉我其他面板的设置方法，以便添加更多内容，呵呵～

如果每个客户我们都需要去手动添加一个主机名的话，那似乎麻烦了点。因此，我们可以使用泛解析记录（WildCard DNS Record）来实现添加一条记录对应多个主机名。

现在越来越多的人都开始接触到服务器，也开始卖卖小空间，笔者经常能够看到有人在问泛解析如何做？

今天来具体地看一下，泛解析在域名管理以及服务器设置的方法。

域名解析管理：

其实对于一个域名做泛解析记录是非常简单的，只要添加一个主机名为*（星号）的A记录或CNAME别名记录到指定的IP，那么只要是这个域名下的二级域名就都能够解析到这个IP（排除单独添加过的主机名）。

泛解析国际上有比较统一的标准，都使用*（星号）表示，所以各个域名注册商的管理面板使用上没有什么区别。而如果你要做空主机名的解析（如steveluo.name，不含www），就会有些差异了。您可以阅读：各平台DNS解析添加空主机名方法汇总

服务器设置：

对于做泛解析的域名来说，通常对服务器拥有完全控制权，因为只有这样，在这台服务器上任意添加做过泛解析的域名才是有效的。例如，在服务器上，我们添加一个站点，主机头设为www.steveluo.name，那么我们就可以通过www.steveluo.name来访问该站点了。而我们在域名解析设置时并没有单独设置www这个主机名。

只要是steveluo.name的二级域名都能够访问到这台服务器。这样，不需要对域名做任何设置，只要Web服务器中有这个主机头，就能访问相应的站点。例如bbs, test这类主机名。

另外补充一下：我们看到很多网站空间商提供了Web邮件服务，通过Web界面来收发邮件，用户只要通过自己域名的某个二级域名就能访问邮件Web界面（例如mail.steveluo.name）。这里其实和泛解析没有关系，只是在Web服务器中添加了一个空主机头的站点，这样只要在所有站点中没有找到所请求的主机头，就打开空主机头的邮件Web站点。而用户只要自己添加一条记录指向这台服务器（不管是A记录还是CNAME别名），就能访问邮件站点了。

不过经过笔者的测试，对于能够伪造Referer来源的程序（比如迅雷等下载工具），这个防盗链就形同虚设了。原理明白了就知道为什么了。

原理：判断Referer是否来自本地主机或在信任列表中的域名，否则就执行重写规则，重定向到一个文件作为防盗链提示。

这里用到了Rewrite Referer来判断URL来源，具体规则如下（分别包含了2.x和3.x版本的规则，请选择使用）：

# For version 2.x
RewriteCond Host: ^(.+)$
RewriteCond Referer: ^(?!http://\\1.*).*$
RewriteCond Referer: ^(?!http://(.*\.google\.com|www\.steveluo\.name).*).*$
RewriteRule ^.*\.(?:gif|jpg|png|exe|rar|zip)$ /block.gif [I,O,N]

# For version 3.x
RewriteCond %{HTTP:Host} ^(.+)$
RewriteCond %{HTTP:Referer} ^(?!http://\\1.*).*$
RewriteCond %{HTTP:Referer} ^(?!http://(.*\.google\.com|www\.steveluo\.name).*).*$
RewriteRule ^.*\.(?:gif|jpg|png|exe|rar|zip)$ /block.gif [NC,N,O]

.*\.google\.com表示来自*.google.com的访问是被允许的，也就是所谓的信任列表，括号中可以写多个被信任的域名或者URL（URL只需在后面加上相应的目录或文件名即可，注意，使用斜杠时要“\\”来转义。），使用“|”来分隔每个信任URL。注意其中的点“.”需要用”\.”来转义。

参数：[I,O,N]中的N根据网上查到的资料说是不读取缓存，用来解决打开过盗链网站的图片以后，再打开自身网站仍然显示缓存中的盗链提示图片的问题。具体我也没试过，因为缓存机制实在太诡异，不知道什么时候会缓存而什么时候不缓存。。。I表示忽略大小写

这样，就用ISAPI Rewrite实现了简单的防盗链，对于普通图片防盗链来说是很有效的，因为几乎没人在打开网页时，会用迅雷去下载里面的图片。而且，大多数盗链网站还是以用户浏览为主，所以作为用户，只是看到了盗链提示而已，反而能为我们带来流量。

顺便提一下：盗链在英语中是hot link或leech

301转向（301 Redirect : Permanently Moved），表示内容永久性转移到新的URL，这样搜索引擎就会知道内容已转移，会去抓取新的URL，因此是友好的。

注意，只有支持自定义URL重写规则的网站空间才能实现自定义的301转向。

域名间的301转向

有时，我们会在域名解析时，创建一个空的主机名，来方便用户输入网址，而省去了www。这样虽然方便了用户，但是从SEO的角度来说，是违反了URL标准化准则的，因此，我们需要对这些不统一的URL进行301重定向。

以下规则能够将steveluo.name以301重定向方式转到www.steveluo.name，这样对于搜索引擎来说是友好的。

注意：本文列出的代码中包含了2.x与3.x版本2种规则，在你使用时务必确认自己使用的版本，否则是无法工作的。

# For ISAPI_Rewrite 2.x
RewriteCond Host: ^steveluo\.name$
RewriteRule (.*) http\://www\.steveluo\.name$1 [I,RP]

# For ISAPI_Rewrite 3.x
RewriteCond %{HTTP:Host} ^steveluo\.name$
RewriteRule (.*) http\://www\.steveluo\.name$1 [NC,R=301]

整个域名下的文件访问都将被重定向，而不仅仅是首页而已！

注释：在规则最后有[I,RP]标记，通过查阅ISAPI Rewrite 2官方使用手册我们知道，I表示忽略大小写，RP表示使用301转向

页面间的301转向

当我们改变了某些页面的地址，但是又不想损失流量，就应该使用301转向，将原来的URL重定向到新的URL上，这样搜索引擎会知道页面地址变更，而不会以为这个页面出错消失了。 规则如下：

# For ISAPI_Rewrite 2.x
RewriteRule ^/oldpage.htm$ http://www.steveluo.name/newpage.htm [I,O,RP,L]

# For ISAPI_Rewrite 3.x
RewriteRule ^/oldpage.htm$ http://www.steveluo.name/newpage.htm [NC,L,R=301,O]

我们将根目录下的oldpage.htm使用301转向重定向到了http://www.steveluo.name/newpage.htm，当然，我们也可以自己指定任意目的地址，可以是站内的（同样以/pagename的形式）或站点外的（以http://开头的URL形式）。

注释：这里出现的O表示对URL进行标准化，可能是用来处理Unicode编码的地址（例如包含中文的URL）以及QueryString的内容，这里我没有测试过。而L表示Last Rule，最后一条规则，也就是后面的重写规则对他不起作用，防止被其他匹配的规则再次重写而造成混乱。

最后说明一下：本文所使用的RewriteRule（重写规则）仅适合ISAPI Rewrite 2.x以及3.x版本，因为标识符（比如[I,RP]）在2.0以前版本是不支持的，会在httpd.parse.errors中提示错误。

而如果你使用的是ISAPI Rewrite 3.0以后的版本，那么2.x的规则是不兼容的，不过3.0版本提供了一个规则转换器，我们可以直接将2.0的规则导入，它会自动转换成3.0版本的规则。

我们先来看一下这几个URL：

http://www.example.com/product.php?item=swedish-fish

http://www.example.com/product.php?item=swedish-fish&category=gummy-candy

http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678

这3个URL或许打开的都是同一个页面，完全相同或者只有微小差别，那么这样对于SEO来说是不太理想的，因为产生了重复的页面，这样权重就被分散了，虽然我觉得Google会对此类URL进行识别与整理，但是人为地说明效果应该是最佳的，Google也推荐使用这种方式。

所以我们可以使用权威链接（Canonical URL）这个东西，简单地使用<link>标签来指定你想要提供给搜索引擎的URL。

<link rel="canonical" href="http://www.example.com/product.php?item=swedish-fish" />

这样Google就会明白，那些重复的内容都是指向这个权威链接的。这样可以尽可能把URL规范化，减少重复内容对排名的影响。

当然这个标准可以适用于各个搜索引擎（作者这么说的，我们就先假设是这样的）

还有一些FAQ内容就不写出来了，大家有兴趣可以去看下原文，是Google工程师回答的，也许也会有帮助。例如说到了要迁移站点，是否可使用这种方法来替代301永久转向等等

查看原文：Specify your canonical （需代理，blogspot上的）