为啥有些网站网址不包含文件扩展名？

Posted 2023-04-13

【中文标题】为啥有些网站网址不包含文件扩展名？

【英文标题】：How come some site urls do not include a file extension?为什么有些网站网址不包含文件扩展名？

【发布时间】：2011-04-07 13:34:48

【问题描述】：

我在浏览互联网时注意到，例如，YouTube 包含一个表示视频页面的 URL：http://www.youtube.com/watch?v=gwS1tGLB0vc。

我的网站使用这样的 URL 作为主题页面：http://www.example.com/page.php?topic_id=6f3246d0sdf42c2jb67abba60ce33d5cc。

不同之处在于，如果您还没有注意到在 youtube 上，他们的观看页面没有文件扩展名，所以我想知道，为什么有些网站不使用文件扩展名，它有什么用途?

【参考方案1】：

不使用文件扩展名是因为 URI（因此是 URL）应该独立于实施 - 如果您想访问 CDC 关于食品安全的信息，您应该能够访问https://www.cdc.gov/foodsafety（例如)。 CDC 的服务器是使用 PHP 还是 Python 还是 Perl 对最终用户来说并不重要，因此他们不应该看到它。最终用户并不关心页面是如何生成的，因为为网页提供服务的所有语言都输出相同的 html、CSS 等，而用户只是在他们的网络浏览器中查看页面。

大多数 Web 框架默认内置此功能，正是出于这个原因，并且在大多数 Web 服务器中，无论 URL 重写如何，都可以实现此功能。这个理想被编入 W3C 风格指南，这无疑是这个想法被广泛接受的重要支持者。他们的指南"Cool URIs Don't Change" 中对此进行了概述，如果您仍然不太了解此处的推理，则应该可以解决问题。该文档是有关该问题的首选声明，也是框架的事实上的标准。

值得注意的是，通常最终下载的文件（有时在 AJAX 中使用的数据文件）仍然具有完整的文件扩展名 - http://example.com/song.mp3 或 http://example.com/whitepaper.pdf - 因为它们是旨在保存到最终用户的计算机上，其中文件扩展名很重要。仅显示（大多数页面）的页面不包含扩展。

后记：这个答案最初链接到的示例页面在某个时候停止存在，因为尽管有最佳实践，但有时 URI 确实会发生变化。我已将其替换为 CDC 的食品安全页面，该页面以某种形式存在于 at least 20 years now。毫无疑问，多年来，许多不同的技术提供了该内容，同时始终使用完全相同的 URL。

【参考方案2】：

您看到的是 URL 路由的示例。服务器不是指向特定文件（例如 page.php），而是使用路由表或配置将请求定向到实际呈现 html 的处理程序（或任何其他取决于返回的 mime 类型）。如果您注意到，*** 使用相同的机制。

【讨论】：

url路由的实际用途是什么？

另外，'watch' 可能是一个 PHP 文件，即使没有扩展名，服务器也只是设置为处理它 - 这就是 Wikipedia 通过更改 'index.php '它只是'维基'

URL路由的实际用途是将实际实现隐藏在网站后面。对于像 SO、Wikipedia、Facebook 等 Web2.0-ish 网站，实现可能非常混乱，甚至无法表示为真正的 URL，因为它是对 Web 服务的调用，而不是服务文件。您可以使用一个相对优雅的 URL 来添加书签或链接到其他站点，而不是所有需要的垃圾。

谢谢 Keith，但是当您说 Web 服务而不是直接文件时，您到底是什么意思？

他的意思是大多数框架都是这样工作的：http://site.com/index.php?page=category/subcategory/pageid&param1=value1&param2=value2 清理 url 大多数人使用 mod_rewrite 将其映射到：http://site.com/category/subcategory/pageid?param1=value1&param2=value 看起来更正常并且打字更友好。

【参考方案3】：

是否拥有扩展名无关紧要。浏览器作用于服务器返回的 MIME 类型，而不是 URL 中使用的任何扩展。

【讨论】：

这并不能真正解释为什么某些 URI 没有文件扩展名。它与客户端无关，但可能与服务器相关。

不是真的；服务器将被配置为在没有扩展的帮助下解密或翻译 URI。例如，这个线程的 URI 最终可能是 http://***.com/questions.php?&thread=3631153&title=how-come-some-site-urls-do-not-include-file-extension。我们不必知道，因为 Web 服务器或中介会进行翻译。像许多快捷方式一样，这确实意味着该站点不能使用扩展来区分，例如 questions.php 和 questions.jsp。

【参考方案4】：

