路由(Route)
Web开发中不可避免的要使用到URL。用得最多的，就是生成一个指向应用中其他某个页面的URL了。
开发者需要一个简洁的、集中的、统一的方法来完成这一过程。
否则的话，在代码中写入大量的诸如
http://www.digpage.com/post/view/100的代码，一是过于冗长，二是易出错且难排查，
三是日后修改起来容易有遗漏。因此，从开发角度来讲，需要一种更简洁、可以统一管理、又能排查错误的解决方案。
同时，我们在 :ref:install部分讲解了如何为Yii配置Web服务器，从中可以发现，
所有的用户请求都是发送给入口脚本index.php来处理的。那么，开发者需要一种高效的判断请求应当采用哪个
controller 哪个 action 进行处理的方法。
结合以上2点需求，Yii提供了路由和URL管理组件。
所谓路由是指URL中用于标识用于处理用户请求的module, controller, action的部分，一般情况下由r查询参数来指定。
如http://www.digpage.com/index.php?r=post/view&id=100，表示这个请求将由PostController 的 actionView来处理。
同时，Yii也提供了一种美化URL的功能，使得上面的URL可以用一个比较整洁、美观的形式表现出来，
如http://www.digpage.com/post/view/100。这个功能的实现是依赖于一个称为 urlManager 的应用组件。
使用 urlManager 开发者可以解析用户的请求，并指派相应的module, controller和action来进行处理，
还可以根据预义的路由规则，生成需要的URL返回给用户使用。
简而言之，urlManger具有解析请求以便确定指派谁来处理请求和根据路由规则生成URL 2个功能。
美化URL
一般情况下，Yii应用生成和接受形如http://www.digpage.com/index.php?r=post/view&id=100的URL。
这个URL分成几个部分：
- 表示主机信息的http://www.digapge.com
- 表示入口脚本的index.php
- 表示路由的r=post/view
- 表示普通查询参数的id=100
其中，主机信息部分从URL来讲，一般是不能少的。当然内部链接可以使用相对路径，这种情况下可以省略，
只是User Agent最终发出Request时，也是包含有主机信息的。
而入口脚本index.php我们知道，所有的请求都是要经过它来处理的。也就是说，所有的URL，其实都是指向他的。
那么我们可以通过默认把这个index.php从URL中去掉，反正指向他的、不是指向他的，都要交给他来处理。
其次，路由信息对于Yii应用而言也必不可少，表明应当使用哪个controller和action来处理请求，
否则Yii只能使用默认的路由来处理请求。这个形式比较固定，一般是module/controller/action形式。
看起来像路径吧？要是能使用路径就好了。那么，如果我们能够将上面的URL转换成
http://www.digpage.com/post/view?id=100，
省略了入口脚本，并将路由信息转换成路径，是不是看起来舒服很多？
这样的链接看起来简洁美观，对于用户比较友好。同时，也比较适合搜索引擎的胃口，据说是SEO的手段之一。
但到了这里还没完，对于查询参数id=100而言，这个URL请求的是编号为100的一个POST，并执行view操作。
那么我们可以再进一步改成http://www.digpage.com/post/view/100。这样是不是更爽？
有处女座的说了，这个编号100跟前面的字母们放一起显得另类呀，要是都是字母的就更好了。
假如所请求的是标题为Route的文章，那么不妨使用用http://www.digpage.com/post/view/Route。
这样的话，干脆再加上.html好了。
变成http://www.digpage.com/post/view/Route.html岂不是连处女座也满意了？
我们把 URLhttp://www.digpage.comindex.php?r=post/view&id=100变成
http://www.digpage.com/post/view/Route.html的过程就称为URL美化。
Yii有专门的yii\web\UrlManager来进行处理，其中：
- 隐藏入口脚本可以通过yii\web\UrlManager::showScriptName = false来实现
- 路由的路径化可以通过yii\web\UrlManager::enablePrettyUrl = true来实现
- 参数的路径化可以通过路由规则来实现
- 加入假后缀(fake suffix).html可以通过yii\web\UrlManager::suffix = '.html'来实现
这里点一点，有个印象就可以下，在 :ref:urlmanager部分就会讲到了。
路由规则
所谓孤掌难鸣，urlManager要发挥功能靠单打独斗是不行的，还要有另外一个的东东来配合。
这就是我们本篇要讲的：路由规则。
路由规则是指 urlManager 用于解析请求或生成URL的规则。
一个路由规则必须实现yii\web\UrlRuleInterface接口，这个接口定义了两个方法：
- 用于解析请求的yii\web\UrlRuleInterface::parseRequest()
- 用于生成URL的yii\web\UrlRuleInterface::createUrl()
Yii中，使用yii\web\UrlRule来表示路由规则，一般这个类是足够开发者使用的。
但是，如果开发者想自己实现解析请求或生成URL的逻辑，可以以这个类为基类进行派生，
并重载parseRuquest()和createUrl()。
以下是配置文件中urlManager组件的路由规则配置部分，以几个相对简单、典型的路由规则的为例，先有个感性认识::
'rules' => [
'posts' => 'post/index',
'post/<id:\d+>' => 'post/view',
'<controller:(post|comment)>/<id:\d+>/<action:(create|update|delete)>'
=> '<controller>/<action>',
'DELETE <controller:\w+>/<id:\d+>' => '<controller>/delete',
'http://<user:\w+>.digpage.com/<lang:\w+>/profile' => 'user/profile',
]
上面的例子并没有穷尽路由规则的例子，可以玩的花样还有很多。至于这些例子所表达的规则，
读者朋友们可以发挥想像去猜测，相信你们绝对可以猜个八九不离十。
目前不需要了解太多，只需大致了解数组的键相当于请求（需要解析的或将要生成的），而元素的值则是路由。
请求部分可称为pattern，路由部分则可称为route。对于这2个部分的形式，大致上可以这么看：
-
pattern 是从正则表达式变形而来。去除了两端的/#等分隔符。
特别注意别在pattern两端画蛇添足加上分隔符。 -
pattern 中可以使用正则表达式的命名参数，以供route部分引用。这个命名参数也是变形了的。
对于原来(?P<name>pattern)的命名参数，要变形成<name:pattern>。 - route 不应含有正则表达式，但是可以按<name>的形式引用命名参数。
至于具体实现过程，我们马上就会讲。
首先是yii\web\UrlRule的代码，让我们来大致看一看::
class UrlRule extends Object implements UrlRuleInterface
{
// 用于 $mode 表示路由规则的2种工作模式：仅用于解析请求和仅用于生成URL。
// 任意不为1或2的值均表示两种模式同时适用，
// 一般未设定或为0时即表示两种模式均适用。
const PARSING_ONLY = 1;
const CREATION_ONLY = 2;
// 路由规则名称
public $name;
// 用于解析请求或生成URL的模式，通常是正则表达式
public $pattern;
// 用于解析或创建URL时，处理主机信息的部分，如 http://www.digpage.com
public $host;
// 指向controller 和 action 的路由
public $route;
// 以一组键值对数组指定若干GET参数，在当前规则用于解析请求时，
// 这些GET参数会被注入到 $_GET 中去
public $defaults = [];
// 指定URL的后缀，通常是诸如 ".html" 等，
// 使得一个URL看起来好像指向一个静态页面。
// 如果这个值未设定，使用 UrlManager::suffix 的值。
public $suffix;
// 指定当前规则适用的HTTP方法，如 GET, POST, DELETE 等。
// 可以使用数组表示同时适用于多个方法。
// 如果未设定，表明当前规则适用于所有方法。
// 当然，这个属性仅在解析请求时有效，在生成URL时是无效的。
public $verb;
// 表明当前规则的工作模式，取值可以是 0, PARSING_ONLY, CREATION_ONLY。
// 未设定时等同于0。
public $mode;
// 表明URL中的参数是否需要进行url编码，默认是进行。
public $encodeParams = true;
// 用于生成新URL的模板
private $_template;
// 一个用于匹配路由部分的正则表达式，用于生成URL
private $_routeRule;
// 用于保存一组匹配参数的正则表达式，用于生成URL
private $_paramRules = [];
// 保存一组路由中使用的参数
private $_routeParams = [];
// 初始化
public function init() {...}
// 用于解析请求，由UrlRequestInterface接口要求
public function parseRequest($manager, $request) {...}
// 用于生成URL，由UrlRequestInterface接口要求
public function createUrl($manager, $route, $params) {...}
}
从上面代码看，UrlRule的属性（可配置项）比较多。各属性的意义在注释中已经写清楚了，这里就不再复述。
但是我们要着重分析一下初始化函数yii\web\UrlRule::init()，来加深对这些属性的理解::
public function init()
{
// 一个路由规则必定要有 pattern ，否则是没有意义的，
// 一个什么都没规定的规定，要来何用？
if ($this->pattern === null) {
throw new InvalidConfigException('UrlRule::pattern must be set.');
}
// 不指定规则匹配后所要指派的路由，Yii怎么知道将请求交给谁来处理？
// 不指定路由，Yii怎么知道这个规则可以为谁创建URL？
if ($this->route === null) {
throw new InvalidConfigException('UrlRule::route must be set.');
}
// 如果定义了一个或多个verb，说明规则仅适用于特定的HTTP方法。
// 既然是HTTP方法，那就要全部大写。
// verb的定义可以是字符串（单一的verb）或数组（单一或多个verb）。
if ($this->verb !== null) {
if (is_array($this->verb)) {
foreach ($this->verb as $i => $verb) {
$this->verb[$i] = strtoupper($verb);
}
} else {
$this->verb = [strtoupper($this->verb)];
}
}
// 若未指定规则的名称，那么使用最能区别于其他规则的 $pattern
// 作为规则的名称
if ($this->name === null) {
$this->name = $this->pattern;
}
// 删除 pattern 两端的 "/"，特别是重复的 "/"，
// 在写 pattern 时，虽然有正则的成分，但不需要在两端加上 "/"，
// 更不能加上 "#" 等其他分隔符
$this->pattern = trim($this->pattern, '/');
// 如果定义了 host ，将 host 部分加在 pattern 前面，作为新的 pattern
if ($this->host !== null) {
// 写入的host末尾如果已经包含有 "/" 则去掉，特别是重复的 "/"
$this->host = rtrim($this->host, '/');
$this->pattern = rtrim($this->host . '/' . $this->pattern, '/');
// 既未定义 host ，pattern 又是空的，那么 pattern 匹配任意字符串。
// 而基于这个pattern的，用于生成的URL的template就是空的，
// 意味着使用该规则生成所有URL都是空的。
// 后续也无需再作其他初始化工作了。
} elseif ($this->pattern === '') {
$this->_template = '';
$this->pattern = '#^$#u';
return;
// pattern 不是空串，且包含有 '://'，以此认定该pattern包含主机信息
} elseif (($pos = strpos($this->pattern, '://')) !== false) {
// 除 '://' 外，第一个 '/' 之前的内容就是主机信息
if (($pos2 = strpos($this->pattern, '/', $pos + 3)) !== false) {
$this->host = substr($this->pattern, 0, $pos2);
// '://' 后再无其他 '/'，那么整个 pattern 其实就是主机信息
} else {
$this->host = $this->pattern;
}
// pattern 不是空串，且不包含主机信息，两端加上 '/' ，形成一个正则
} else {
$this->pattern = '/' . $this->pattern . '/';
}
// route 也要去掉两头的 '/'
$this->route = trim($this->route, '/');
// 从这里往下，请结合流程图来看
// route 中含有 <参数> ，则将所有参数提取成 [参数 => <参数>]
// 存入 _routeParams[],
// 如 ['controller' => '<controller>', 'action' => '<action>'],
// 留意这里的短路判断，先使用 strpos()，快速排除无需使用正则的情况
if (strpos($this->route, '<') !== false &&
preg_match_all('/<(\w+)>/', $this->route, $matches)) {
foreach ($matches[1] as $name) {
$this->_routeParams[$name] = "<$name>";
}
}
// 这个 $tr[] 和 $tr2[] 用于字符串的转换
$tr = [
'.' => '\\.',
'*' => '\\*',
'$' => '\\$',
'[' => '\\[',
']' => '\\]',
'(' => '\\(',
')' => '\\)',
];
$tr2 = [];
// pattern 中含有 <参数名:参数pattern> ，
// 其中 ':参数pattern' 部分是可选的。
if (preg_match_all('/<(\w+):?([^>]+)?>/', $this->pattern, $matches,
PREG_OFFSET_CAPTURE | PREG_SET_ORDER)) {
foreach ($matches as $match) {
// 获取 “参数名”
$name = $match[1][0];
// 获取 “参数pattern” ，如果未指定，使用 '[^\/]' ，
// 表示匹配除 '/' 外的所有字符
$pattern = isset($match[2][0]) ? $match[2][0] : '[^\/]+';
// 如果 defaults[] 中有同名参数，
if (array_key_exists($name, $this->defaults)) {
// $match[0][0] 是整个 <参数名:参数pattern> 串
$length = strlen($match[0][0]);
$offset = $match[0][1];
// pattern 中 <参数名:参数pattern> 两头都有 '/'
if ($offset > 1 && $this->pattern[$offset - 1] === '/'
&& $this->pattern[$offset + $length] === '/') {
// 留意这个 (?P<name>pattern) 正则，这是一个命名分组。
// 仅冠以一个命名供后续引用，使用上与直接的 (pattern) 没有区别
// 见：http://php.net/manual/en/regexp.reference.subpatterns.php
$tr["/<$name>"] = "(/(?P<$name>$pattern))?";
} else {
$tr["<$name>"] = "(?P<$name>$pattern)?";
}
// defaults[]中没有同名参数
} else {
$tr["<$name>"] = "(?P<$name>$pattern)";
}
// routeParams[]中有同名参数
if (isset($this->_routeParams[$name])) {
$tr2["<$name>"] = "(?P<$name>$pattern)";
// routeParams[]中没有同名参数，则将 参数pattern 存入 _paramRules[] 中。
// 留意这里是怎么对 参数pattern 进行处理后再保存的。
} else {
$this->_paramRules[$name] = $pattern === '[^\/]+' ? '' :
"#^$pattern$#u";
}
}
}
// 将 pattern 中所有的 <参数名:参数pattern> 替换成 <参数名> 后作为 _template
$this->_template = preg_replace('/<(\w+):?([^>]+)?>/', '<$1>', $this->pattern);
// 将 _template 中的特殊字符及字符串使用 tr[] 进行转换，并作为最终的pattern
$this->pattern = '#^' . trim(strtr($this->_template, $tr), '/') . '$#u';
// 如果指定了 routePrams 还要使用 tr2[] 对 route 进行转换，
// 并作为最终的 _routeRule
if (!empty($this->_routeParams)) {
$this->_routeRule = '#^' . strtr($this->route, $tr2) . '$#u';
}
}
上面的代码难点在于pattern等的转换过程，有点翻来覆去，转换过去、转换回来的感觉，这里我们先放一放，
秋后再找他们来算帐，注意力先放在init()的前半部分，这些代码提醒我们：
- 规则的$pattern和$route是必须配置的。
- 规则的名称$name和主机信息$host在未配置的情况下，可以从$pattern来获取。
-
$pattern虽然含有正则的成分，但不需要在两端加入/，更不能使用#等其他分隔符。
Yii会自动为我们加上。 - 指定$pattern为空串，可以使该规则匹配任意的URL。此时基于该规则所生成的所有URL也都是空串。
-
$pattern中含有:\\时，Yii会认为其中包含了主机信息。此时就不应当再指定 host 。
否则，Yii会将 host 接在这个 pattern 前，作为新的pattern。这会造成该pattern 两段:\\，
而这显然不是我们要的。
接下来要啃稍硬点的骨头了，就是init()的后半段，
我们以一个普通的['post/<action:\w+>/<id:\d+>' => 'post/<action>']为例。
同时，我们假设这个路由规则默认有$defaults['id'] = 100，表示在未指定 post 的 id 时，
使用100作为默认的id。那么这个UrlRule的初始过程如 :ref:img-urlrule-init所示。
.. _img-urlrule-init:
.. figure:: _static/UrlRule_init.png
:alt: UrlRule路由规则初始化过程示意图
:height: 60em
UrlRule路由规则初始化过程示意图
后续的初始化过程具体如下：
0. 从['post/<action:\w+>/<id:\d+>' => 'post/<action>']，
我们有$pattern = '/post/<action:\w+>/<id:\d+>/'和
$route = 'post/<action>'。
. 首先从$route中提取出由< >所包含的部分。这里可以得到['action' => '<action>']。
将其存入$_routeParams[ ]中。
. 再从$pattern中提取出由< >所包含的部分，这里匹配2个部分，1个<action:\w+>
和1个<id\d+>。下面对这2个部分进行分别处理。
. 对于<action:\w+>由于$defaults[ ]中不存在下标为action的元素，于是向$tr[ ]
写入(?P<$name>$pattern)形式的元素，得到$tr['<action>'] = '(?P<$name>\w+)'。
而对于<id:\d+>，由于$defaults['id'] = 100，所以写入$tr[ ]的元素形式有所不同，
变成(/(?P<$name>$pattern))?。于是有$tr['<id>'] = (/(?P<$id>\d+))?。
. 由于在第1步只有$_routeParams['action'] = '<actoin>'，而没有下标为id的元素。
所以对于<action:\w+>，往tr2[ ]中写入['<action>' => '(?P<action>\w+)']，
而对于<id:\d+>则往$_paramRules[ ]中写入['id' => '#^\d+$#u']。
. 上面只是准备工作，接下来开始各种替换。首先将$pattern中所有<name:pattern>
替换成<name>并作为$_template。因此，$_template = '/post/<action>/<id>/'。
. 接下来用$tr[ ]对$_template进行替换，并在两端加上分隔符作为$pattern。
于是有$pattern = '#^post/(?P<action>\w+)(/(?P<id>\d+))?$#u'。
. 最后，由于第1步中$_routeParams不为空，所以需要使用$tr2[ ]对$route进行替换，
并在两端加上分隔符后，作为$_routeRule，于是有$_routeRule = '#^post/(?P<action>\w+)$#'。
这些替换的意义在于方便开发者以简洁的方式在配置文件中书写路由规则，然后将这些简洁的规则，
再替换成规范的正则表达式。让我们来看看这个init()的成果吧。仍然以上面的
['post/<action:\w+>/<id:\d+>' => 'post/<action>']为例，经过init()处理后，我们最终得到了::
$urlRule->route = 'post/<action>'; $urlRule->pattern = '#^post/(?P<action>\w+)(/(?P<id>\d+))?$#u'; $urlRule->_template = '/post/<action>/<id>/'; $urlRule->_routeRule = '#^post/(?P<action>\w+)$#'; $urlRule->_routeParams = ['action' => '<action>']; $urlRule->_paramRules = ['id' => '#^\d+$#u']; // $tr 和 $tr2 作为局部变量已经完成历史使命光荣退伍了
下面我们来讲讲 UrlRule 是如何创建和解析URL的。
创建URL
URL的创建就 UrlRule 层面来讲，是由yii\web\UrlRule::createUrl()负责的，
这个方法可以根据传入的路由和参数创建一个相应的URL来。具体代码如下::
public function createUrl($manager, $route, $params)
{
// 判断规则是否仅限于解析请求，而不适用于创建URL
if ($this->mode === self::PARSING_ONLY) {
return false;
}
$tr = [];
// 如果传入的路由与规则定义的路由不一致，
// 如 post/view 与 post/<action> 并不一致
if ($route !== $this->route) {
// 使用 $_routeRule 对 $route 作匹配测试
if ($this->_routeRule !== null && preg_match($this->_routeRule,
$route, $matches)) {
// 遍历所有的 _routeParams
foreach ($this->_routeParams as $name => $token) {
// 如果该路由规则提供了默认的路由参数，
// 且该参数值与传入的路由相同，则可以省略
if (isset($this->defaults[$name]) &&
strcmp($this->defaults[$name], $matches[$name]) === 0) {
$tr[$token] = '';
} else {
$tr[$token] = $matches[$name];
}
}
// 传入的路由完全不能匹配该规则，返回
} else {
return false;
}
}
// 遍历所有的默认参数
foreach ($this->defaults as $name => $value) {
// 如果默认参数是路由参数，如 <action>
if (isset($this->_routeParams[$name])) {
continue;
}
// 默认参数并非路由参数，那么看看传入的 $params 里是否提供该参数的值。
// 如果未提供，说明这个规则不适用，直接返回。
if (!isset($params[$name])) {
return false;
// 如果 $params 提供了该参数，且参数值一致，则 $params 可省略该参数
} elseif (strcmp($params[$name], $value) === 0) {
unset($params[$name]);
// 且如果有该参数的转换规则，也可置为空。等下一转换就消除了。
if (isset($this->_paramRules[$name])) {
$tr["<$name>"] = '';
}
// 如果 $params 提供了该参数，但又与默认参数值不一致，
// 且规则也未定义该参数的正则，那么规则无法处理这个参数。
} elseif (!isset($this->_paramRules[$name])) {
return false;
}
}
// 遍历所有的参数匹配规则
foreach ($this->_paramRules as $name => $rule) {
// 如果 $params 传入了同名参数，且该参数不是数组，且该参数匹配规则，
// 则使用该参数匹配规则作为转换规则，并从 $params 中去掉该参数
if (isset($params[$name]) && !is_array($params[$name])
&& ($rule === '' || preg_match($rule, $params[$name]))) {
$tr["<$name>"] = $this->encodeParams ?
urlencode($params[$name]) : $params[$name];
unset($params[$name]);
// 否则一旦没有设置该参数的默认值或 $params 提供了该参数，
// 说明规则又不匹配了
} elseif (!isset($this->defaults[$name]) || isset($params[$name])) {
return false;
}
}
// 使用 $tr 对 $_template 时行转换，并去除多余的 '/'
$url = trim(strtr($this->_template, $tr), '/');
// 将 $url 中的多个 '/' 变成一个
if ($this->host !== null) {
// 再短的 host 也不会短于 8
$pos = strpos($url, '/', 8);
if ($pos !== false) {
$url = substr($url, 0, $pos) . preg_replace('#/+#', '/',
substr($url, $pos));
}
} elseif (strpos($url, '//') !== false) {
$url = preg_replace('#/+#', '/', $url);
}
// 加上 .html 之类的假后缀
if ($url !== '') {
$url .= ($this->suffix === null ? $manager->suffix : $this->suffix);
}
// 加上查询参数们
if (!empty($params) && ($query = http_build_query($params)) !== '') {
$url .= '?' . $query;
}
return $url;
}
我们以上面提到['post/<action:\w+>/<id:\d+>' => 'post/<action>']路由规则来创建一个URL，
就假设要创建路由为post/view，id=100的URL吧。具体的流程如 :ref:img-urlrule-create所示。
.. _img-urlrule-create:
.. figure:: _static/UrlRule_create.png
:alt: UrlRule创建URL的流程示意图
:height: 60em
UrlRule创建URL的流程示意图
结合代码 :ref:img-urlrule-create，URL的创建过程大体上分4个阶段：
第一阶段
调用createUrl(Yii::$app->urlManager, 'post/view', ['id'=>101])。
传入的路由为post/view与规则定义的路由post/<action>不同。
但是，post/view可以匹配路由规则的$_routeRule = '#^post/(?P<action>\w+)$#'。
所以，认为该规则是适用的，可以接着处理。而如果连正则也匹配不上，那就说明该规则不适用，返回false。
遍历路由规则的所有$_routeParams，这个例子中，$_routeParams['action' => '<action>']。
这个我们称为路由参数规则，即出现在路由部分的参数。
对于这个路由参数规则，我们并未为其设置默认值。但实际使用中，有的时候可能会提供默认的路由参数，
比如对于形如post/index之类的，我们经常想省略掉index，那么就可以为<action>
提供一个默认值index。
对于有默认值的情况，我们的头脑要清醒，目前是要用路由规则来创建URL，
规则所定义的默认值并非意味着可以处理不提供这个路由参数值的路由，
而是说在处理路由参数值与默认值相等的路由时，最终生成的URL中可以省略该默认值。
即默认是体现在最终的URL上，是体现在URL解析过程中的默认，而不是体现在创建URL的过程中。
也就是说，对于post/index类的路由，如果默认index，则生成的URL中可以不带有index。
这里没有默认值，相对简单。由于$_routeRule正则中，使用了命名分组，即(?P<action>...)。
所以，可以很方便地使用$matches['action']来捕获\w+所匹配的部分，这里匹配的是view。
故写入$tr['<action>'] = view。
第二阶段
接下来遍历所有的默认参数，当然不包含路由参数部分，因为这个在前面已经处理过了。这里只处理余下的参数。
注意这个默认值的含义，如同我们前面提到的，这里是创建时必须提供，而生成出来的URL可以省略的意思。
因此，对于$params中未提供相应参数的，或提供了参数值但与默认值不一致，且规则没定义参数的正则的，
均说明规则不适用。
只有在$params提供相应参数，且参数值与默认值一致或匹配规则时方可进行后续处理。
这里我们有一个默认参数['id' => 100]。传入的$params['id'] => 100。两者一致，规则适用。
于将该参数从$params中删去。
接下来，看看是否为参数id定义了匹配规则。还真有$_paramRules['id'] => '#^\d+$#u'。
但这也用不上了，因为这是在创建URL，该参数与默认值一致，等下的id是要从URL中去除的。
因此，写入$tr['<id>'] = ''。
第三阶段
再接下来，就是遍历所有参数匹配规则$_paramRules了。对于这个例子，
只有$_paramRules = ['id' => '#^\d+$#u']。
如果$params中并未定义该id参数，那么这一步什么也不用做，因为没有东西要写到URL中去。
而一旦定义了id，那么就需要看看当前路由规则是否适用了。
判断的标准是所提供的参数不是数组，且匹配$_paramRules所定义的规则。
而如果$parasm['id']是数组，或不与规则匹配，或定义了id的参数规则却没有定义其默认值而
$params['id']又未提供，则规则不适用。
这里，我们在是在前面处理默认参数时，已经将id从$params中删去。
但判断到规则为id定义了默认值的，所以认为规则仍然适用。只是，这里实际上不用做任何处理。
如果需要处理的情况，也是将该参数从$params中删去，然后写入$tr['<id>'] = 100。
第四阶段
上面一切准备就绪之后，就可以着手生成URL了。主要用$tr对路由规则的$_template进行转换。
这里，$_template = '/post/<action>/<id>/'，因此，转换后再去除多余的/
就变成了$url = 'post/view'。其中id=100被省略掉了。
最后再分别接上.html的后缀和查询参数，一个URLpost/view.html就生成了。
其中，查询参数串是$params中剩下的内容，使用PHP的http_build_query( )生成的。
从创建URL的过程来看，重点是完成这么几项工作：
- 看规则是否适用，主要标准是路由与规则定义的是否匹配，规则通过默认值或正则所定义的参数，是否都提供了。
- 看看当前要创建的URL是否与规则定义的默认的路由参数和查询参数一致，对于一致的，可以省略。
- 看将这些与默认值一致的，规则已经定义了的参数从$params删除，余下的，转换成最终URL的查询参数串。
解析URL
说完了路由规则生成URL的过程，再来看看其逻辑上的逆过程，即URL的解析。
先从路由规则yii\web\UrlRule::parseRequest()的代码入手::
public function parseRequest($manager, $request)
{
// 当前路由规则仅限于创建URL，直接返回 false。
// 该方法返回false表示当前规则不适用于当前的URL。
if ($this->mode === self::CREATION_ONLY) {
return false;
}
// 如果规则定义了适用的HTTP方法，则要看当前请求采用的方法是否可以接受
if (!empty($this->verb) && !in_array($request->getMethod(),
$this->verb, true)) {
return false;
}
// 获取URL中入口脚本之后、查询参数 ? 号之前的全部内容，即为PATH_INFO
$pathInfo = $request->getPathInfo();
// 取得配置的 .html 等假后缀，留意 (string)null 转成空串
$suffix = (string) ($this->suffix === null ? $manager->suffix :
$this->suffix);
// 有假后缀且有PATH_INFO
if ($suffix !== '' && $pathInfo !== '') {
$n = strlen($suffix);
// 当前请求的 PATH_INFO 以该假后缀结尾，留意 -$n 的用法
if (substr_compare($pathInfo, $suffix, -$n, $n) === 0) {
$pathInfo = substr($pathInfo, 0, -$n);
// 整个PATH_INFO 仅包含一个假后缀，这是无效的。
if ($pathInfo === '') {
return false;
}
// 应用配置了假后缀，但是当前URL却不包含该后缀，返回false
} else {
return false;
}
}
// 规则定义了主机信息，即 http://www.digpage.com 之类，那要把主机信息接回去。
if ($this->host !== null) {
$pathInfo = strtolower($request->getHostInfo()) .
($pathInfo === '' ? '' : '/' . $pathInfo);
}
// 当前URL是否匹配规则，留意这个pattern是经过 init() 转换的
if (!preg_match($this->pattern, $pathInfo, $matches)) {
return false;
}
// 遍历规则定义的默认参数，如果当前URL中没有，则加入到 $matches 中待统一处理，
// 默认值在这里发挥作用了，虽然没有，但仍视为捕获到了。
foreach ($this->defaults as $name => $value) {
if (!isset($matches[$name]) || $matches[$name] === '') {
$matches[$name] = $value;
}
}
$params = $this->defaults;
$tr = [];
// 遍历所有匹配项，注意这个 $name 的由来是 (?P<name>...) 的功劳
foreach ($matches as $name => $value) {
// 如果是匹配一个路由参数
if (isset($this->_routeParams[$name])) {
$tr[$this->_routeParams[$name]] = $value;
unset($params[$name]);
// 如果是匹配一个查询参数
} elseif (isset($this->_paramRules[$name])) {
// 这里可能会覆盖掉 $defaults 定义的默认值
$params[$name] = $value;
}
}
// 使用 $tr 进行转换
if ($this->_routeRule !== null) {
$route = strtr($this->route, $tr);
} else {
$route = $this->route;
}
Yii::trace("Request parsed with URL rule: {$this->name}", __METHOD__);
return [$route, $params];
}
我们以http://www.digpage.com/post/view.html为例，来看看上面的代码是如何解析成路由
['post/view', ['id'=>100]]的。注意，这里我们仍然假设路由规则提供了id=100默认值。
而如果路由规则未提供该默认值，则请求形式要变成http://www.digapge.com/post/view/100.html。
同时，规则的$pattern也会不同::
// 未提供默认值，id 必须提供，否则匹配不上 $pattern = '#^post/(?P<action>\w+)/(?P<id>\d+)?$#u'; // 提供了默认值，id 可以不提供，照样可以匹配上 $pattern = '#^post/(?P<action>\w+)(/(?P<id>\d+))?$#u';
这个不同的原因在于UrlRule::init()，读者朋友们可以回头看看。
在讲URL的解析前，让我们先从请求的第一个经手人Web Server说起，在 :ref:install中讲到Web Server的配置时，
我们将所有未命中的请求转交给入口脚本来处理：
.. code-block:: nginx
location / {
try_files $uri $uri/ /index.php?$args;
}
# fastcgi.conf
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
以Nginx为例，try_files会依次尝试处理：
./post/view.html，这个如果真有一个也就罢了，但其实多半不存在。
./post/view.html/，这个目录一般也不存在。
./index.php，这个正是入口脚本，可以处理。至此，Nginx与Yii顺利交接。
由于请求最终交给入口脚本来处理，且我们隐藏了URL中入口脚本名，上述请求还原回来的话，
应该是http://www.digapge.com/index.php/post/view.html。
自然，这post/view.html就是PATH_INFO了。
有关PATH_INFO的更多知识，请看 :ref:web_request部分的内容。
好了，在Yii从Web Server取得控制权之后，就是我们大显身手的时候了。在解析过程中，UrlRule主要做了这么几件事：
- 通过 PATH_INFO 还原请求，如去除假后缀，开头接上主机信息等。还原后的请求为post/view。
-
看看当前请求是否匹配规则，这个匹配包含了主机、路由、参数等各方面的匹配。如不匹配，说明规则不适用，
返回false。在这个例子中，规则并未定义主机信息方面的规则，
规则中$pattern = '#^post/(?P<action>\w+)(/(?P<id>\d+))?$#u'。这与还原后的请求完全匹配。
如果URL没有使用默认值id = 100，如post/view/101.html，也是同样匹配的。 -
看看请求是否提供了规则已定义了默认值的所有参数，如果未提供，视为请求提供了这些参数，且他的值为默认值。
这里URL中并未提供id参数，所以，视为他提供了id = 100的参数。简单粗暴而有效。 -
使用规则定义的路由进行转换，生成新的路由。
再把上一步及当前所有参数作为路由的参数，共同组装成一个完整路由。
具体的转换流程可以看看 :ref:img-urlrule-parse。
.. _img-urlrule-parse:
.. figure:: _static/UrlRule_parse.png
:alt: UrlRule解析URL过程示意图
UrlRule路由规则解析URL的过程示意图
扫码二维码 获取免费视频学习资料
- 本文固定链接: http://phpxs.com/post/5387/
- 转载请注明：转载必须在正文中标注并保留原文链接
- 扫码： 扫上方二维码获取免费视频资料