YII 2.0中如何禁用自带的jquery? - 问答 - Yii Framework 中文社区
YII 2.0中如何禁用自带的jquery?
1552次浏览
悬赏 5 金钱
由于项目中自己手动引入了jquery 1.10版本的。可是在使用activeform的时候，总是会在最后又加载了一次YII自带的jquery 2版本，导致冲突
不知道有什么方法，可以默认禁止引用YII自带的Jquery，使用我自定义的jquery?
在assetManager里面添加下面几行即可！
'yii\web\JqueryAsset' =& [
'sourcePath' =& null,
'js' =& []
这个方法还挺不错的
暂时还未用到～留下脚印
mark一下~~什么时候遇到了回来膜拜。
摸索了一晚上，最终还是在官方手册中得到了方法，分享一下，方便后来的学习者。
其实很简单，只需要在assetManager里面添加下面几行即可！
'yii\web\JqueryAsset' =& [
'sourcePath' =& null,
'js' =& []
或者再变态一点，在JqueryAsset.php里面直接将Jquery.js给屏蔽掉。。当然不建议你修改源码！
这样修改之后，你会发现，项目每次加载的只有自己包含的jquery，不在末尾子自动包含YII自带的asset里面的jquery了。
共 1 条回复这个方法不错。感谢分享
找到AppAseest.php，里面有个
public $depends = [
'yii\web\YiiAsset',
'yii\bootstrap\BootstrapAsset',
在YiiAsset里面就引用了JQuery。
共 1 条回复谢啦,还非得10个字
您需要登录后才可以回答。 |
在 线201人Yii2.0 数据库查询_懒人程序
国外psd下载,php教程,jquery教程,jquery效果免费下载
Yii2.0 数据库查询
Yii2.0 数据库查询
User::find()-&all(); & &此方法返回所有数据；
& &User::findOne($id); & 此方法返回 主键 id=1 &的一条数据(举个例子)；
& &User::find()-&where(['name' =& '小伙儿'])-&one(); & 此方法返回 ['name' =& '小伙儿'] 的一条数据；
& &User::find()-&where(['name' =& '小伙儿'])-&all(); & 此方法返回 ['name' =& '小伙儿'] 的所有数据；
& &User::findBySql('SELECT * FROM user')-&all(); &此方法是用 sql &语句查询 user 表里面的所有数据；
& &User::findBySql('SELECT * FROM user')-&one(); &此方法是用 sql &语句查询 user 表里面的一条数据；
& &User::find()-&andWhere(['sex' =& '男', 'age' =& '24'])-&count('id'); & 统计符合条件的总条数；
& &User::find()-&one(); & &此方法返回一条数据；
& &User::find()-&all(); & &此方法返回所有数据；
& &User::find()-&count(); & &此方法返回记录的数量；
& &User::find()-&average(); & &此方法返回指定列的平均值；
& &User::find()-&min(); & &此方法返回指定列的最小值 ；
& &User::find()-&max(); & &此方法返回指定列的最大值 ；
& &User::find()-&scalar(); & &此方法返回值的第一行第一列的查询结果；
& &User::find()-&column(); & &此方法返回查询结果中的第一列的值；
& &User::find()-&exists(); & &此方法返回一个值指示是否包含查询结果的数据行；
& &User::find()-&batch(10); &每次取 10 条数据
& &User::find()-&each(10); &每次取 10 条数据， 迭代查询
看过本文的人还看过
支持键盘 ←　→相关热词搜索：数据库& Web应用Request
Web应用Request 前面
部分我们讲了用户请求的基础知识和命令行应用的Request，接下来继续讲Web应用的Request。 Web应用Request由 yii\web\Request 实现，这个类的代码将近1400行，主要是一些功能的封装罢了， 原理上没有很复杂的东西。只是涉及到许多HTTP的有关知识，读者朋友们可以自行查看相关的规范文档， 如
等。 同时，Yii大量引用了 $_SERVER ， 具体可以查看
， 此外，还涉及到PHP运行于不同的环境和模式下的一些细微差别。 这些内容比较细节，不影响大局，但是很影响理解，不过没关系，我们在涉及到的时候，会点一点。
请求的方法 根据
，HTTP的请求可以有：GET, POST, PUT等8种方法 (Request Method)。除了用不到的 CONNECT 外，Yii支持全部的HTTP请求方法。 要获取当前用户请求的方法，可以使用 yii\web\Request::getMethod()
19// 返回当前请求的方法，请留意方法名称是大小写敏感的，按规范应转换为大写字母
public function getMethod()
// $this-&methodParam 默认值为 '_method'
// 如果指定 $_POST['_method'] ，表示使用POST请求来模拟其他方法的请求。
// 此时 $_POST['_method'] 即为所模拟的请求类型。
if (isset($_POST[$this-&methodParam])) {
return strtoupper($_POST[$this-&methodParam]);
// 或者使用 $_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'] 的值作为方法名。
} elseif (isset($_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE'])) {
return strtoupper($_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE']);
// 或者使用 $_SERVER['REQUEST_METHOD'] 作为方法名，未指定时，默认为 GET 方法
return isset($_SERVER['REQUEST_METHOD']) ?
strtoupper($_SERVER['REQUEST_METHOD']) : 'GET';
这个方法使用了3种方法来获取当前用户的请求，优先级从高到低依次为：
当使用POST请求来模拟其他请求时，以 $_POST['_method'] 作为当前请求的方法； 否则，如果存在 X_HTTP_METHOD_OVERRIDE HTTP头时，以该HTTP头所指定的方法作为请求方法， 如 X-HTTP-Method-Override: PUT 表示该请求所要执行的是 PUT 方法； 如果 X_HTTP_METHOD_OVERRIDE 不存在，则以 REQUEST_METHOD 的值作为当前请求的方法。 如果连 REQUEST_METHOD 也不存在，则视该请求是一个 GET 请求。
前面两种方法，主要是针对一些只支持GET和POST等有限方法的User Agent而设计的。 其中第一种方法是从Ruby on Rails中借鉴过来的， 通过在发送POST请求时，加入一个 $_POST['_method'] 的隐藏字段，来表示所要模拟的方法， 如PUT，DELETE等。这样，就可以使得这些功能有限的User Agent也可以正常与服务器交互。 这种方法胜在简便，随手就来。 第二种方法则是使用 X_HTTP_METHOD_OVERRIDE HTTP头的办法来指定所使用的请求类型。 这种方法胜在直接明了，约定俗成，更为规范、合理。 至于 REQUEST_METHOD 是
所定义的环境变量， 专门用来表明当前请求方法的。上面的代码只是在未指定时默认为GET请求罢了。 当然，我们在开发过程中，其实并不怎么在乎当前的用户请求是什么类型的请求，我们更在乎是不是某一类型的请求。 比如，对于同一个URL地址 /post/123 ， 如果是正常的GET请求，应该是查看编号为123的文章的意思。 但是如果是一个DELETE请求，则是表示删除编号为123的文章的意思。我们在开发中，很可能就会这么写: 1
5if ($app-&request-&isDelete()){
$post-&delete();
$post-&view();
上面的代码只是一个示意，与实际编码是有一定出入的，主要看判断分支的用法。 就是判断请求是否是某一特定类型的请求。这些判断在实际开发中，是很常用的。 于是Yii为我们封装了许多方法专门用于执行这些判断：
getIsAjax() 是否是AJAX请求，这其实不是HTTP请求方法，但是实际使用上，这个是用得最多的。 getIsDelete() 是否是DELETE请求 getIsFlash() 是否是Adobe Flash 或 Adobe Flex 发出的请求，这其实也不是HTTP请求方法。 getIsGet() 是否是一个GET请求 getIsHead() 是否是一个HEAD请求 getIsOptions() 是否是一个OPTIONS请求 getIsPatch() 是否是PATCH请求 getIsPjax() 是否是一个PJAX请求，这也并非是HTTP请求方法。 getIsPost() 是否是一个POST请求 getIsPut() 是否是一个PUT请求
上面10个方法请留意其中有3个并未是HTTP请求方法，主要是用于特定HTTP请求类型（AJAX、Flash、PJAX）的判断。 除了这3个之外的其余7个方法，正好对应于HTTP 1.1 协议定义的7个方法。 而CONNECT方法由于Web开发在用不到，主要用于HTTP代理， 因此，Yii也就没有为其设计一个所谓的 isConnect() 了，这是无用功。 上面的10个方法，再加一开始说的 getMehtod() 一共是11个方法，按照我们在
部分所说的， 这相当于定义了11个只读属性。我们以其中几个为例，看看具体实现:
29// 这个SO EASY，啥也不说了，Yii实现的7个HTTP方法都是这个路子。
public function getIsOptions()
// 注意在getMethod()时，输出的是全部大写的字符串
return $this-&getMethod() === 'OPTIONS';
// AJAX请求是通过 X_REQUESTED_WITH 消息头来判断的
public function getIsAjax()
// 注意这里的XMLHttpRequest没有全部大写
return isset($_SERVER['HTTP_X_REQUESTED_WITH']) &&
$_SERVER['HTTP_X_REQUESTED_WITH'] === 'XMLHttpRequest';
// PJAX请求是AJAX请求的一种，增加了X_PJAX消息头的定义
public function getIsPjax()
return $this-&getIsAjax() && !empty($_SERVER['HTTP_X_PJAX']);
// HTTP_USER_AGENT消息头中包含 'Shockwave' 或 'Flash' 字眼的（不区分大小写），
// 就认为是FLASH请求
public function getIsFlash()
return isset($_SERVER['HTTP_USER_AGENT'])
&& (stripos($_SERVER['HTTP_USER_AGENT'], 'Shockwave') !== false
|| stripos($_SERVER['HTTP_USER_AGENT'], 'Flash') !== false);
上面提到的AJAX、PJAX、FLASH请求比较特殊，并非是HTTP协议所规定的请求类型，但是在实现中是会使用到的。 比如，对于一个请求，在非AJAX时，需要整个页面返回给客户端，而在AJAX请求时，只需要返回页面片段即可。 这些特殊请求是通过特殊的消息头实现的，具体的可以自行搜索相关的定义和规范。 至于那7个HTTP方法的判断，摆明了是同一个路子，换瓶不换酒， getMethod() 前人栽树，他们后人乘凉。
请求的参数 在实际开发中，开发者如果需要引用request，最常见的情况是为了获取请求参数，以便作相应处理。 PHP有众所周知的 $_GET 和 $_POST 等。相应地，Yii提供了一系列的方法用于获取请求参数:
106// 用于获取GET参数，可以指定参数名和默认值
public function get($name = null, $defaultValue = null)
if ($name === null) {
return $this-&getQueryParams();
return $this-&getQueryParam($name, $defaultValue);
// 用于获取所有的GET参数
// 所有的GET参数保存在 $_GET 或 $this-&_queryParams 中。
public function getQueryParams()
if ($this-&_queryParams === null) {
// 请留意这里并未使用 $this-&_queryParams = $_GET 进行缓存。
// 说明一旦指定了 $_queryParams 则 $_GET 会失效。
return $_GET;
return $this-&_queryParams;
// 根据参数名获取单一的GET参数，不存在时，返回指定的默认值
public function getQueryParam($name, $defaultValue = null)
$params = $this-&getQueryParams();
return isset($params[$name]) ? $params[$name] : $defaultValue;
// 类以于get()，用于获取POST参数，也可以指定参数名和默认值
public function post($name = null, $defaultValue = null)
if ($name === null) {
return $this-&getBodyParams();
return $this-&getBodyParam($name, $defaultValue);
// 根据参数名获取单一的POST参数，不存在时，返回指定的默认值
public function getBodyParam($name, $defaultValue = null)
$params = $this-&getBodyParams();
return isset($params[$name]) ? $params[$name] : $defaultValue;
// 获取所有POST参数，所有POST参数保存在 $this-&_bodyParams 中
public function getBodyParams()
if ($this-&_bodyParams === null) {
// 如果是使用 POST 请求模拟其他请求的
if (isset($_POST[$this-&methodParam])) {
$this-&_bodyParams = $_POST;
// 将 $_POST['_method'] 删掉，剩余的$_POST就是了
unset($this-&_bodyParams[$this-&methodParam]);
return $this-&_bodyParams;
// 获取Content Type
// 对于 'application/ charset=UTF-8'，得到的是 'application/json'
$contentType = $this-&getContentType();
if (($pos = strpos($contentType, ';')) !== false) {
$contentType = substr($contentType, 0, $pos);
// 根据Content Type 选择相应的解析器对请求体进行解析
if (isset($this-&parsers[$contentType])) {
// 创建解析器实例
$parser = Yii::createObject($this-&parsers[$contentType]);
if (!($parser instanceof RequestParserInterface)) {
throw new InvalidConfigException(
&The '$contentType' request parser is invalid.
It must implement the yii\\web\\RequestParserInterface.&);
// 将请求体解析到 $this-&_bodyParams
$this-&_bodyParams = $parser-&parse($this-&getRawBody(), $contentType);
// 如果没有与Content Type对应的解析器，使用通用解析器
} elseif (isset($this-&parsers['*'])) {
$parser = Yii::createObject($this-&parsers['*']);
if (!($parser instanceof RequestParserInterface)) {
throw new InvalidConfigException(
&The fallback request parser is invalid.
It must implement the yii\\web\\RequestParserInterface.&);
$this-&_bodyParams = $parser-&parse($this-&getRawBody(),
$contentType);
// 连通用解析器也没有
// 看看是不是POST请求，如果是，PHP已经将请求参数放到$_POST中了，直接用就OK了
} elseif ($this-&getMethod() === 'POST') {
$this-&_bodyParams = $_POST;
// 以上情况都不是，那就使用PHP的 mb_parse_str() 进行解析
$this-&_bodyParams = [];
mb_parse_str($this-&getRawBody(), $this-&_bodyParams);
return $this-&_bodyParams;
在上面的代码中，将所有的请求参数划分为两类， 一类是包含在URL中的，称为查询参数（Query Parameter），或GET参数。 另一类是包含在请求体中的，需要根据请求体的内容类型（Content Type）进行解析，称为POST参数。 其中， get() , getQueryParams() 和 getQueryParam() 用于获取查询参数：
get() 用于获取GET参数，可以指定所要获取的特定参数的参数名，在这个参数名不存在时，可以指定默认值。 当不指定参数名时，获取所有的GET参数。 具体功能是由下面2个函数来实现的。 getQueryParams() 用于获取所有的GET参数。 这些参数的内容，保存在 $_GET 或 $this-&_queryParams 中。优先使用 $this-&_queryParams 的。 getQueryParam() 对应于 get() 用于获取特定的GET参数的情况。
而 post() , getPostParams() 和 getPostParam() 用于获取POST参数：
post() 与 get() 类似，可以指定所要获取的特定参数的参数名，在这个参数名不存在时，可以指定默认值。 当不指定参数名时，获取所有的POST参数。 具体功能是由下面2个函数来实现的。 getPostParam() 用于通过参数名获取特定的POST参数，需要调用 getPostParams() 获取所有的POST参数。 getPostParams() 用于获取所有的POST参数。
上面稍微复杂点的，可能就是 getPostParams() 了，我们就稍稍剖析下Yii是怎么解析POST参数的。 先讲讲这个方法所涉及到的一些东东：内容类型、请求解析器、请求体。
内容类型（Content-Type） 在 getPostParams() 中，需要先获取请求体的内容类型，然后采用相应的解析器对内容进行解析。 获取内容类型，使用 getContentType()
10public function getContentType()
if (isset($_SERVER[&CONTENT_TYPE&])) {
return $_SERVER[&CONTENT_TYPE&];
} elseif (isset($_SERVER[&HTTP_CONTENT_TYPE&])) {
return $_SERVER[&HTTP_CONTENT_TYPE&];
return null;
， 内容类型由 CONTENT_TYPE 环境变量来表示。 而根据
， 内容类型则是放在 CONTENT_TYPE 头部中，然后由PHP赋值给 $_SERVER['HTTP_CONTENT_TYPE'] 。 这里一般没有冲突，因此发现哪个用哪个，就怕客户端没有给出（这种情况返回 null ）。
请求解析器 在 getPostParams() 中，根据不同的Content Type 创建了相应的内容解析器对请求体进行解析。 yii\web\Request 使用成员变量 public $parsers 来保存一系列的解析器。 这个变量在配置时进行指定: 1
6'request' =& [
'parsers' =& [
'application/json' =& 'yii\web\JsonParser',
$parsers 是一个数组，数组的键是Content Type，如 applicaion/json 之类。 而数组的值则是对应于特定Content Type 的解析器，如 yii\web\JsonParser 。 这也是Yii实现的唯一一个现成的Parser，其他Content-Type，需要开发者自己写了。 而且，可以以 * 为键指定一个解析器。那么该解析器将在一个Content Type找不到任何匹配的解析器后被使用。 yii\web\JsonParser 其实很简单:
28namespace yii\web;
use yii\base\InvalidParamException;
use yii\helpers\Json;
// 所有的解析器都要实现 RequestParserInterface
// 这个接口也只是要求实现 parse() 方法
class JsonParser implements RequestParserInterface
public $asArray = true;
public $throwException = true;
// 具体实现 parse()
public function parse($rawBody, $contentType)
return Json::decode($rawBody, $this-&asArray);
} catch (InvalidParamException $e) {
if ($this-&throwException) {
throw new BadRequestHttpException(
'Invalid JSON data in request body: '
. $e-&getMessage(), 0, $e);
return null;
这里使用 yii\helpers\Json::decode() 对请求体进行解析。这个 yii\helpers\Json 是个辅助类， 专门用于处理JSON格式数据。具体的内容我们这里就不做讲解了，只需要了解这里可以将JSON格式数据解析出来就OK了， 学有余力的读者朋友可以自己看看代码。
请求体 在 yii\web\Reqeust::getBodyParams() 和 yii\web\RequestParserInterface::parse() 中， 我们可以看到，需要将请求体传入 parse() 进行解析，且请求体由 yii\web\Request::getRawBody() 可得。 yii\web\Request::getRawBody(): 1
8public function getRawBody()
if ($this-&_rawBody === null) {
$this-&_rawBody = file_get_contents('php://input');
return $this-&_rawBody;
这个方法使用了 php://input 来获取请求体，这个 php://input 有这么几个特点：
php://input 是个只读流，用于获取请求体。 php://input 是返回整个HTTP请求中，除去HTTP头部的全部原始内容， 而不管是什么Content Type（或称为编码方式）。 相比较之下， $_POST 只支持 application/x-www-form-urlencoded 和 multipart/form-data-encoded 两种Content Type。其中前一种就是简单的HTML表单以 method=&post& 提交时的形式， 后一种主要是用于上传文档。因此，对于诸如 application/json 等Content Type，这往往是在AJAX场景下使用， 那么使用 $_POST 得到的是空的内容，这时就必须使用 php://input 。 相比较于 $HTTP_RAW_POST_DATA ， php://input 无需额外地在php.ini中 激活 always-populate-raw-post-data ，而且对于内存的压力也比较小。 当编码方式为 multipart/form-data-encoded 时， php://input 是无效的。这种情况一般为上传文档。 这种情况可以使用传统的 $_FILES 或者 yii\web\UploadedFile 。
请求的头部 yii\web\Request 使用一个成员变量 private $_headers 来存储请求头。 而这个 $_header 其实是一个 yii\web\HeaderCollection ，这是一个集合类的基本数据结构， 实现了SPL的 IteratorAggregate , ArrayAccess 和 Countable 等接口。 因此，这个集合可以进行迭代、像数组一样进行访问、可被用于 conut() 函数等。 这个数据结构相对简单，我们就不展开占用篇幅了。我们要讲的是怎么获取请求的头部。 这个是由 yii\web\Request::getHeaders() 来实现的:
40public function getHeaders()
if ($this-&_headers === null) {
// 实例化为一个HeaderCollection
$this-&_headers = new HeaderCollection;
// 使用 getallheaders() 获取请求头部，以数组形式返回
if (function_exists('getallheaders')) {
$headers = getallheaders();
// 使用 http_get_request_headers() 获取请求头部，以数组形式返回
} elseif (function_exists('http_get_request_headers')) {
$headers = http_get_request_headers();
// 使用 $_SERVER 数组获取头部
foreach ($_SERVER as $name =& $value) {
// 针对所有 $_SERVER['HTTP_*'] 元素
if (strncmp($name, 'HTTP_', 5) === 0) {
// 将 HTTP_HEADER_NAME 转换成 Header-Name 的形式
$name = str_replace(' ', '-',
ucwords(strtolower(str_replace('_', ' ',
substr($name, 5)))));
$this-&_headers-&add($name, $value);
return $this-&_headers;
// 将数组形式的请求头部变成集合的元素
foreach ($headers as $name =& $value) {
$this-&_headers-&add($name, $value);
return $this-&_headers;
这里用3种方法来尝试获取请求的头部：
getallheaders() ，这个方法仅在将PHP作为Apache的一个模块运行时有效。 http_get_request_headers() ，要求PHP启用HTTP扩展。 $_SERVER 数组的方法，需要遍历整个数组，并将所有以 HTTP_* 元素加入到集合中去。 并且，要将所有 HTTP_HEADER_NAME 转换成 Header-Name 的形式。
就是根据不同的PHP环境，采用有效的方法来获取请求头部，如此而已。
请求的解析 我们前面就说过了，无论是命令行应用还是Web应用，他们的请求都要实现接口要求的 resolve() ， 以便明确这个用户请求的路由和参数。下面就是 yii\web\Request::resolve() 的代码:
15public function resolve()
// 使用urlManager来解析请求
$result = Yii::$app-&getUrlManager()-&parseRequest($this);
if ($result !== false) {
list ($route, $params) = $result;
// 将解析出来的参数与 $_GET 参数进行合并
$_GET = array_merge($_GET, $params);
return [$route, $_GET];
throw new NotFoundHttpException(Yii::t('yii', 'Page not found.'));
看着很简单吧？这才几行，还没有 getBodyParams() 的代码多呢。 虽然简单，但是有一个细节我们要留意，就是在解析出路由信息和参数的时候， 会把参数的内容加入到 $_GET 中去，这是合理的。 比如，对于 /post/view/100 这个 100 在路由规则中，其实定义为一个 参数。其原始的形式应当是 /index.php?r=post/view&id=100 。你说该 不该把 id = 100 重新写回 $_GET 去？至于路由规则的内容，可以看看
的内 容。 从这个 resolve() 是看不出来解析过程的复杂的，这个 yii\web\Request::resolve() 是个没担当的家伙，他把解析过程推给了 urlManager。 那我们就顺藤摸瓜，一睹这个 yii\web\UrlManager::parseRequest() 吧:
67public function parseRequest($request)
// 启用了 enablePrettyUrl 的情况
if ($this-&enablePrettyUrl) {
// 获取路径信息
$pathInfo = $request-&getPathInfo();
// 依次使用所有路由规则来解析当前请求
// 一旦有一个规则适用，后面的规则就没有被调用的机会了
foreach ($this-&rules as $rule) {
if (($result = $rule-&parseRequest($this, $request)) !== false) {
return $result;
// 所有路由规则都不适用，又启用了 enableStrictParsing ，
// 那只能返回 false
if ($this-&enableStrictParsing) {
return false;
// 所有路由规则都不适用，幸好还没启用 enableStrictParing，
// 那就用默认的解析逻辑
Yii::trace(
'No matching URL rules. Using default URL parsing logic.',
__METHOD__);
// 配置时所定义的fake suffix，诸如 &.html& 等
$suffix = (string) $this-&suffix;
if ($suffix !== '' && $pathInfo !== '') {
// 这个分支的作用在于确保 $pathInfo 不能仅仅是包含一个 &.html&。
$n = strlen($this-&suffix);
// 留意这个 -$n 的用法
if (substr_compare($pathInfo, $this-&suffix, -$n, $n) === 0) {
$pathInfo = substr($pathInfo, 0, -$n);
// 仅包含 &.html& 的$pathInfo要之何用？掐死算了。
if ($pathInfo === '') {
return false;
// 后缀没匹配上
return false;
return [$pathInfo, []];
// 没有启用 enablePrettyUrl的情况，那就更简单了，
// 直接使用默认的解析逻辑就OK了
Yii::trace(
'Pretty URL not enabled. Using default URL parsing logic.',
__METHOD__);
$route = $request-&getQueryParam($this-&routeParam, '');
if (is_array($route)) {
$route = '';
return [(string) $route, []];
从上面代码中可以看到，urlManager是按这么一个顺序来解析用户请求的：
先判断是否启用了 enablePrettyUrl，如果没启用，所有的路由和参数信息都在URL的查询参数中， 很简单就可以处理了。 通常都会启用 enablePrettyUrl，由于路由和参数信息部分或全部变成了URL路径。 经过了美化，使得URL看起来更友好，但化妆品总是比清水芙蓉要烧银子，解析起来就有点费功夫了。 既然路由和参数信息变成了URL路径，那么就先从URL路径下手获取路径信息。 然后依次使用已经定义好的路由规则对当前请求进行解析，一旦有一个规则适用， 后续的路由规则就不会起作用了。 然后再对配置的 .html 等fake suffix进行处理。
这一过程中，有两个重点，一个是获取路径信息，另一个就是使用路由规则对请求进行解析。下面我们依次进行讲解。
获取路径信息 在大多数情况下，我们还是会启用 enablePrettyUrl 的，特别是在产品环境下。那么从上面的代码来看， yii\web\Request::getPathInfo() 的调用就不可避免。其实涉及到获取路径信息的方法有很多， 都在 yii\web\Request 中，这里暴露出来的，只是一个 getPathInfo() ，相关的方法有:
65// 这个方法其实是调用 resolvePathInfo() 来获取路径信息的
public function getPathInfo()
if ($this-&_pathInfo === null) {
$this-&_pathInfo = $this-&resolvePathInfo();
return $this-&_pathInfo;
// 这个才是重点
protected function resolvePathInfo()
// 这个 getUrl() 调用的是 resolveRequestUri() 来获取当前的URL
$pathInfo = $this-&getUrl();
// 去除URL中的查询参数部分，即 ? 及之后的内容
if (($pos = strpos($pathInfo, '?')) !== false) {
$pathInfo = substr($pathInfo, 0, $pos);
// 使用PHP urldecode() 进行解码，所有 %## 转成对应的字符， + 转成空格
$pathInfo = urldecode($pathInfo);
// 这个正则列举了各种编码方式，通过排除这些编码，来确认是 UTF-8 编码
// 出处可参考 http://w3.org/International/questions/qa-forms-utf-8.html
if (!preg_match('%^(?:
[\x09\x0A\x0D\x20-\x7E]
| [\xC2-\xDF][\x80-\xBF]
# non-overlong 2-byte
| \xE0[\xA0-\xBF][\x80-\xBF]
# excluding overlongs
| [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}
# straight 3-byte
| \xED[\x80-\x9F][\x80-\xBF]
# excluding surrogates
| \xF0[\x90-\xBF][\x80-\xBF]{2}
# planes 1-3
| [\xF1-\xF3][\x80-\xBF]{3}
# planes 4-15
| \xF4[\x80-\x8F][\x80-\xBF]{2}
# plane 16
)*$%xs', $pathInfo)
$pathInfo = utf8_encode($pathInfo);
// 获取当前脚本的URL
$scriptUrl = $this-&getScriptUrl();
// 获取Base URL
$baseUrl = $this-&getBaseUrl();
if (strpos($pathInfo, $scriptUrl) === 0) {
$pathInfo = substr($pathInfo, strlen($scriptUrl));
} elseif ($baseUrl === '' || strpos($pathInfo, $baseUrl) === 0) {
$pathInfo = substr($pathInfo, strlen($baseUrl));
} elseif (isset($_SERVER['PHP_SELF']) && strpos($_SERVER['PHP_SELF'],
$scriptUrl) === 0) {
$pathInfo = substr($_SERVER['PHP_SELF'], strlen($scriptUrl));
throw new InvalidConfigException(
'Unable to determine the path info of the current request.');
// 去除 $pathInfo 前的 '/'
if ($pathInfo[0] === '/') {
$pathInfo = substr($pathInfo, 1);
return (string) $pathInfo;
从 resolvePathInfo() 来看，需要调用到的方法有 getUrl() resolveRequestUri() getScriptUrl() getBaseUrl() 等，这些都是与路径信息密切相关的，让我们分别都看一看。
Request URI yii\web\Request::getUrl() 用于获取Request URI的，实际上这只是一个属性的封装， 实质的代码是在 yii\web\Request::resolveRequestUri() 中:
44// 这个其实调用的是 resolveRequestUri() 来获取当前URL
public function getUrl()
if ($this-&_url === null) {
$this-&_url = $this-&resolveRequestUri();
return $this-&_url;
// 这个方法用于获取当前URL的URI部分，即主机或主机名之后的内容，包括查询参数。
// 这个方法参考了 Zend Framework 1 的部分代码，通过各种环境下的HTTP头来获取URI。
// 返回值为 $_SERVER['REQUEST_URI'] 或 $_SERVER['HTTP_X_REWRITE_URL']，
// 或 $_SERVER['ORIG_PATH_INFO'] + $_SERVER['QUERY_STRING']。
// 即，对于 /index.html?helloworld，
// 得到URI为 index.html?helloworld
protected function resolveRequestUri()
// 使用了开启了ISAPI_Rewrite的IIS
if (isset($_SERVER['HTTP_X_REWRITE_URL'])) {
$requestUri = $_SERVER['HTTP_X_REWRITE_URL'];
// 一般情况，需要去掉URL中的协议、主机、端口等内容
} elseif (isset($_SERVER['REQUEST_URI'])) {
$requestUri = $_SERVER['REQUEST_URI'];
// 如果URI不为空或以'/'打头，则去除 http:// 或 https:// 直到第一个 /
if ($requestUri !== '' && $requestUri[0] !== '/') {
$requestUri = preg_replace('/^(http|https):\/\/[^\/]+/i',
'', $requestUri);
// IIS 5.0， PHP以CGI方式运行，需要把查询参数接上
} elseif (isset($_SERVER['ORIG_PATH_INFO'])) {
$requestUri = $_SERVER['ORIG_PATH_INFO'];
if (!empty($_SERVER['QUERY_STRING'])) {
$requestUri .= '?' . $_SERVER['QUERY_STRING'];
throw new InvalidConfigException('Unable to determine the request URI.');
return $requestUri;
从上面的代码我们可以知道，Yii针对不同的环境下，PHP的不同表现形式，通过一些分支判断， 给出一个统一的路径名或文件名。 辛辛苦苦那么多，其实就是为了消除不同环境对于开发的影响，使开发者可以更加专注于核心工作。 其实，作为一个开发框架，无论是哪种语言、用于哪个领域， 都需要为开发者提供在各种环境下的都表现一致的编程界面。 这也是开发者可以放心使用的基础条件，如果在使用框架之后， 开发者仍需要考虑各种环境下会怎么样怎么样，那么这个框架注定短命。 这里有必要点一点涉及到的几个 $_SERVER 变量。这里面提到的，读者朋友可以自行阅读
， 也可以看看
REQUEST_URI 由HTTP 1.1 协议定义，指访问某个页面的URI，去除开头的协议、主机、端口等信息。 如 :8080/index.php/foo/bar?queryParams ， REQUEST_URI为 /index.php/foo/bar?queryParams 。 X-REWRITE-URL 当使用以开启了ISAPI_Rewrite 的IIS作为服务器时，ISAPI_Rewrite会在未对原始URI作任何修改前， 将原始的 REQUEST_URI 以 X-REWRITE-URL HTTP头保存起来。 PATH_INFO CGI 1.1 规范所定义的环境变量。 从形式上看， :8080/index.php&/PATH_INFO&?queryParams 。 它是整个URI中，在脚本标识之后、查询参数 ? 之前的部分。 对于Apache，需要设置 AcceptPathInfo On ，且在一个URL没有 &/PATH_INFO& 部分的时候， PATH_INFO 无效。特殊的情况，如 /index.php/ ， PATH_INFO 为 / 。 而对于Nginx，则需要设置：
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_param PATH_INFO $fastcgi_path_info;
ORIG_PATH_INFO 在PHP文档中对它的解释语焉不详，“指未经PHP处理过的原始的PATH_INFO”。 这个在Apache和Nginx需要配置一番才行，但一般用不到，已经有PATH_INFO可以用了嘛。而在IIS中则有点怪， 对于 /index.php/ ORIG_PATH_INFO 为 /index.php/ ； 对于 /index.php ORIG_PATH_INFO 为 /index.php 。
根据上面这些背景知识，再来看 resolveRequestUri() 就简单了：
最广泛的情况，应当是使用 REQUEST_URI 来获取。但是 resolveRequestUri() 却先使用 X-REWRITE-URL， 这是为了防止REQUEST_URI被rewrite。 其次才是使用 REQUEST_URI，这对于绝大多数情况是完全够用的了。 但REQUEST_URI毕竟只是规范的要求，Web服务器很有可能店大欺客、另立山头，我们又不是第一次碰见了是吧？ 所以，Yii使用了平时比较少用到的ORIG_PATH_INFO。 最后，按照规范要求进行规范化，该去头的去头，该续尾的续尾。去除主机信息段和查询参数段后， 就大功告成了。
入口脚本路径 yii\web\Request::getScriptUrl() 用于获取入口脚本的相对路径，也涉及到不同环境下PHP的不同表现。 我们还是先从代码入手:
34// 这个方法用于获取当前入口脚本的相对路径
public function getScriptUrl()
if ($this-&_scriptUrl === null) {
// $this-&getScriptFile() 用的是 $_SERVER['SCRIPT_FILENAME']
$scriptFile = $this-&getScriptFile();
$scriptName = basename($scriptFile);
// 下面的这些判断分支代码，为各主流PHP framework所用，
// Yii, Zend, Symfony等都是大同小异。
if (basename($_SERVER['SCRIPT_NAME']) === $scriptName) {
$this-&_scriptUrl = $_SERVER['SCRIPT_NAME'];
} elseif (basename($_SERVER['PHP_SELF']) === $scriptName) {
$this-&_scriptUrl = $_SERVER['PHP_SELF'];
} elseif (isset($_SERVER['ORIG_SCRIPT_NAME']) &&
basename($_SERVER['ORIG_SCRIPT_NAME']) === $scriptName) {
$this-&_scriptUrl = $_SERVER['ORIG_SCRIPT_NAME'];
} elseif (($pos = strpos($_SERVER['PHP_SELF'], '/' . $scriptName))
!== false) {
$this-&_scriptUrl = substr($_SERVER['SCRIPT_NAME'], 0, $pos)
. '/' . $scriptName;
} elseif (!empty($_SERVER['DOCUMENT_ROOT'])
&& strpos($scriptFile, $_SERVER['DOCUMENT_ROOT']) === 0) {
$this-&_scriptUrl = str_replace('\\', '/',
str_replace($_SERVER['DOCUMENT_ROOT'], '', $scriptFile));
throw new InvalidConfigException(
'Unable to determine the entry script URL.');
return $this-&_scriptUrl;
上面的代码涉及到了一些环境问题，点一点，大家了解下就OK了：
SCRIPT_FILENAME 当前脚本的实际物理路径，比如 /var//frontend/web/index.php ， 或WIN平台的 D:\\frontend\web\index.php 。 以Nginx为例，一般情况下，SCRIPT_FILENAME有以下配置项：
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
# 使用 document root 来得到物理路径
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name
SCRIPT_NAME CGI 1.1 规范所定义的环境变量，用于标识CGI脚本（而非脚本的输出）， 如 /path/index.php 中的 /path/index.php 。 仍以Nginx为例，SCRIPT_NAME一般情况下有 fastcgi_param SCRIPT_NAME $fastcgi_script_name 的设置。 绝大多数情况下，使用 SCRIPT_NAME 即可获取当前脚本。 PHP_SELF PHP_SELF 是PHP自己实现的一个 $_SERVER 变量，是相对于文档根目录（document root）而言的。 对于 /path/index.php?queryParams ，PHP_SELF 为 /path/index.php 。 一般SCRIPT_NAME 与 PHP_SELF 无异。但是，在 PHP.INI 中，如 cgi.fix_pathinfo=1 （默认即为1）时， 对于形如 /path/index.php/post/view/123 ， 则PHP_SELF 为 /path/index.php/post/view/123 。 而根据 CGI 1.1 规范，SCRIPT_NAME 仅为 /path/index.php ，至于剩余的 /post/view/123 则为PATH_INFO。 ORIG_SCRIPT_NAME 当PHP以CGI模式运行时，默认会对一些环境变量进行调整。 首当其冲的，就是 SCRIPT_NAME 的内容会变成 php.cgi 等二进制文件，而不再是CGI脚本文件。 当然，设置 cgi.fix_pathinfo=0 可以关闭这一默认行为。但这导致的副作用比较大，影响范围过大，不宜使用。 但天无绝人之路，九死之地总留一线生机，那就是ORIG_SCRIPT_NAME，他保留了调整前 SCRIPT_NAME 的内容。 也就是说，在CGI模式下，可以使用 ORIG_SCRIPT_NAME 来获取想要的SCRIPT_NAME。 请留意使用 ORIG_SCRIPT_NAME 前一定要先确认它是否存在。
交待完这些背景知识后，我们再来看看 yii\web\Request::getScriptUrl() 的逻辑：
先调用 yii\web\Request::getScriptFile() ， 通过 basename($_SERVER['SCRIPT_FILENAME']) 获取脚本文件名。一般都是我们的入口脚本 index.php 。
绝大多数情况下， base($_SERVER('SCRIPT_NAME')) 是与第一步获取的 index.php 相同的。 如果这样的话，则认为这个 SCRIPT_NAME 就是我们所要的脚本URL。 这也是规范的定义。但是既然称为规范，说明并非是事实。 事实是由Web服务器来实现的，也就是说Web服务器可能进行修改。 另外，对于运行于CGI模式的PHP而言，使用 SCRIPT_NAME 也无法获得脚本名。
那么我们转而向PHP_SELF求助，这个是PHP内部实现的，不受Web服务器的影响。一般这个PHP_SELF也是可堪一用的， 但也不是放之四海而皆准，对于带有PATH_INFO的URI， basename() 获取的并不是脚本名。
于是我们再转向 ORIG_SCRIPT_NAME 求助，如果PHP是运行于CGI模式，那么就可行。
再不成功，可能PHP并非运行于CGI模式（否则第4步就可以成功），且URI中带有PATH_INFO（否则第二步就可以成功）。 对于这种情形，PHP_SELF的前面一截就是我们要的脚本URL 。
万一以上情况都不符合，说明当前PHP运行的环境诡异莫测。 那只能寄希望于将 SCRIPT_FILENAME 中前面那截可能是Document Root的部分去掉，余下的作为脚本URL了。 前提是要有Document Root，且SCRIPT_FILENAME前面的部分可以匹配上。
Base Url 获取路径信息的最后一个相关方法，就是 yii\web\Request::getBaseUrl():
10// 获取Base Url
public function getBaseUrl()
if ($this-&_baseUrl === null) {
// 用上面的脚本路径的父目录，再去除末尾的 \ 和 /
$this-&_baseUrl = rtrim(dirname($this-&getScriptUrl()), '\\/');
return $this-&_baseUrl;
这个Base Url很简单，相信聪明如你肯定一目了然，我就不浪费篇幅了。 好了，上面就是 yii\web\Request::resolve() 中有关获取路径信息的内容。 下一步就是使用路由规则去解析当前请求了。
使用路由规则解析 上面这么多有关从请求获取路径信息的内容，其实只完成了请求解析的第一步而已。 接下来，urlManager就要遍历所有的路由规则来解析当前请求，直到有一个规则适用为止。 路由规则层面对于请求的解析，我们在
部分已经讲得很清楚了。}