当你问“为什么？”你问的是技术原因还是设计原因？有些人已经回答了技术问题，所以我只对设计发表评论。

基本上归结为 url 是一个端点。这是用户/服务需要到达的地方。在大多数情况下，扩展是无关紧要的。如果用户正在浏览网页并转到http://site.com/users，他正在等待用户列表。他不在乎它没有说 .html 或 .php。作为使用这些扩展的设计师并没有真正的意义。您希望您的应用有意义，而这些扩展并不能真正提供用户需要的任何洞察力。

如果您正在创建其他应用程序将使用的服务，那么您会想要使用它们。然后，您可以选择使用扩展名来表示期望返回的数据类型（.json、.xml 等）。有人在为这些东西制定设计指南和规范，但一切都还为时过早

基本上使用这些扩展是因为这是默认情况下 Web 服务器/客户端的工作方式。随着 Web 开发的成熟，我们开始更专业地处理 url，并试图让它们对阅读/使用它们的人有意义。

【参考方案5】：

虽然扩展对浏览器无关紧要，浏览器只是使用传递给它的标头来确定要显示什么以及如何显示它，但它们可能确实在服务器上很重要。例如，您的机器可能同时安装了 php 和 ruby​​ 解释器，但您的网络服务器具有将文件扩展名映射到 MIME 类型的配置文件。例如，来自 Apache 的 php5.conf：

  AddType application/x-httpd-php .php .phtml .php3

它告诉 Apache 以 .php、.phtml 和 .php3 结尾的文件应该被识别为 PHP 文件。

但是，由于扩展对客户端没有任何意义，因此没有它们，URL 通常看起来“更好”。为此，可以使用 Apache 的 mod_rewrite 等技术“重写”客户端 URL，使其在服务器上有意义。

例如，您可以设置mod_rewrite 规则来将http://yourblog.com/article/the-article-you-wrote 之类的URL（看起来更好，并且更易于键入和记住）重写为http://yourblog.com/articles.php?title=the-article-you-wrote，Apache 可以使用它来正确地将请求路由到您的PHP 脚本。

【参考方案6】：

关键是 HTTP 响应标头的 Content-Type 字段。类似的东西：

HTTP 200 OK
Content-Type: video/flv
Content-Length: 102345

DATA-DATA-DATA-DATA-DATA-DATA-....

另见：

Content-Disposition: attachment; filename=genome.jpeg;
     modification-date="Wed, 12 Feb 1997 16:29:51 -0500";

更多详情：http://en.wikipedia.org/wiki/MIME

【讨论】：

当您说密钥时，您的意思是服务器如何识别该文件的密钥？

响应在“Content-Type”字段中包含 MIME 类型，因此 Web 浏览器知道如何处理它。它将以不同于 image/png 的方式显示 text/html，依此类推。没有扩展的关键是您不必向世界公开您的服务器端技术，例如没有.php，没有.asp，等等。 .html 是不正确的，因为它们不是静态页面，只有“未知技术”的输出是 HTML。

另外，对于非技术人员来说，.jsp（或其他）只是另外四个不必要且无法识别的字符，它们会延长 URL。

【参考方案7】：

好吧，文件扩展名在互联网上没有任何用处。浏览器不关心文件扩展名是什么。您可以将 CSS 文件作为 .avi 提供。那么为什么不干脆把它排除在外呢？这允许使用更短的 URL。

此外，“重写” url 允许更多可读的 url。 /categories.php?id=455 你可能不懂，但/455-some-category你懂。

如果您想自己执行此操作并使用 Apache，请查看 mod_rewrite。

【参考方案8】：

网址应该被视为用户界面的一部分。因此，它应该旨在传达有关用户在网站上的位置以及网站结构的信息。

一个网址，例如：

mysite.com/sport/soccer/brazil_wins_worldcup

告诉用户很多关于网站的结构，以及他目前在哪里。相比之下：

mysite.com/article.php?cateogry=12&articleid=371

没有用，而是暴露了不相关的实现细节，例如使用哪种语言制作网站，以及该文章的 id 是什么（可能存储在该 id 下的数据库中）

除了这种道德论点（不要让用户接触不相关的实施细节）之外，它还有助于使网站面向未来。因为如果您从一开始就没有公开您选择的语言，那么您以后可以升级到 Ruby 或 Python，而不需要世界上所有指向您的链接，现在都是 404。

设计对用户有意义的网址，并且是面向未来的。

【参考方案9】：

对此有很多可能的答案。这是您的 Web 应用程序服务器的配置方式，导致您的 Web 浏览器正在解释什么。在某些情况下，您正在使用 URL 重写或路由，正如其他人所说，您为请求的 URL 或扩展提供了哪些处理程序。

