在IIS7.5中，设置伪静态是通过配置Web服务器的`web.config`文件来实现的。这个文件是基于XML格式的配置文件，用于定义应用程序的行为，包括URL重写规则，这正是创建伪静态的关键。以下是两种常用的方法：
### 方法一
第一种方法适用于全站伪静态，灵活性较高，只需将`web.config`文件放置在网站的根目录下，即可处理所有的伪静态请求。以下是该方法的配置代码：
```xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name="OrgPage" stopProcessing="true">
<match url="^(.*)$" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTP_HOST}" pattern="^(.*)$" />
<add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
<add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
</conditions>
<action type="Rewrite" url="index.php/{R:1}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
```
这段代码中，规则`<rule name="OrgPage">`定义了一个URL重写规则，它会捕获任何非文件、非目录的请求，并将其重写为`index.php/{R:1}`，其中`{R:1}`是URL匹配的部分。这种方法适用于所有URL，如ThinkPHP框架，以及其他类似结构的项目。
### 方法二
第二种方法更适合有多个子目录的网站，每个子目录可能需要不同的伪静态规则。以下是一个示例配置：
```xml
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<!-- 规则 1: includes 目录 -->
<rule name="规则 1" stopProcessing="true">
<match url="^includes/(.*)" />
<action type="Rewrite" url="includes/{R:1}" />
</rule>
<!-- 规则 2: blog 子目录下的 includes 目录 -->
<rule name="规则 2" stopProcessing="true">
<match url="^(blog)/includes/(.*)" />
<action type="Rewrite" url="{R:1}/includes/{R:2}" />
</rule>
<!-- 规则 3: blog 子目录下的 .html 结尾的 URL -->
<rule name="规则 3" stopProcessing="true">
<match url="^(blog)/(.*).html(.*)" />
<action type="Rewrite" url="{R:1}/index.php/{R:2}.html{R:3}" />
</rule>
<!-- 规则 4: 其他 .html 结尾的 URL -->
<rule name="规则 4" stopProcessing="true">
<match url="^(.*).html(.*)" />
<action type="Rewrite" url="index.php/{R:1}.html{R:2}" />
</rule>
</rules>
</rewrite>
</system.webServer>
</configuration>
```
这个配置包含了四个规则，分别处理不同的URL模式。例如，规则1和规则2处理包含`includes`目录的请求，规则3针对`blog`子目录下带有`.html`后缀的URL，而规则4则适用于其他所有`.html`结尾的URL。
### 补充说明
IIS 7及更高版本引入了URL重写模块，使得通过`web.config`配置伪静态成为可能。与之前的版本相比，这种方法更便于管理和维护，因为所有规则都集中在一个文件中。如果你的项目有特定的伪静态需求，可以通过调整`web.config`中的规则来适应。同时，确保正确安装并启用IIS的URL重写模块，否则这些规则不会生效。
选择哪种方法取决于你的项目结构和需求。如果只有一个简单的站点，且所有伪静态请求都可以用一个通用规则处理，那么方法一可能更合适。如果有多个子目录或需要特定的重写逻辑，方法二提供了更多的灵活性。在实际应用中，可能需要根据项目特性进行微调，以确保所有URL都能正确地被重写和处理。
