版权声明：本文为博主原创文章，未经博主允许不得转载。
 UrlRewrite地址重写后，用户得到的全部都是经过处理后的URL地址。
 一、它的主要优点
 1.1、提高安全性，可以有效的避免一些参数名、ID等完全暴露在用户面前，如果用户随便乱输的话，不符合规则的话直接会返回个404或错误页面，这比直接返回500或一大堆服务器错误信息要好的多。
 1.2、美化URL，去除了那些比如*.do、*action之类的后缀名、长长的参数串等，可以自己组织精简更能反映访问模块内容的URL。
 1.3、更有利于搜索引擎的收入，通过对URL的一些优化，可以使搜索引擎更好的识别与收录网站的信息。
 二、UrlRewrite使用范围
 地址重写一般是用于将动态地址伪静态，如果已经是静态页面路径那就没有必要用此技术了。
 三、 使用方法
 3.1、下载并引用urlrewrite.jar，如果是maven管理jar的话可直接 拷贝如下代码：
 
 <dependency>
       <groupId>org.tuckey</groupId>
       <artifactId>urlrewritefilter</artifactId>
       <version>4.0.3</version>
 </dependency>
 
3.2、配置web.xml文件，即在web.xml文件中添加如下代码：
 
  <filter>
        <filter-name>UrlRewriteFilter</filter-name>
        <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
        <init-param>
            <param-name>confReloadCheckInterval</param-name>
            <param-value>60</param-value>
        </init-param>
        <!--自定义配置文件的路径,是相对context的路径,(默认位置 /WEB-INF/urlrewrite.xml) -->
        <init-param>
            <param-name>confPath</param-name>
            <param-value>/WEB-INF/urlrewrite.xml</param-value>
        </init-param>
        
   <!--设置日志级别（将被记录到日志中） 可以为: TRACE, DEBUG, INFO (default), WARN, ERROR, FATAL, log4j, commons, slf4j,比如 sysout:DEBUG（设置到控制台调试输出级别） (默认级别 WARN) -->
        <init-param>
            <param-name>logLevel</param-name>
            <param-value>DEBUG</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>UrlRewriteFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
    </filter-mapping>
 
3.3 、配置urlrewrite.xml文件 ，具体的配置方法如下所示
 
<urlrewrite>
    <rule>
        <from>/login.html</from>  
        <to>/loginController.do?login</to> 
    </rule>
</urlrewrite>
 
其中from是Urlrewrite地址重写后的路径，to是实际访问路径。如果想以参数为伪静态页面的名称的话，则可以通过以下配置
 
<rule>
        <from>^/login/(.*).html</from>
        <to>/loginController.do?login&amp;parameter=$1</to> 
</rule>
 
如果parameter的值为user001的话，那么重写后的路径则为/login/user001.html。

       我们在web项目开发中，难免会遇到URL中参数名、ID等完全暴露在用户面前，如果用户随便乱输的话，对系统的安全性造成威胁。这时，我们便会用到 UrlRewrite。
 
       UrlRewrite就是我们通常说的地址重写，用户得到的全部都是经过处理后的URL地址。地址重写一般是用于将动态地址伪静态。如果本身就是静态就没必要了。地址重写后网站制作者可以通过输入地址名直接访问。
 
       使用地址重写不仅可以提高安全性，可以有效的避免一些参数名、ID等完全暴露在用户面前，如果用户随便乱输的话，不符合规则的话直接会返回个404或错误页面，这比直接返回500或一大堆服务器错误信息要好的多，而且可以美化URL，去除了那些比如*.do之类的后缀名、长长的参数串等，可以自己组织精简更能反映访问模块内容的URL，更有利于搜索引擎的收入，通过对URL的一些优化，可以使搜索引擎更好的识别与收录网站的信息。
 
接下来是使用实例：
 
1、首先需在项目的lib文件夹中加入urlrewrite-3.2.0.jar包
 