如果我愿意，我可以有一个类似“http://cory.com/this/really/doesnt/exist”的 URL，并让它实际上指向“http://cory.com/this.does.exist.123”。

【讨论】：

为什么会出于好奇而使用 url 路由？

URL 路由允许您将相关逻辑分组到单个控制器文件中，而不是将其拆分为几个独立的 PHP 文件。

一个大的就是SEO（搜索引擎优化）。一些搜索引擎可能不太关心页面有哪些查询字符串参数，但如果您提供的 URL 可以路由到使用这些参数的页面，那么您会立即获得新的搜索结果。示例：cory.com/category/555/recent 可能会路由到 cory.com/category.aspx?id=555&sort=recent。此外，URL 更容易阅读和记住。还要记住，“路由”与“重写”不同——你会看到它们被错误地互换（就像我所做的那样）。

@Cory：你能提供关于 SEO 点的参考吗？我觉得更容易阅读，更有意义，...但我不相信 SEO 点；）

它还可以使 URL 看起来更漂亮，更容易记住

【参考方案10】：

Web 服务器的正常行为是将请求的 URI 路径映射到文档根目录中某处的文件。所以http://example.com/foo/bar 被简单地映射到/path/do/document/root/foo/bar。此外，Web 服务器需要知道如何处理文件。这通常由文件扩展名完成。所以文件扩展名为.php的文件由PHP解释器处理。

现在，除了这种正常行为之外，大多数 Web 服务器都具有允许更改映射（即URL rewriting）和处理没有文件扩展名的文件的方式的功能。

如果是 Apache Web 服务器，前者可以使用mod_rewrite：

RewriteEngine on
RewriteRule ^/watch$ /watch.php

而后者可以使用mod_mime:

<File watch>
    ForceType application/x-httpd-php
</File>

（好吧，实际上这不是 mod_mime 功能，而是core 功能。）

【讨论】：

好的，所以基本上该示例告诉服务器将手表映射到 watch.php，并通过输入 mime 类型告诉服务器作为 php 文件处理？

@Scarface：是的，没错。这两种变体都可以使用，以便/watch 指的是由 PHP 脚本生成的内容的页面。

太好了，感谢gumbo抽出宝贵时间，我将探索使用这些模组。

【参考方案11】：

规则：文件扩展名不应包含在 URI 中

在 Web 上，句点 (.) 字符通常用于分隔文件名和 URI 的扩展部分。 REST API 不应包含人为的文件扩展名 在 URI 中表示消息实体主体的格式。相反，他们应该依靠 通过 Content-Type 标头传达的媒体类型，以确定如何 处理正文的内容。

(1)http://api.college.restapi.org/students/3248234/transcripts/2005/fall.json (2)http://api.college.restapi.org/students/3248234/transcripts/2005/fall

(1)不应使用文件扩展名来表示格式偏好。 (2) 应鼓励 REST API 客户端使用 HTTP 提供的格式选择 机制，Accept 请求头。 参考：设计 REST api 规则手册

【参考方案12】：

下面是我在 .htaccess 中使用的内容，以使 url 在没有 HTML 或 PHP 扩展的情况下仍能正常运行。

RewriteEngine on
RewriteCond %REQUEST_FILENAME !-d
RewriteCond %REQUEST_FILENAME\.html -f

表示如果浏览器中指定名称的文件与您的网络服务器中的目录（-d）或文件（-f）不匹配，则重写下面的规则

RewriteRule ^(.*)$ $1.html

我不确定下面是如何工作的，但我认为在它用 html 重写之后，如果它仍然不匹配，那么用 php 重写

RewriteCond %REQUEST_FILENAME\.php -f
RewriteRule ^(.*)$ $1.php

如果仍然不匹配，则会显示 404 页面。

您也可以在 .htaccess 中使用以下代码重定向 404

ErrorDocument 404 /404.html

重要的是代码正在为我的网站工作。

http://mintnet.net/services

http://php.mintnet.net/home

那些不需要文件扩展名。

【参考方案13】：

“www.youtube.com/watch”是 YouTube 的目录。所以它基本上可以写成“www.youtube.com/watch/”结尾的正斜杠。

【讨论】：

您不能打开目录，只能打开文件，以目录结尾的 url 假定您有一个名为 index 的文件（或类似的文件）配置为在请求目录时打开，例如 https://www.youtube.com/watch/会请求https://www.youtube.com/watch/index.html，但正如我们所见，情况并非如此，其他任何索引文件也不是，因此youtube很可能只是在内部路由地址。