深入学习Apache模块mod_rewrite

 人们一提到.htaccess配置文件，首先映入他们脑海的就是用mod_rewrite进行URL地址重定向。对mod_rewrite的看法各不相同，为了就人们对mod_rewrite是怎么认识的有一个快速的看法，我在twitter上搜索了一下"mod_rewrite"，并且将我写这篇文章时的前几个搜索页面的结果找出来：

midk：啊！.hatccess和mod_rewrite是如此的痛苦……

basterzenbach:我喜欢mod_rewrite。在我的有生之年，我都可以用它工作，并且还是不能精通它——太强大了。

mikemackay:仍然喜欢mod_rewrite的灵活性——又得到了拯救。这往往容易被忽略……并且要比你想想的要简单！

hostpc:我讨厌mod_rewrite。无法用它正常工作。

awanderingmind:噢，Wordpress 和Apache，你们带给了我烦恼。该死的mod_rewrite！

danielishiding:为什么mod_rewrite不工作了！该死！

      我注意到人们清楚的认识到了mod_rewrite的强大，但是往往在语法面前望而却步。考虑到Apache的mod_rewrite文档在前面几页说了同样的问题，这并不奇怪：

“mod_rewrite例子和文档的数量，尽管可以以吨来计算，但是它是巫术。该死的冷漠的巫术，但仍然是巫术。“——-布莱恩摩尔

      太糟糕了！因此，在本文中。我真的试图使mod_rewrite的难度降低一个档次。我不仅要去尝试解决mod_rewrite的的语法，还要设法提供一个工作流程，使你可以通过它调试和解决你的mod_rewrite问题。我也会给你一些有用的现实世界中的例子。

     然而，在开始之前，我还要做一个警告。许多学科，尤其是这个，除非你自己动手尝试，否则你是不会学会的！这就是为何我会更专注于教授一个调试工作流程。像往常一样，如果你还没有加载模块，我会告诉你如何安装好你的系统。我敦促你们在你们自己服务器上做这些例子，如果是测试环境，则更好。你的经验和成功次数越多，你就会越容易将这种知识扩展到更高级的例子和应用。享受吧。

mod_rewrite的是什么？

      mod_rewrite的是一个Apache模块，可使服务器操纵请求的网址。根据一系列规则对传入的网址进行检查，规则中包含一个正则表达式来检测特定的格式。如果在地址中发现了一个格式，并且满足适当的条件，该格式就会被一个替代的字符串或者是动作取代。这一过程一直在进行着，直到没有更多的规则或是程序被明确告诉停止。

     上面的内容可以总结为以下3点：

     *有一个按顺序排列的处理规则列表。
     *如果有一个规则相匹配，它会检查那条规则满足的条件。
     *如果一切都匹配，它会替代或这是做出一个动作。

mod_rewrite的优点

      用这样的一个地址重定向工具有很明显的优点，但是有一些东西也不是很明显。

      人们用mod_rewrite的主要原因是为了将丑陋的、神秘的网址转化为所谓的“友好的地址”或者是“干净的地址”。新网址通过多种方式变的友好，而不是仅仅一种。它们是用户友好的，表现在可更容易为人类所理解，瞥一眼就可以，并且用户可能自己来操纵网址。作为额外的奖励，这些网址对搜索引擎来说也是友好的。创建友好的网址是一个搜索引擎优化技术，网址是一种有效描述他链接的内容的方式。看看下面的例子：

 不是很友好: http://example.com/user.php?id=4512
 比较友好: http://example.com/user/4512/
甚至更好:     http://example.com/user/Joe/

      最后的链接不仅仅是看上去变的简单了，它还可以使搜索引擎从中提取语义。这种基本的URL重写机制是使用 mod_rewrite的一种方式。然而，正如你将要看到的一样，除了这些简单的转换，它还可以作很多的事情。

      将同一个例子扩展一下，一些人声称通过用 mod_rewrite改变你的网址可以获得安全效益。给出同一个例子，想像，考虑一下下面这个对用户id的攻击：

 http://example.com/user.php?id=AHHHHHH
