将文件扩展名添加到“href”中是否是更好的做法？价值？
如果我有一个非常简单 http 目录：
<前><代码>default.html 信息.html 联系方式.html ETC...
如果 default.html 链接到目录中的其他文件，我总是能够简单地使用锚标记，因此：
联系我！
假设目录中只有一个文件的名称与此无扩展名 href 值匹配，这是否总是有效？
If I have a very simple http directory:
default.html info.html contact.html etc...
Should default.html link to the other files in the directory, I've always been able to simply use an anchor tag thus:
<a href="contact" target="_self">Contact me!</a>
Will this always work, assuming that there is only one file in the directory with a name matching this extension-less href value?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，它不会自动附加
.html因为他不知道要使用哪个文件扩展名。假设您有一个contact.html和一个contact.php。他应该使用哪一个。但是，您可以使用重写规则（例如在 .htaccess 文件中）来完成所有这些操作。只需在此处或网络上搜索一些示例即可。
No it does not automatically appends
.htmlas he could not know which file extension to use. Let's say you have acontact.htmland acontact.php. Which one should he use.However you can do all this using rewrite rules (e.g. in a .htaccess file). Just search for some examples here on SO or in the web.
Apache2 中有一个内容协商功能可以做到这一点，但就我个人而言，我不喜欢依赖它。
如果我需要漂亮的 URL，我最好使用 mod_rewrite 并实现完全自定义的 url 方案，这样很容易修改和修改。定制无限制。
http://httpd.apache.org/docs/2.0/content-negotiation。 html
There is a content negotiation feature in Apache2 which does that, but personally, I do not like to rely on that.
If I need nice URLs, I'd better use mod_rewrite and implement completely custom url scheme which would be easy to modify & customize without limits.
http://httpd.apache.org/docs/2.0/content-negotiation.html
这取决于服务器及其设置方式。
请记住，URI 和 Web 服务器上的文件之间没有固有的映射，Web 服务器始终遵循某种关于要发送的文件的规则。最简单的方法采用 URI 的路径部分，并直接映射到网络服务器本地的文件路径，但它可以做任何其他事情。常见的情况是使用文件扩展名进行 con-neg，因此，如果您在与路径对应的同一本地目录中有 contact.html 和 contact.atom 等，它会从用户中选择最接近 Accept 标头的文件 -代理人。
将文件扩展名（无论是“静态”文件还是 .php、.aspx 等处理程序）放入 URI 中是毫无意义的，因为 Web 上不存在文件这样的东西（服务器上有文件，客户端上有文件）可以将流保存到文件中，但在网络本身上，存在可能对应也可能不对应于文件的八位字节流）。而且不太理想；据推测，contact.html 与联系方式有关，而“contact”很好地表达了这个想法，“.html”与联系方式无关，不属于那里。
因此，更明智的 URI 中不会包含“.html”，除非这以某种方式表达有用的内容（例如明确要求 HTML 版本并绕过内容协商，或者页面实际上是关于 HTML 的）。
另一方面，直接映射到文件名是一种快速而简单的方法，因此，虽然我确实对 URI 中的这种任意胡乱皱眉，但我不会跳过太多的障碍而不使用它，特别是在辅助 URI 中用于样式表、图像等，而不是那些通常出现在浏览器地址栏中的内容。
第三，一旦你消除了这些麻烦，如果需要的话，稍后添加更复杂的处理，就会变得更容易过渡。
It depends on the server and how it is set-up.
Remember that there's no innate mapping between URIs and files on a webserver, the webserver is always following some sort of rule as to what file to send. The simplest takes the path part of the URI and does a direct mapping to a filepath local to the webserver, but it could be doing just about anything else. A common case is using the file extension to do con-neg, so if you have contact.html and contact.atom and so on in the same local directory corresponding to the path, it picks that closest to the Accept header from the user-agent.
Putting file extensions (whether of "static" files or handlers like .php, .aspx, etc.) in URIs is rather pointless since there is no such thing as a file on the web (there are files on the server, and the client can save the stream to a file, but on the web itself there are octet streams that may or may not correspond to a file). And less than ideal; presumably contact.html has something to do with contact details, while "contact" expresses this idea well, ".html" has nothing to do with contact details and doesn't belong there.
Hence the more sensible URI would not have ".html" in it, unless this was in some way expressing something useful (such as explicitly asking for a HTML version and bypassing content-negotiation, or if the page was actually about HTML).
On the other hand, just mapping directly to file names is a quick and easy way to do things, so while I certainly frown on such arbitrary cruft in URIs I won't jump through too many hoops not to use it, especially in secondary URIs used for stylesheets, images etc. rather than those which are expected to regularly appear in the address bar of a browser.
On the third hand, once you remove such cruft, adding more sophisticated handling later if required, becomes a much easier transition.