传递看起来像 URI 目录的 GET 参数
我见过很多看起来像这样的 URI：
www.fakesite.net/stories/1234/man_invents_fire
我想知道 URI 的 /1234/man_invents_fire 部分是否实际上是目录，或者它们是否是 GET 参数（或其他参数）。 我注意到很多时候 /man_invents_fire 段是不必要的（可以删除而不会产生任何后果），这让我相信 /1234/ 是数据库表中故事的 id 号（或沿着这些表的内容）线）。
如果 URI 的这些部分是 GET 参数，是否有一种简单的方法可以实现这一点？ 如果没有，正在做什么？
（另外，我知道 CodeIgnitor 提供了这种功能，但我很好奇是否可以在没有 CodeIgnitor 的情况下轻松实现它。但是，如果这与答案相关，我通常是 PHP）
谢谢
I've seen a lot of URIs that look something like this:
www.fakesite.net/stories/1234/man_invents_fire
and I was wondering if the /1234/man_invents_fire part of the URI are actually directories or if they are GET parameters (or something else). I've noticed that a lot of times the /man_invents_fire segment is unnecessary (can be removed with no consequences), which led me to believe that the /1234/ is the id number for the story in a database table (or something along those lines).
If those segments of the URI are GET parameters, is there an easy way of achieving this?
If they aren't, what is being done?
(also, I am aware that CodeIgnitor gives this kind of functionality, but I was curious to find out if it could be easily achieved without CodeIgnitor. I am, however, generally PHP, if that is relevant to an answer)
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
就像 WordPress 中的永久链接一样，这通常是通过 Apache 的 mod_rewrite 完成的（如果不使用 Apache，则使用等效的方法）； 但是，您也可以使用 404 错误页面处理程序来实现相同的结果（但通常不建议这样做）。
通常，所有页面请求都会重定向到网关，该网关解析请求的 URI 以确定它是否符合指定的模式（在您的情况下可能是
/{category}/{article_id}/{article_title}） 。 从那里，网关通常可以仅使用article_id来检索适当的内容。根据系统的不同，
category和article_title通常可以被丢弃/忽略，并且通常用于 SEO 价值； 但是，在某些情况下，category可能用于以某种方式扩充article_id（例如：确定要查询哪个数据库表等）。MVC 与 Zend 一样，也使用类似的技术来确定要执行的控制器和方法。 此类使用的示例格式为
/{module}/{controller}/{method}； 然而，这是高度可定制的。Just like permalinks in WordPress, this is done typically done via Apache's mod_rewrite (or an equivalent thereof if not using Apache); however, you can also use a 404 error page handler to achieve the same result (but this is not usually recommended).
Typically, all page requests are redirected to a gateway that parses the requested URI to determine if it fits the specified pattern (in your case likely to be
/{category}/{article_id}/{article_title}). From there, the gateway can typically use just thearticle_idto retrieve the appropriate content.Depending on the system,
categoryandarticle_titlecan usually be thrown away/ignored and are typically for SEO value; however, in some casescategorymight be used to augmentarticle_idin some way (e.g.: to determine what DB table to query, etc).MVC's, like Zend, also use a similar technique to determine which controller and method therein to execute. An example format for this type of use is
/{module}/{controller}/{method}; however, this is highly customizable.在 PHP 中实现此功能通常是通过 .htaccess 文件并使用 apache 的 mod_rewrite 模块< /a>.
Implementing this in PHP is typically done via an .htaccess file and using apache's mod_rewrite module.
他们将网址设置为这样，以便人们可以轻松地为其添加书签，并且它可以在搜索中安全返回。
取决于您使用什么语言来解码它。 在本例中，“stories”是主脚本，“1234”是 id，“man_invent_fires”是标题。
如果您使用的是 php，则可以使用 $_SERVER['PHP_SELF'] 或 $_SERVER['REQUEST_URI'] 变量对其进行解码。
如果您打算制作这样的网站，则必须牢记一定的安全性。 在 google 中查找它们，但要注意的关键之一是 sql 注入器。
They make the url like that so that people can easily bookmark it, and it can return safely in the search.
Depends on what language you're using to decode it. In this case, it appears "stories" is the main script, and "1234" is the id, and "man_invent_fires" is the title.
If you're using php, you can use the $_SERVER['PHP_SELF'] or $_SERVER['REQUEST_URI'] variable to decode it.
If you're planning to make a website like that, certain safety must be kept in mind. Look them up in google, but key one to look out for is sql injectors.
好吧，您假设 1234 和 main_invents_fire 是参数是正确的。 从 HTTP 协议描述它们的意义上来说，它们并不是真正的 GET 参数，但它们完成相同的任务，同时保持 URL“友好”。 该技术称为 URL 重写 这些天网络上充斥着这方面的信息..
这是一个 关于 PHP 中友好 URL 的文章 但我确信谷歌搜索该主题会呈现更有用的结果。
Well, you are kind of right in assuming that the 1234 and main_invents_fire are parameters. They are not truly GET parameters in the sense that the HTTP protocol describes them but they accomplish the same task, while keeping the URL "friendly". The technique is called URL rewriting and the web is full of info on this these days..
Here's an article about friendly URLs in PHP but I'm sure googling for the topic will render more useful results.
作为除了我面前的答案之外的一些背景信息，URL 就是“统一资源定位器”。 尽管在过去，它经常用于 1:1 映射到文件/目录结构，但 HTTP 规范中所要求的只是识别某个资源。 基本上这意味着，给定某个字符串，它应该指示服务器上的某个“资源”。 实际上，在 HTTP 环境中，这通常是通过诸如 mod_rewrite 之类的重写机制来实现的。 RFC 例如： http://www.ietf.org/rfc/rfc1738.txt< /a> 给出一个很好的、虽然抽象的概述。 不过，这些概念只有在设计和实现一些非显而易见的用途后才会变得现实。
As some background information in addition to the answers before me, a URL is just that - a 'Uniform Resource Locator'. Although in the old days, it often used to map 1:1 to a file/directory structure, all that is required in the HTTP spec is to identify a certain resource. Basically that means that, given a certain string, it should indicate a certain 'resource' on the server. In practice, in a HTTP environment this is usually implemented with a rewriting mechanism such as mod_rewrite. RFC's such as this one: http://www.ietf.org/rfc/rfc1738.txt give a nice, albeit abstract, overview. The concepts only come to life after designing and implementing some non-obvious uses, though.
如果您使用 Symfony，那么您可以使用 路由功能来执行此操作。
If you are using Symfony, then you can use the routing feature to do this.
最简单的方法是将所有内容路由到主index.php文件中，然后通过运行 $pieces =explode("/", $_SERVER['REQUEST_URI']); 找出您的路由。
安装/启用 mod_rewrite 后，确保 apache 配置中的 allowed override 未设置为 false（以允许读取 .htaccess），然后将其放入 docroot 的 .htaccess 文件中。
Easiest thing to do is route everything into a main index.php file and figure out your routing from there by running $pieces = explode("/", $_SERVER['REQUEST_URI']);
After installing/enabling mod_rewrite, make sure allow override is not set to false in your apache config (to allow .htaccess to be read), then throw this in your docroot's .htaccess file.
这就是所谓的url重写，google一下，你会发现很多这方面的信息。
That is called url rewriting, google for it, you will find a lot of information about that.