我能让我的 htaccess 更干净、更优化吗？
这是我的 .htaccess 感觉它的方式很长并且可以变得更高效。我目前遇到的问题是，由于配置文件视图和 vcard 视图重写中这些规则的顺序，目前不起作用。我发现，根据我放置这些 RewriteRules 的顺序，它会影响其他规则的行为。如果你问我的话，这有点像一场噩梦。
我的网站结构并不复杂。我有 3 个 PHP 页面，每个页面使用 $_GET 值处理项目的不同操作，以检查人员是否处于正确的位置并使用正确的参数。我遇到的问题是建立友好链接，以便人们可以使用熟悉的 url 路径访问图像或其他内容。
嗯，就是这样，哦耶。另外，我有一个动态 RewriteRule 模板，当我想使用选项或设置时，我可以使用最后 2 个占位符来放入我的数据。
# Options:
# -MultiViews: Turns off multiviews so it doesn't interfer with our rewrite rules
# -Indexes: Stop directory listings
# +FollowSymlinks: Let out rewrite rules work
Options -MultiViews -Indexes +FollowSymlinks
RewriteEngine On
RewriteBase /
# Error page
# Force add trainling slash
RewriteCond %{REQUEST_URI} !(\.[a-zA-Z0-9]{1,5}|/)$
RewriteRule (.*)$ http://foo.bar/$1/ [R=301,L]
# Prepent www if not exist in URI
RewriteCond %{HTTP_HOST} ^foo\.bar$
RewriteRule (.*) http://www.foo.bar/$1 [R=301,L]
# If path is not a directory or file then apply RewriteRule
RewriteCond %{REQUEST_FILENAME} -f [NC,OR]
RewriteCond %{REQUEST_FILENAME} -d [NC,OR]
RewriteCond %{REQUEST_FILENAME} -l [NC]
RewriteRule .* - [L]
# Rewrite for page view
RewriteRule ^([^/]+)/([^/]+)/([^/]+)/?$ account.php?type=$1&user=$2&page=$3 [QSA,L]
# Condition to ignore regular links
RewriteRule ^library/templates/([^/]+)/([^/]+)/([^/]+)/?$ library/templates/$1/$2/$3 [QSA,L]
# Rewrite for dynamic page settings
RewriteRule ^([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/?$ account.php?type=$1&user=$2&page=$3&$4=$5 [QSA,L]
# Rewrite for account view
RewriteRule ^([^/]+)/([^/]+)/?$ account.php?type=$1&user=$2 [QSA,L]
# Rewrite for site default resources location
RewriteRule ^([^/]+)/([^/]+)/theme/s/([^/]+)/([^/]+)/([^/]+)/?$ library/themes/site/$3/$4/$5 [QSA,L]
# Rewrite for profile view
RewriteRule ^([^/]+)/?$ profile.php?user=$1 [NC,L]
# Rewrite for vCard view
RewriteRule ^([^/]+)/vcard/?$ vcard.php?user=$1 [NC,L]
# Rewrite for user themes location
#RewriteRule ^([^/]+)/([^/]+)/theme/([^/]+)?$ library/themes/users/$3 [NC,L]
#error codes
#RewriteRule ^error/([^/]+)/?$ error.php?code=$1 [NC,L]
This is my .htaccess It feels like its way to long and that it can be made more efficient. The problems I'm having at the moment are that because of the order these rules are in the Rewrites for profile view and vcard view aren't working at the moment. I figured out that depending in what order I place these RewriteRules it will affect how the others behave. Its kinda of a nightmare if you ask me.
My site structure isn't so complicated. I have 3 PHP pages each page handles different actions of my project using the $_GET values for checking that the person is in the right place with the right parameters. One thing I was having issues with was making friendly links so people can go to an image or something using familiar url paths.
Well thats it, oh ya. Also I have a dynamic RewriteRule template for when I want to use an option or a setting, then I can use the last 2 place holders to put in my data.
# Options:
# -MultiViews: Turns off multiviews so it doesn't interfer with our rewrite rules
# -Indexes: Stop directory listings
# +FollowSymlinks: Let out rewrite rules work
Options -MultiViews -Indexes +FollowSymlinks
RewriteEngine On
RewriteBase /
# Error page
# Force add trainling slash
RewriteCond %{REQUEST_URI} !(\.[a-zA-Z0-9]{1,5}|/)$
RewriteRule (.*)$ http://foo.bar/$1/ [R=301,L]
# Prepent www if not exist in URI
RewriteCond %{HTTP_HOST} ^foo\.bar$
RewriteRule (.*) http://www.foo.bar/$1 [R=301,L]
# If path is not a directory or file then apply RewriteRule
RewriteCond %{REQUEST_FILENAME} -f [NC,OR]
RewriteCond %{REQUEST_FILENAME} -d [NC,OR]
RewriteCond %{REQUEST_FILENAME} -l [NC]
RewriteRule .* - [L]
# Rewrite for page view
RewriteRule ^([^/]+)/([^/]+)/([^/]+)/?$ account.php?type=$1&user=$2&page=$3 [QSA,L]
# Condition to ignore regular links
RewriteRule ^library/templates/([^/]+)/([^/]+)/([^/]+)/?$ library/templates/$1/$2/$3 [QSA,L]
# Rewrite for dynamic page settings
RewriteRule ^([^/]+)/([^/]+)/([^/]+)/([^/]+)/([^/]+)/?$ account.php?type=$1&user=$2&page=$3&$4=$5 [QSA,L]
# Rewrite for account view
RewriteRule ^([^/]+)/([^/]+)/?$ account.php?type=$1&user=$2 [QSA,L]
# Rewrite for site default resources location
RewriteRule ^([^/]+)/([^/]+)/theme/s/([^/]+)/([^/]+)/([^/]+)/?$ library/themes/site/$3/$4/$5 [QSA,L]
# Rewrite for profile view
RewriteRule ^([^/]+)/?$ profile.php?user=$1 [NC,L]
# Rewrite for vCard view
RewriteRule ^([^/]+)/vcard/?$ vcard.php?user=$1 [NC,L]
# Rewrite for user themes location
#RewriteRule ^([^/]+)/([^/]+)/theme/([^/]+)?$ library/themes/users/$3 [NC,L]
#error codes
#RewriteRule ^error/([^/]+)/?$ error.php?code=$1 [NC,L]
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
由于每个结果 URL 只有一条规则，因此我认为在不更改应用程序 URL 结构的情况下，您无法简化这一过程（或者不能显着简化）。你的正则表达式很简单，而且据我所知，足够可靠。
但是，是的，结构很脆弱并且依赖于顺序：
查看或转到 vcard 视图。这需要
将帐户查看规则放在之后
vCard 查看规则并避免
有一个名为“vcard”的用户。
链接或动态页面设置——所以
避免交换这两个规则或具有类型“库”和
用户“模板”。
我不会太担心效率/性能：在我的一个项目中，我们使用类似的设置，其中包括 308 RewriteRule 和 307 RewriteCond（只是计算了它们）。与您有同样的担忧，我曾经通过使用随机 URL 与转换后的 URL 运行负载测试来测量其性能，性能差异非常小，以至于在 PHP 和 PHP 的背景下根本无法测量。数据库处理。
注意：事实上，我有过类似的经历（我不得不说非常相似），但这并不意味着我支持它。无法轻松记录和解释的 URL 结构是一场噩梦，应尽可能避免。
Since you have only one rule for each result URL, I don't think you can simplify this -- or not significantly -- without altering your app's URL structure. Your regexps are simple and, as far as I can tell, solid enough.
But yes, the structure is fragile and order-dependent:
view or to vcard view. Which requires
putting the account view rule after
the vCard view rule AND avoiding ever
having a user called "vcard".
links or dynamic page settings -- so
avoid swapping these two rules or having a type "library" and a
user "templates".
I wouldn't worry much about efficiency/performance: in one of my projects we're using a similar setup with 308 RewriteRule and 307 RewriteCond (just counted them). Having the same worry you have, I once measured its performance by running a load test with random URLs vs. the transformed ones and the difference in performance was so small that it was simply not measurable against the backdrop of PHP & database processing.
Note: the fact that I have experience with something similar (strikingly similar I have to say) should not be construed to mean that I back it. URL structures which can't be documented and explained easily are a nightmare and should be avoided if possible.