http://example.com/user/AHHHHHH/

      第一个例子是明确的PHP脚本调用，并且必须得处理无效的ID号。写得不好的脚本可能会失败，更极端的情况是（写得不好的Web应用程序）错误的输入可能导致数据损坏。然而，如果只给用户显示友好的网址，也就是说他们甚至不知道user.php网页的存在，他们可能只知道友好的URL结构。试图在这种情况下进行的攻击可能在读取PHP脚本之前就已经失败了。这是因为mod_rewrite的核心是正则表达式的格式匹配。在上面的例子中，你的地址中可能有一个数字，比如（\ d +），而不是字符，像a-z，当重写模块找到的是字母而不是数字时，重写就会失败。

 
      从安全的角度讲，这种额外的抽象功能是不错的。如果你愿意，你甚至可以防止直接访问原始PHP脚。不过，我们决不能使用mod_rewrite来替换一般的安全措施，你的脚本应当在服务器端进行验证。

在服务器上启用mod_rewrite模块

      就像启用.htaccess支持一样，启用 mod_rewrite或者是其他 apache模块必须修改全局配置文件（httpd.conf）。就像前面说的一样，由于mod_rewrite用的是如此广泛，主机提供商几乎总是启用这个模块的。然而，如果你怀疑你的主机提供商没有启用它（我们会在下面测试），你应当联系他们，并且他们很乐意启用它。

      如果你是自己安装的Apache，毫无疑问，当编译Apache的时候，要将Mod_rewrite模块包括进来，因为默认情况下是不包括它的。然而，它是用的如此普遍，几乎所有的安装指南，包括Apache的安装文档都会在他们的示例中指出如何将它编译进来。然而，预先包装的版本已经将它启用了。如果你正在读这篇文章，那么你的Apache有99%的可能已经将 mod_rewrite模块编译进来了，所以你只须进入下一个步骤。

 
      如果你是你们网络的网络管理员，并且你想确认一下你已经加载了这个模块，你应当检查一下httpd.conf文件。在配置文件有很大一部分用于加载那一大堆模块。下面的行可能会出现在文件中，如果是，好极了！如果它被注释掉了，或者说是在它前面有一个#号，哪么你只需将#号删除掉，留下下面的这一部分：

1、LoadModule rewrite_module modules/mod\_rewrite.so 

      老版本的Apache1.3，可能需要你在LoadModule目录中加上以下目录：

 # Only in Apache 1.3
 AddModule mod\_rewrite.c

     然而，这好像在Apache 2及以后的版本中消失了，只需要LoadModule指令。

     如果你不得不修改配置文件，那么你必须重启你的 apache服务。你要记住备份你的原始文件，以防万一你需要将它还原回以前的版本。

测试mod_rewrite模块

      你可以通过多种方式测试 mod_rewrite模块是否启用（或者是工作）了，最简单的方法是查看PHP的phpinfo函数的输出。创建下面的这个非常简单的PHP页面，在你的浏览器中打开它，并且在输出结果中找一下"mod_rewrite"。

<?php phpinfo(); ?>  

       mod_rewrite应该会显示在网页的“Loaded Modules”部分中，就像这样：

       然而，如果你用的不是PHP（虽然在接下来的教程中我会用它），还有很多方式来测试。Apache有许多命令行工具。

在我的基本身份验证的第一个教程中，我提到了在htpasswd的工具。你可以使用诸如 apachectl或者httpd的其他工具直接对模块进行测试。有命令行开关可以使你检查现有的已经安装加载的模块。您可以执行下面的命令来得到一个所有已加载的模块的列表。 shell >  apachectl -t -D DUMP_MODULES          这里我展示的是这个命令的帮组页面。然后，我运行了这个命令，并在结果中查找了“rewrite”，有一行输出与之相匹配。       最后，如果你还是不能确定它是否启用了，像以前一样将它注释掉，看看会发生什么！之后，我会介绍语法，但这里仅仅是一个测试，看看他是否工作了。下面的.htaccess文件将重定向任何给定的文件夹请求到good.html文件，这意味着如果你的 mod_rewrite工作了，你应该看到good.html。如果mod_rewrite不工作，那么你会看到一个带警告的index.html。 # Redirect everything in this directory to "good.html" RewriteEngine on RewriteRule .* good.html     下面是正确的和错误的页面： .htaccess的内容      通常情况下，你可以写在.htaccess文件中的内容也可以写到全局配置文档中。在 mod_rewrite中，如果你将一条规则放的文件不同，会有一点儿小差异。最明显的是： 如果你将【……】规则放到了.htaccess文件中，目录的前缀（/)在REQUEST_URI变量中会被去掉，因为所有的请求会被自动假设是现在目录的相对地址。——Apache文档      有一点要记住，如果你在网上看例子或者是你自己在测试一个实例，要注意前面的斜线！当我将一些例子放到一起的时候，我将在下面试图澄清这些问题。 正则表达式       本教程不打算教你正则表达式。对于那些你知道的正则表达式， mod_rewrite中用到的正则表达式会根据Apache版本的不同而有所改变。在Apache 2.0中，他们似乎是与Perl兼容（pcre）的正则表达式。这意味着许多你所使用的简写，例如\w的意思是[A-Za-z0-9]，\d的意思是 [0-9]，以及更多不存在的简写。但是，我的公司使用的是Apache 1.3，并且Apache1.3的正则表达式是比较有限的。       如果你不知道正则表达式，下面这些有用的教程会让你快速入门： Nettuts very own Jeffrey’s Crash Course The Absolute Bare Minimum Every Programmer Should Know About Regular Expressions Quick And Practical Tutorial Smashing Magazine Links on Regular Expressions      还有每个人都应该知道的一些引用： Popular Added Bytes Cheatsheet For Regular Expressions Added Bytes Cheatsheet for mod_rewrite Explain Regular Expressions      如果有还没有花时间去学习正则表达式，我强烈建议你花点时间学习一下。因为通常情况下，他们没有你想象的那么复杂。我从多年的经验中选择了上面的那些关于正则表达式的链接，我觉得这些指南对于学习最基础的东西来说，写的很好。如果你想有效的利用 mod_rewrite，正则表达式是至关重要的，在其他方面，了解他们也很有用，如在你最喜爱的代码编辑器中使用“查找/替换”。 初次体验      好了，你等待的耐心已经足够大了，让我们快速的看一个例子。这个例子在链接的源代码中有。这里只给出.htaccess文件的代码： # Enable Rewriting RewriteEngine on # Rewrite user URLs # Input: user/NAME/ # Output: user.php?id=NAME RewriteRule ^user/(\w+)/?$ user.php?id=$1      在我对它做任何解释之前，我会先讲解一下目录中的另外一个文件。      目录中包含两个文件：index.php和user.php。index.php中有一些指向user页面的链接或者是各种各样的格式。php代码用来显示页面被请求了，并检查传过来的"id"参数。下面是user.php的代码： <?php // Get the username from the url $id = $_GET['id']; ?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> <title>Simple mod\_rewrite example</title> <style type="text/css"> .green { color: green; } </style> </head> <body> <h1>You Are on user.php!</h1> <p>Welcome: <span class="green"><?php echo $id; ?></span></p> </body> </html>        这个例子有一些不同的地方。首先，请注意URL重写必须通过RewriteEngine指令启用！如果你的htaccess文件要使用重写规则，应始终包括这行，否则你不能确定它是否启用了！作为一个经验法则，总是将它包括进去并确保每个.htaccess文件中你只包含了一个。字符串“on”不区分大小写，因此，当你在网上看到其他的例子用的是“On”，这是可以接受的。      第一个重写规则是用来处理user.php页面的。就像这些注释说的一样，我们正在将友好的网址重写为正常的URL格式。为了做到这一点，当输入友好的网址时，事实上，我们将它转化成了标准的查询字符串URL。将它分解开，我们就得到了： T规则: RewriteRule ^user/(\w+)/?$ user.php?id=$1 匹配模式: ^ 输入的开头 user/ 以“user/“开始的请求地址 (\w+) 提取所有的字母，并将提取的结果传给$1 /? 可选的斜线 "/" $ 输入结束 替换为: user.php?id= 要用到的字符串. $1 上面第一个提取到的字符串。      下面是一些例子及对上面每行话的解释： User.php 输入 匹配 提取 输出 结果 user.php?id=joe No   user.php?id=joe Normal user/joe Yes joe user.php?id=joe Good user/joe/ Yes joe user.php?id=joe Good user/joe/x No   user/joe/x Fail       因此，第一个例子不会受到重写规则的影响，并且可以正常访问。第二个和第三个例子与重写规则相匹配，会根据重写规则被改写，可以正常访问，最后一个例子不符合规则且无法访问。服务器没有用户目录，不能试图找到它。这是预期的结果，因为user/joe/ x是一个无法访问的网址！      这个例子比较容易理解。然而，为了澄清任何更复杂的事情，就像我现在做的一样，我必须要花好几分钟去注意细节。在下一节中，我们将举一个更复杂的例子，这个例子涉及所有重写的核心内容。         注意：如果这个例子不能在你的机器上运行，可能是由于你的Apache或 mod_rewrite 版本与PCRE不兼容。请尝试着将^user/(\w+)/?$改为  ^user/([a-z]+)/?$。 请注意，我没有使用\w的缩写。如果此版本可以在你的机器上正确运行，那么你不要使用正则表达式的缩写，要使用较长的当量（见上面的正则表达式节）。 执行流程详情      重写规则的执行流程比较简单，但不是完全明了。因此，我将叙述一下细节。这一切都开始于用于向你的服务器提出请求的时候。他们在浏览器地址栏中键入网址，他们的浏览器将之转换成一个HTTP请求并发送到服务器，Apache收到这一请求，并将之解析成片断。下面是一个例子：       请注意，每当我提到Apache的变量，我使用了一种奇怪的语法：％｛APACHE_VAR｝。这是因为它类似于mod_rewrite访问变量的语法。不过，括号内名字是重要的。       那么， mod_rewrites是如何工作的？如果你用的是.htaccess文件，那么你只需输入REMOTE_URI部分，但没有开始的斜线！我之前提到过这个，对大多数刚刚开始用它的人来说，这显得很混乱。如果你是将它添加到了全局配置文件里，那么你应当加上斜线。         为了说的更具体一点儿，下面是Apache的文档中对 mod_rewrite中“URL部分”的描述： 该模式始终是对请求的URL路径进行正则表达式匹配（主机名后面的那部分，但在任何以问号为标志的显示查询字符串的前面）。 Apache文档       为了消除大家的模糊不清的认识，下面用黄色高亮显示的两个网址是 mod_rewrite在.htaccess文件中的“部分网址”：       在本节接下来的部分我将利用这两个网址来描述执行的流程。我将把第一个网址称为“绿色”网址，第二个称为“蓝色”网址。在整个分析中，我还将使用“URL部分”来表示开始处没有斜线的REMOTE_URI。        对于那些想要100％的区分开这两中教法的人，我这里说的URL其实是URI。一个统一资源标识符（URI）的定义有别于统一资源定位符（URL）。一个 URI只是标识资源在哪里，这意味着存在多个URl可以指向相同的资源，但是他们是不同的地址。一个URI可能在找到资源之前经过了数次跳动和重定向。然而，URL却是标识资源的确切位置。这种细微的差别随着时间的推移，变得越来月模糊，以至于没有人关心它们的差异。我将继续使用术语URL，因为人们用它更舒服一些。        所以，现在我们知道重写规则将要采取行动了。一旦Apache已解析出请求，它就会将它翻译成它认为的文件，并去读取该文件。在这个过程中，他会搜索.htaccess文件。假设，.htaccess文件起用了RewriteEngine，那么任何重写规则都可以更改网址。地址的急剧变化（如 Apache将某个网址原来指向的目录替换为另外一个目录）将促发Apache发出子请求，进而获取新的文件。        在大多数情况下，你是可以看到子请求的。这些实现细节对于了解你写的或使用的大多数简单的重写规则来说并不重要。更重要的是知道Apache如何处理.htaccess文件中的重写规则。         .htaccess文件中的规则会以它们出现的顺序被处理。请注意，每个重写规则都是“部分网址”，也就是说类似于REMOTE_URI。当一个规则促发替换的时候，修改后的“部分网址”将被移交给下一个规则。这意味着，正在处理的网址可能已经被前面的规则修改过了，网址会被每个相匹配的规则更新。这一点很重要！         下面是一个流程图，它试图提供URL在通过含有多个规则的.htaccess文件时的执行过程：      请注意，流程图的顶部的将会与重写规则进行匹配的数据是“网址部分”，如果替换成功，则修改过的网址会与下一条规则继续匹配。        前面，我介绍了重写条件，但是没有详谈。每个重写过程都与一条重写规则相关联。条件出现在与它们有联系的规则之前，但是只有与规则相匹配了，网址才会得到评估。正如流程图所示，如果与一个重写规则相匹配了，Apache会检查这条规则有什么条件（即做出替换是否需要其他条件）。如果没有条件，那么将进行替代并进入下一步。如果需要条件，那么只有所有的条件都成立的时候，才会进行替换。举一个具体的例子。         我用的网址实际上是我放在"profile_example"目录中的源代码的一部分。这和前面的例子user.php一样，但现在有一个profile.php页面，一个附加的重写规则，和一个条件！让我们看一下这段代码和它在Apache中的执行过程：      这里有两个规则。规则＃1和我们前面看到的user例子一样。规则＃2是新加的，注意它有一个条件。在“网址部分”我们已经讨论过会从上到下遍历每一条规则。因此，必须先经过规则＃1，然后才是规则＃2。        理解这个例子的关键是首先要了解目标。在这个例子中，我允许友好网址，但实际上，我要明确地禁止直接访问PHP页面。请注意，有些人可能会说这是一个坏主意。他们可能会说，作为开发者，这个调试起来会更难。是这样的，事实上我不推荐做这样的小把戏，但是作为一个例子，这很好。更实际的使用 mod_rewrite的例子会在本教程后面的部分看到。         因此，在这一点的基础上，让我们看看我绿色网址发生了什么。这次，我们希望取得成功。       在最上面，可以看到Apache的THE_REQUEST变量。我把它放在上方是因为它不像我们要处理的其他Apache变量，在请求期间这个变量的值不会改变。这就是规则＃2使用％｛THE_REQUEST｝的原因之一。在THE_REQUEST下面，我们看到绿色的“网址部分”开始进入第一个规则了：  URL匹配成功。 没有任何条件，因此继续。 进行替换。 没有任何标志，因而继续。        通过第一条规则后，该网址已经更改。网址已被重写成了profile.php?id=joe，这时，Apache会听下来更新它的大多数变量。我们看不到?id=joe，新的“网址部分”会进入下一条规则。这是我们第一次遇到条件： URL匹配成功。 还有条件，我们将检查条件。 THE_REQUEST不包含profile.php，因此条件检查失败。 因为不满足条件，所以我们忽略替换和标志。 这条规则没有改变URL。       这一次，我们通过了所有的重写规则，并且 profile.php?id=joe 页会被正确的提取。            下面介绍关于如何执行蓝色的URL，这一次，我们要失败：     我再次将THE_REQUEST的值放在了最上面，蓝色的“网址部分”进入规则＃1：  URL匹配失败。 其他的一切都被忽略，网址没有改变，进入下一步。       第一个规则很容易。通常情况下，如果URL匹配失败，那么它会原样进入下一步。现在进入规则＃2：  URL匹配成功。 有条件需要比较，因此会先测试条件。 请求包含 profile.php，因此条件测试通过。 通过所有的条件，我们可以替换网址了。 ”-”是一个特殊的替换，这一为着任何东西都不会改变了。 规则中有标志，因此我们处理标志。 有一个F标志，意思是返回一个禁止访问响应。 一个403 Forbidden响应发送到了客户端。      有几件事情值得再重复一次。为了使替换发生，所有条件都必须检查通过。在上面这种情况下只有一个条件，并且检查通过了，所以，可以对网址进行替换。注意，有一种特殊的替换，不改变任何东西。当你想用标志做点儿什么的时候，这种方法相当有用，在这种情况下，我们就会这样做（指的是，替换后什么都不改变）。        下面是一个URL例子的分解和它们的返回值表： Profile.php 输入 匹配 获取 输出 结果 profile.php?id=joe Yes (#2)   profile.php?id=joe Forbidden profile/joe Yes (#1) joe profile.php?id=joe Good profile/joe/ Yes (#1) joe profile.php?id=joe Good profile/joe/x No   profile/joe/x Fail 语法       在介绍重写规则（RewriteRule）和重写条件（RewriteCond）的语法之前，我建议你先下载theAddedBytes Cheatsheet。这是因为cheatsheet表列出了最有用的服务器变量，标志，并有正则表达式技巧，甚至还有几个例子。在那里面有这么多的内容，将它们关联起来是很难的。        让我们从重写规则开始。如果你想做一些特殊的事，你可以随时查看Apache的关于重写规则的文档。下面是我的概述：      这个表显示了什么类型的标志是可用的。许多指南涵盖了flags的详细讲解，我会通过通过下面的例子介绍一下我认为的用的最多的flag。       下面是Apache的RewriteCond文档和我的概述： 调试流程      当你使用 mod_rewrite制定新规则的时候，总是以一个简单的规则开始，并且逐步发展为最后的版本。从来不要试图一下子将所有的事情办好。对于重写条件的编写，这个道理同样适用。一次添加规则和条件，多次测试！        我正在介绍的这种方法的关键之处是它可以让你知道是否你的一个改变不能正常工作或者是使某个地方运行不正常。当一次做得太多的时候，你会不可避免的遇到错误，并且你将不得不恢复你所做的一切更改来找出问题到底是出在那儿了。这是一项非常艰难的工作，可能会导致你的失望。不过，如果你总是稳步推进，并且在每一步都可以到达一个可以正常运行的点，你的处境就会稍好一点儿。       人们往往忽略这条建议，创建了一个复杂的规则，最终却不能工作。几个小时后，他们发现问题没有出现在复杂的部分，反而只是简单的正则表达式错误，如果他们按我上面解释的构造规则的换，问题可能早已经被发现了。在反向工程拆解规则上，这种方法也适用。这种做法将极大降低人们的失望！ 例子       在下面的例子中，我总是会假设网站的域名是example.com。此域名很重要，因为它会影响HTTP_HOST变量以及在你的网站上将指定的URL 重定向到另一个文件。如果你打算修改你的任何一个例子，以便它可以在你的网站上工作，请记住这一点。如果是这样，只需用你的域名替换 “example.com”。例如，Nettuts会将“example.com”改为“nettuts.com”。  删除www       这是最经典的重写规则。这将使得每个通过http://www.example.com访问你网站的人会得到一个硬性的重定向，从而其浏览器的地址栏中也将进行相应更新。  RewriteEngine on RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC] RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]      这条规则与任何输入的地址都匹配，并将所有的地址保存为$1。本例中的重要组成部分是条件语句，这个条件会检查HTTP_HOST变量，看它是否以“www”开始。如果是这样，重写就会发生： 替代的是一个完整的URL (它以http://开始) 替代中包含早期抓取的 $1。 [R=301]标志将浏览器重定向到重写过的网址，在某种意义上说，这是硬性重定向，它是浏览器加载新的页面，并用新的URL地址更新地址栏。 [L]标志的意思是这是最后需要分析的一条规则，重写引擎应该停止了。       如果传入的URL是“http://www.example.com/user/index.html”，那么HTTP_HOST是 beenwww.example.com，重写会创造http://example.com/user/index.html。        如果传入的URL是“http://example.com/user/index.html”，那么HTTP_HOST是beenexample.com，不满足条件，重写引擎将会保持网址不变。  禁止盗链       盗链，在维基百科中被称为内联链接，是用来描述一个网站读取另一个网站的内容。通常一个网站，读取者，将包括一些其他网站上的媒体文件的链接（让我们说成是一个图像或视频）——包含内容的主机。在这种情况下，内容主机的服务器会浪费带宽为其他网站提供内容（译者注：图像、视频等）。      对许多人来说，如果其他网站链接他们的内容，这很好。然而，许多人宁愿防止盗链，为了不支付将本网站内容发送到其他网站产生的额为的带宽。       最常见的、基本的防止盗链是的方法将一些网站加进空白页列表，并阻止其他的一切访问。你可以通过检查引用的内容来找出谁正在从你的网站访问那些内容。 HTTP_REFERER头（是的它是这样拼写的）是由正在访问资源的浏览器或客户端设置的。最后，这是不是100％可靠的，但它是禁止大多数盗链的最有效的方法。因此，你只需验证引用是否在空白页列表中。如果引用是不能接受的（空白或其他人的网站），那么你可以给他们发送禁止警告：  # 给盗链着发送403禁止访问警告。 RewriteEngine on RewriteCond %{HTTP_REFERER} !^http://example\.net/?.*$ [NC] RewriteCond %{HTTP_REFERER} !^http://example\.com/?.*$ [NC] RewriteRule \.(gif|jpe?g|png|bmp)$ - [F,NC]     在这里，RewriteRule检查的是任何一个主流类型的图像文件，例如的.gif,.png或.jpg。如果你想保护.flv,.swf或者是其他文件，你可以添加其他扩展到这个列表中。        被允许访问的域名是“example.net”和“example.com”，在这两种情况下，重写条件验证将失败，替代也不会发生。如果有任何其他域名尝试访问，比如说说“sample.com”企图访问，那么所有的重写条件会验证通过，替代会发生，比且[F]禁止动作将被触发。  给盗链者发送一张警告图片      当有人试图从你的服务器上读取内容时，前面的例子会返回404禁止访问警告。实际上，你可以更进一步，给盗链者发送你选择的任何资源。例如，您可以发送一个有用的以文字“盗链不允许”表述的图片警告。这样，其他人能够意识到他们自己的错误，并在他们的主机上保存一份副本。唯一的变化是改变替换方式，并提供一个已经选好的图片来代替正在被访问的资源：  # 重定向盗链者请求为 "warning.png" RewriteEngine on RewriteCond %{HTTP_REFERER} !^http://example\.net/?.*$ RewriteCond %{HTTP_REFERER} !^http://example\.com/?.*$ [NC] RewriteRule \.(gif|jpe?g|png|bmp)$ http://example.com/warning.png [R,NC]       注意，这是一个我称之为“硬”或“外部”重定向的例子。该重定向规则在他的替换部分有一个URL和一个[R］标志。  自定义404 错误     一个窍门：你可以用htaccess检查目前的“URL部分”是不是链接到服务器上的实际文件或Web目录，这是一个创建自定义404“文件未找到”页面的好方法。例如，如果用户试图读取特定目录中不存在的页面时，你可以重定向它们到任何网页，如Index页面或自定义404页。  # 显示“custom_404.html”页的通用404页 # 如果请求的页面不是一个文件或目录 #静态重定向：用户的地址栏的内容不变。 RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule .* custom_404.html [L]       这是 mod_rewrite文件测试的很好的例子。它同bash shell脚本、甚至是Perl脚本文件测试相似。这里的条件检查REQUEST_FILENAME是不是一个文件或目录。在都不是的情况下，则没有这样的文件反馈给这个请求。        如果传入的请求文件无法找到，那么返回一个“custom404.html”页面。注意有没有[R]标志，所以这是一个静态重定向，而不是硬重定向。用户的地址栏将不会改变，但网页的内容是“custom404.html”，简短而简单。  安全第一       如果你有经常使用的 mod_rewrite代码片段，并想轻松地分发到其他的服务器或环境中，你可能得要小心。如前所述，任何一个.htaccess文件的无效指令都可能会引起内部服务错误。因此，如果你的代码片段要移动到的环境没有mod_rewrite，你可以先暂停一下。        一个解决这个问题是 mod_rewrite模块的“检查“指令”，任何一个模块都有这个指令。只要将你的mod_rewrite代码放到<IfModule>块中，你可以这样设置：  <IfModule mod_rewrite.c> # Turn on RewriteEngine on # Always remove www (with a hard redirect) RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC] RewriteRule ^(.*)$ http://example.com/$1 [R=301,L] # Generic 404 for anyplace on the site # ... </IfModule> 结论        我希望本教程能够证明 mod_rewrite没有想象的那么恐怖，并且事实上通过精心设计，它的复杂性和访问速度问题都可以避免。