关于动态URL解析的问题
我看到很多很多网站都有各个页面的 URL，例如
http:// www.mysite.com/articles/this-is-article-1 http://www.mysite.com/galleries/575
而且它们不会重定向，它们运行速度并不慢...
我知道如何解析 URL，这很简单。 但在我看来，这在动态网站上似乎又慢又麻烦。 另外，如果页面都是静态构建的（hende 自定义 URL），那么这意味着页面的所有组件也是静态的......（这会很糟糕）
我很想听听一些关于这通常是如何进行的想法完成了。
I see many, many sites that have URLs for individual pages such as
http://www.mysite.com/articles/this-is-article-1
http://www.mysite.com/galleries/575
And they don't redirect, they don't run slowly...
I know how to parse URL's, that's easy enough. But in my mind, that seems slow and cumbersome on a dynamic site. As well, if the pages are all staticly built (hende the custom URL) then that means all components of the page are static as well... (which would be bad)
I'd love to hear some ideas about how this is typically accomplished.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
有很多方法可以处理上述问题。 一般来说，总是至少涉及某种形式的重定向 - 尽管这可能是在 .htaccess 级别而不是 php。 下面是一个场景：
使用 .htaccess 重定向到您的 php 处理脚本。
解析 uri ($_SERVER['REQUEST_URI']) 并确定内容类型（例如，根据您的示例，文章或图库）。
使用提供的 id（通常附加到 uri 的末尾，再次如您的示例中所示）来获取正确的数据 - 通过提供静态文件或查询数据库来获取请求的内容。
这种方法是一种非常流行的提高 SEO 的方法，但正如您正确强调的那样，采用这种方法可能会遇到困难 - 通常不是性能问题，但它可能会使开发或管理变得更加麻烦（如果您的实施没有经过深思熟虑，那么后者会变得更加麻烦）可扩展）。
There are many ways you can handle the above. Generally speaking, there is always at least some form of redirection involved - although that could be at the .htaccess level rather than php. Here's a scenario:
Use .htaccess to redirect to your php processing script.
Parse the uri ($_SERVER['REQUEST_URI']) and ascertain the type of content (for instance, articles or galleries as per your examples).
Use the provided id (generally appended to the end of the uri, again as in your examples) to obtain the correct data - be that by serving a static file or querying a database for the requested content.
This method is a very popular way of increasing SEO, but as you rightly highlight there can be difficulties in taking this approach - not typically performance, but it can make development or administration more troublesome (the later if your implementation is not well thought out and scalable).
首先，当将应用程序级别的 /plain/ URL 重写与使用 /plain/ CGI（CGI 可以是 PHP、ISAPI、ASP.NET 等）提供静态页面进行比较时，提供静态文件将永远获胜。 只是工作量变少了。 例如，在 Windows 和 Linux（据我所知）中，内核甚至还增强了通过 HTTP 在本地驱动器上提供静态文件的功能。 为了进一步说明这一点，我什至找到了使用多个服务器和操作系统的基准测试：http://www.litespeedtech.com/web-server-performance-comparison-litespeed-2.0-vs.html#RESULT 请注意，提供静态文件比使用任何类型的文件要快得多CGI
然而，通过有效地使用重写的 URL 并且通过缓存完成，可能会提高性能和可扩展性。 如果您返回正确的缓存标头（请参阅 HTTP 中的 缓存控制指令文档），然后它使下游服务器能够缓存数据，这样您的网站就不会受到点击。 但是，我想您可以通过静态页面获得相同的好处:) 我只是碰巧在一两天前在高可扩展性博客上读到了一篇关于这个主题的文章：http://highscalability.com/strategy-understanding-your-data-leads-best-scalability-solutions
Firstly, when comparing /plain/ URL rewriting at the application level to using /plain/ CGI (CGI can be PHP, ISAPI, ASP.NET, etc.) with serving static pages, serving static files will always, always win. There is simply less work. For example, in Windows and Linux (that I know of) there are even enhancements in the kernel for serving static files on a local drive via HTTP. To further make the point I even found a benchmark using several servers and OSs: http://www.litespeedtech.com/web-server-performance-comparison-litespeed-2.0-vs.html#RESULT Note that serving static files is dramatically faster than using any type of CGI
However, there can potentially be performance and scalability gains by using rewritten URLs effectively and it is done with caching. If you return proper cache headers (see cache-control directive in HTTP documentation) then it enables downstream servers to cache the data so you won't even get hits on your site. However, I guess you could get the same benefit with static pages :) I just happen to read an article on this very topic a day or two ago at the High Scalability blog: http://highscalability.com/strategy-understanding-your-data-leads-best-scalability-solutions
重写引擎是最好的方法，因为它们速度快且经过优化。 允许您的服务器端脚本仅使用普通的本地变量。
Apache 的 mod_rewrite 是最常见的。
A rewrite engine is the best approach as they are fast and optimised. Allowing your Server-Side scripting to use just plain local vars.
Apaches mod_rewrite is the most common.
它通常是通过服务器中的重写引擎完成的（通过Apache中的mod_rewrite之类的东西）或在 Web 应用程序中（所有请求都路由到 Web 应用程序，该应用程序查找指定路径的路由）。
It's usually done via a rewrite engine, either in the server (via something like mod_rewrite in Apache) or in the web application (all requests are routed to the web application, which looks for a route for the path specified).
就我而言，我坚持使用已内置此功能的 Web 框架。 （代码点火器）
...是的，这确实非常糟糕。 :o
In my case, I stick to the web framework with this feature already built-in. (CodeIgniter)
... yes, this is very bad indeed. :o
可以
应用程序级别（在本例中为 PHP）。 您可以编写自定义重定向来分析 URL 并基于此以某种方式进行重定向。 现代 Web 框架（例如 Zend Framework (ZF)）使用路由来控制 URL 重写。 以下是 ZF
$route = new Zend_Controller_Router_Route_Static('latest/news/this/week',
array('controller' => '新闻'));
这将重定向来自 http://somedomain.com/lastest/news/this/week< 的任何请求/a> 到新闻控制器。
动态路由的一个例子是
$route = new Zend_Controller_Router_Route('gallery/:id', array('controller' => 'gallery'));
其中变量 $id 可用于该控制器（使用我们上面的示例将是 575）。
这些是非常有用的工具，可让您开发应用程序并追溯将 URL 更改为您想要的任何内容。
It is possible to rewrite at
The server level in either the .htaccess file or the httpd.conf or vhosts.conf file. This is typically faster than the next level of rewriting which is done on the application level.
The application level (in this instance with PHP). You can write custom redirects that analyse the URL and redirect in some way based on that. Modern web frameworks such as the Zend Framework (ZF) use routes to control URL rewriting. The following is an example of a static route with ZF
$route = new Zend_Controller_Router_Route_Static('latest/news/this/week',
array('controller' => 'news'));
Which would redirect any request from http://somedomain.com/lastest/news/this/week to the news controller.
An example of a dynamic route would be
$route = new Zend_Controller_Router_Route('galleries/:id', array('controller' => 'gallery'));
Where the variable $id would be availbe to that controller (and using our example above would be 575)
These are very useful tools to that allow you to develop an application and retrospectively change the URL to anything you want.
一个非常简单的方法是让 CGI 解析 URL 的 PATH_INFO 部分。
在您的示例中：
脚本名称后面的所有内容都会传递到 PATH_INFO CGI 标头中的脚本。
然后您可以进行数据库查找或任何您希望生成页面的操作。
访问此值时请务必小心，因为 IIS 服务器和 Apache 服务器将 URL 的不同部分放入 PATH_INFO 中。 （IIRC：IIS 错误使用整个 URL，Apache 如上所述对其进行修剪。）
A very simple way is to have a CGI parse the PATH_INFO portion of the URL.
In your example:
Every thing after the script name is passed to the script in the PATH_INFO CGI header.
Then you can do a database lookup or whatever you wish to generate the page.
Use caution when accessing this value as the IIS server and Apache server put different portions of the URL in PATH_INFO. (IIRC: IIS incorrectly uses the entire URL and Apache prunes it as stated above.)
在 apache 服务器上，mod_rewrite 是最常见的，它是一个 apache mod，允许您使用正则表达式将请求 url 重写为其他 url，因此对于您的示例，将使用类似这样的内容：
这几乎不需要任何时间，并且实际上是就像获得网址一样快：
www.mysite.com/galleries.php?gallerie=575 但看起来好多了
On apache servers mod_rewrite is the most common for this, it's an apache mod which allows you to rewrite request urls to other urls with regular expressions, so for your example something like this would be used:
This costs hardly any time, and in practice is just as fast as having the url:
www.mysite.com/galleries.php?gallerie=575 but looks way better
我以前使用过这种方法 - 您只需要添加不应该在正则表达式中重定向的文件扩展名，然后其他所有内容都由 php 处理，因此您不需要进入 .htacces 文件
使用网址成功
I have used this method preiously - you just need to add the file extensions that should not be redirected in the regex and then everything else is handled by php so you don't need to be going into your .htacces file
suceed with urls