简体   繁体   English

htaccess 中重写规则 apache 中 ^ 与 ^.*$ 之间的区别

[英]difference between ^ vs ^.*$ in Rewrite rule apache in htaccess

What is the difference between ^ vs ^.*$ in the third line of both the expressions.两个表达式的第三行中的^^.*$有什么区别。 Are they same or different from each other它们是相同的还是不同的

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.+)/$
RewriteRule ^  %1 [L,R=301]

and

 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteCond %{REQUEST_URI} (.+)/$
 RewriteRule ^.*$  %1 [L,R=301]

The net result in these two examples is the same, but they are technically different and ^ is more efficient in this case.这两个示例中的最终结果是相同的,但它们在技术上有所不同,并且^在这种情况下更有效。

In both of these rules you simply need the RewriteRule directive to be successful for everything and both regex achieve that.在这两个规则中,您只需要RewriteRule指令对所有事情都成功,并且两个正则表达式都可以实现。

^ - This regex simply asserts the start-of-string anchor, so it is successful for everything, but matches nothing. ^ - 这个正则表达式只是断言字符串开始的锚点,所以它对一切都是成功的,但什么都不匹配。 (The $0 backreference is empty.) $0反向引用为空。)

UPDATE: For example, given a request for /abc , then the approx steps involved are:更新:例如,给定/abc的请求,那么所涉及的大约步骤是:

  1. ^ asserts the start of the URL-path. ^断言 URL 路径的开始。
  2. No more symbols in the regex.正则表达式中不再有符号。 The regex is successful.正则表达式成功。 Nothing has been matched in the requested URL-path.请求的 URL 路径中没有任何匹配项。 The $0 backreference is empty. $0反向引用为空。 DONE完毕

^.*$ - This regex matches anything and everything, so it is successful for everything and matches everything . ^.*$ - 这个正则表达式匹配任何东西,所以它对所有东西都是成功的,并且匹配所有东西 Since it actually matches everything , the $0 backreference stores the entire URL-path that is matched.由于它实际上匹配了所有内容,因此$0反向引用存储了匹配的整个 URL 路径。 If you simply need to be successful then this is less efficient as it traverses the entire URL-path.如果您只需要成功,那么效率会降低,因为它会遍历整个 URL 路径。 Incidentally, this is the same as simply .* because regex is greedy by default.顺便说一句,这与简单的.*相同,因为正则表达式默认是贪婪的。

UPDATE: For example, given a request for /abc , then the approx steps involved are:更新:例如,给定/abc的请求,那么所涉及的大约步骤是:

  1. ^ asserts the start of the URL-path. ^断言 URL 路径的开始。
  2. . matches a in abc .匹配abca
  3. * quantifier repeats the previous match 0 or more times (greedy). *量词重复上一个匹配 0 次或更多次(贪婪)。
  4. . matches b in abc .匹配abc中的b
  5. * quantifier repeats the previous match 0 or more times (greedy). *量词重复上一个匹配 0 次或更多次(贪婪)。
  6. . matches c in abc .匹配abc中的c
  7. * quantifier repeats the previous match 0 or more times (greedy). *量词重复上一个匹配 0 次或更多次(贪婪)。
  8. . does not match anything (fails) since we have reached the end of the URL-path.不匹配任何内容(失败),因为我们已到达 URL 路径的末尾。
  9. $ asserts the end of the URL-path. $断言 URL 路径的结尾。
  10. No more symbols in the regex.正则表达式中不再有符号。 The regex is successful.正则表达式成功。 The entire URL-path has been matched by traversing through the URL-path.整个 URL 路径已通过遍历 URL 路径进行匹配。 The $0 backreference contains the entire URL-path. $0反向引用包含整个 URL 路径。 DONE完毕

However...然而...

 RewriteCond %{REQUEST_FILENAME}.-d RewriteCond %{REQUEST_URI} (,+)/$ RewriteRule ^ %1 [L,R=301]

This could actually be made more efficient since the 2nd RewriteCond directive is not required.这实际上可以提高效率,因为不需要第二个RewriteCond指令。 This check should be made in the RewriteRule pattern instead, to avoid a filesystem check on every request, not just requests that end in a slash (which is all that's required).这种检查应该在RewriteRule模式中进行,以避免对每个请求进行文件系统检查,而不仅仅是以斜杠结尾的请求(这就是所有需要的)。 For example:例如:

RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.+)/$ /$1 [L,R=301]

The RewriteRule pattern is processed first, before any of the conditions, so you should do as much processing here as possible. RewriteRule模式首先被处理,在任何条件之前,所以你应该在这里做尽可能多的处理。 Note the addition of the slash prefix on the substitution string, which is missing from the $1 backreference.请注意在替换字符串上添加了斜杠前缀, $1反向引用中缺少该前缀。 (The slash is otherwise part of the %1 backreference - as you used previously - because the REQUEST_URI server variable starts with a slash.) (斜杠是%1反向引用的一部分 - 正如您之前使用的那样 - 因为REQUEST_URI服务器变量以斜杠开头。)

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM