我应该在 URL 中使用重音字符吗？

Question

当人们使用不同于英语的语言创建网页内容时，搜索引擎优化和用户友好 URL 的问题就会出现。

我想知道在 URL 中使用去重音字母是否是最佳做法——冒着某些词在有或没有某些重音时具有完全不同的含义的风险——或者最好坚持使用非重音字母。在不太高级的环境（例如 MSIE、查看源代码）中适当牺牲这些 URL 的可读性的英文字符。

“异国情调”字母可能出现在任何地方：文档标题、标签、用户名等，因此它们并不总是在网站维护者的完全监督之下。

当然，一种可能的方法是设置替代的 -- 非重音 -- 指向原始目标的 URL，但我想了解您对使用重音 URL 作为 主要 的意见文档标识符。

Answer 1

考虑到带有重音符号的 URL 通常最终看起来像这样：

http://fr.wikipedia.org/wiki/%C3%89l%C3%A9phant

...这不太好...我想我们仍然会在一段时间内使用去重音的 URL。

不过，事情应该会变得更好，因为重音 URL 现在似乎已被 Web 浏览器接受。

我当前使用的 firefox 3.5 以很好的方式显示 URL，而不是 %stuff, btw ；这似乎是自 firefox 3.0 以来的“新”（见Firefox 3: UTF-8 support in location bar）；所以，至少在 IE 6 中可能不支持——而且仍然有很多人在使用这个 :-(

也许没有重音的 URL 看起来不是最好的；但是，人们仍然习惯了它们，并且似乎普遍理解它们。

Answer 2

当遇到类似问题时，我利用URL rewriting 来允许通过重音字符或非重音字符访问此类页面。实际的 URL 类似于

http://www.mysite.com/myresume.html

并且重写+字符翻译功能允许这个参考

http://www.mysite.com/myresumé.html

加载相同的资源。因此，为了回答您的问题，作为 primary 资源标识符，我将自己限制为 0-9、A-Z、a-z 和偶尔的连字符。

Answer 3

您应该避免用户在浏览器中手动输入的 URL 中的非 ASCII 字符。对于由服务器预编码的嵌入式链接是可以的。

我们发现浏览器可以用不同的方式对 URL 进行编码，而且很难弄清楚它使用什么编码。请参阅我关于此问题的问题，

Handling Character Encoding in URI on Tomcat

Answer 4

一个完整的 URL 中有几个区域，每个区域可能有不同的规则。 该协议是纯 ASCII。 DNS 条目受 IDN（国际域名）规则的约束，并且可以包含（大多数）Unicode 字符。 路径（在第一个 / 之后）、用户名和密码也可以是一切。它们被转义（如 %XX），但这些只是字节。这些字节的编码是什么很难知道（由http服务器解释）。 参数部分（在第一个？之后）“按原样”（在 %XX 取消转义之后）传递给某些服务器端应用程序（php、asp、jsp、cgi），而如何解释字节则是另一回事）。 建议路径/用户/密码/参数为 utf-8，但不是强制性的，也不是每个人都尊重这一点。

因此，您绝对应该允许使用非 ASCII（我们不再是 80 年代了），但您如何使用它可能会很棘手。尝试使用 Unicode 并远离遗留代码页，如果可以的话，用适当的编码/字符集标记您的内容（在 html 中使用元，asp/jsp 的语言指令等）

Answer 5

这里没有歧义：RFC3986 says no，即 URI 不能包含 unicode 字符，只能包含 ASCII。

一个完全不同的问题是浏览器在显示 URI 时如何表示编码字符，例如，一些浏览器会在 URL 中显示一个空格而不是 '%20'。这也是 IDN 的工作方式：punycoded 字符串由浏览器即时编码和解码，所以如果您访问 cafe.com，您实际上是在访问 xn--caf-dma.com。 URL 中的 unicode 字符实际上只是浏览器的“视觉糖”：如果您使用不支持 IDN 或 unicode 的浏览器，编码版本将不起作用，因为 URL 的底层定义只是不支持它，因此要使其始终如一地工作，您需要 % 编码。