2、在web.xml中声明Filter
 
 
<filter>
        <filter-name>UrlRewriteFilter</filter-name>
        <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>UrlRewriteFilter</filter-name>
        <url-pattern>/*</url-pattern>
        <dispatcher>REQUEST</dispatcher>
        <dispatcher>FORWARD</dispatcher>
    </filter-mapping>

 
 
3、声明完filter后，需要在WEB-INF目录下新建一个urlrewrite.xml文件并在urlrewrite.xml添加规则
 
 
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite
PUBLIC "-//tuckey.org//DTD UrlRewrite 3.0//EN"
"http://tuckey.org/res/dtds/urlrewrite3.0.dtd">
<urlrewrite>    
   
  <rule>
       <from>^/demo/(\w+).html$</from>
       <to type="redirect">/Struts/$1</to>
</rule>
</urlrewrite>
rule 是urlrewrite下的子节点，是urlrewrite的主要规则节点，在它里面包含from 和to两个子节点，from表示请求的URL，to表示将转到的真实的URL。关于from，UrlRewrite有两种匹配的模式，一种是正则表达式匹配，一种的通配符匹配，如上就是正则表达式匹配。当进行匹配的时候，匹配部分的正则可以被提取为参数进行传递。

 
 

 
 

 

 
 
做伪静态的好处有哪些? 
 
 
 
 
1.最主要的是为了搜索引擎方便搜索引擎蜘蛛(Spider)来抓取主页上的相关内容; 
 
 
 
 
2.提高用户对主页的信任度; 、
 
 
 
 
3.影响网站在搜索引擎的排名中
 
 
现在主流的项目都在使用SpringMVC了，今天就结合SpringMVC和UrlRewrite来实现URL地址的重写，实现伪静态
 
 
首先我们要导入UrlRewrite的所需 Jar包，这里使用Maven方式导入：在pom.xml中添加以下代码
 
 

 
<!-- URL Rewrite -->
<dependency>
    <groupId>org.tuckey</groupId>
    <artifactId>urlrewritefilter</artifactId>
    <version>4.0.4</version>
</dependency>
 
 下面要在web.xml 把UrlRewriteFilter的过滤器添加进去，用于哪些请求是要进行静态化处理的，哪些不需要，同时要注意web.xml 文件中filter的加载顺序。
 
 
 

 
<filter>
　　<filter-name>UrlRewriteFilter</filter-name>
　　<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
　　<!-- 因为urlrewrite.xml只能在web-inf下，所以我们这里可以省略掉urlrewrite.xml的路径配置。 -->
　　<init-param>
　　　　<param-name>logLevel</param-name>
　　　　<param-value>WARN</param-value>
　　</init-param>
</filter>
　　<filter-mapping>
　　<filter-name>UrlRewriteFilter</filter-name>
　　<url-pattern>/*</url-pattern>
　　<dispatcher>REQUEST</dispatcher>
　　<dispatcher>FORWARD</dispatcher>
</filter-mapping>


 
 最后我们要定义一个urlrewirte.xml文件，将文件放在WEB-INF目录下（如果放在其他文件下，则需要修改加载地址，建议直接放在WEB-INF下）。
 
 
 

 
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN" "\\urlrewrite3.2.dtd">
  
<urlrewrite>
  
    <rule>
    <note>科室、专家、就医指南、互动留言、人员招聘、其他</note>
    <note>example:/news/zjtd</note>
    <from>/news/([A-Za-z0-9]+).html</from>
    <to type="forward">/news/$1</to>
  </rule>
  
  <rule>
    <note>科室详情</note>
    <note>example：/index.action</note>
    <from>/dept/([0-9]+).html</from>
    <to type="forward">/dept/$1</to>
  </rule>
  
  <rule>
    <note>新闻资讯列表</note>
    <note>example:/news/jyzn/gzsj</note>
    <from>/news/([A-Za-z0-9]+)/([A-Za-z0-9]+).html</from>
    <to type="forward">/news/$1/$2</to>
  </rule>
  
  <rule>
    <note>新闻资讯列表详情</note>
    <note>example:/news/jyzn/gzsj/19</note>
    <from>/news/([A-Za-z0-9]+)/([A-Za-z0-9]+)/([0-9]+).html</from>
    <to type="forward">/news/$1/$2/$3</to>
  </rule>
   
  
</urlrewrite>
 
 这里我们看到 form里面的表达式可以是正则表达式，这样配置会更加灵活，但是请把尽量精确的url放在前面，因为这个匹配规则是从上往下依次匹配，如果
 
 
 
匹配了，则下面不在匹配，所以使用的时候，一定要先精确然后模糊匹配。
 
 

 <rule>：自定义匹配规则
 <note>：注释，解释标签
 <from>：定义具体的匹配规则
 <to>：匹配成功后的目标地址
 <to type="">：type的值有两个，一个是 forward (转发,参数不丢失)，一个是 redirect (重定向,地址栏显示的地址就是目标真实地址)
 
 
 
</rule>
 

URL重写
 
在前后端分离的开发模式中，会遇到这样一个需求：前端通过特定路由前缀来访问后端接口，例如：http://localhost/api/getUser，这里 api 即是每一个前端 request 所多加的前缀。nginx 需要把http://localhost/api/getUser 转换成后端的访问端口及路由，例如：http://localhost:8080/getUser，从而访问服务。
 
这里就涉及到一个URL重写的的概念，可以使用多种方式来实现，那么这里由于前端程序时通过 webpack 打包后，将静态文件发布在 nginx 上，所以我们需要通过 nginx 的 rewirte 指令来进行 URL 的重写。
 
location匹配规则
 
在使用 rewirte 指令前，我们需要先熟悉 location 匹配规则。
 这里只涉及一般会用到的语法：
 
= 开头精准匹配，停止搜索并立即处理请求
 
例：
	location = /login {  
	   #规则A  
	}  
	location / {  
	   #规则B 
	}  
	http://localhost/login 将匹配规则A
	http://localhost/register 则匹配规则B
 
~ 区分大小写匹配(可用正则表达式)
~* 不区分大小写匹配(可用正则表达式)
 
	location ~ \.(gif|jpg|png|js|css)$ {  
	   #规则D  
	}  
	location ~* \.png$ {  
	   #规则E  
	} 
	http://localhost/a.PNG 则匹配规则E，
	不会匹配规则D，因为规则E不区分大小写
 
!~ 区分大小写不匹配
!~* 不区分大小写不匹配
^~ 如果路径中匹配，那么不测试正则表达式
 
rewrite 使用规则
 
nginx-rewirte 使用语法：
 
	rewrite regex replacement [flag]; 
 
参数介绍
 
regex ：可以使用正则或者字符串来表示相匹配的地址。
replacement：可以表示重定向的地址。
flag：指令集，匹配后续动作。取值 
  
last、break：目前看来，作用类似，都是重写后停止处理重写其他指令。
redirect：如果替换字符串不以“ http://”，“ https://”或“ $scheme” 开头，返回带有302代码的临时重定向，浏览器地址会显示跳转后的URL地址。
permanent：返回301代码的永久重定向，浏览器地址栏会显示跳转后的URL地址。
 
 
使用示例
 例如，现在将 http://localhost/api/getUser 请求转发到 http://localhost:8080/getUser，配置如下：
 
        location ^~ /api/ {
                rewrite  ^/api/(.*)$ /$1 break;
                proxy_pass http://localhost:8080;
        }

 
location 匹配：路由中匹配到 /api/ 即执行规则。
 正则：以 /api/ 开始，子表达式匹配任意多单字符，结束。
 
tips
 
react（umi）页面刷新404，配置
 
try_files  $uri $uri/ /index.html;
 
参考文献
 
https://www.cnblogs.com/dalaoyang/p/10264919.html