67

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

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

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

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

4

5 回答 5

41

这里没有歧义:RFC3986 说 no,即 URI 不能包含 unicode 字符,只能包含 ASCII。

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

于 2012-05-15T12:24:15.977 回答
16

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

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

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

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

加载相同的资源。因此,为了回答您的问题,作为主要资源标识符,我将自己限制为 0-9、AZ、az 和偶尔的连字符。

于 2009-09-06T18:09:00.503 回答
10

考虑到带有重音符号的 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 看起来不是最好的;但是,人们仍然习惯了它们,并且似乎总体上对它们非常了解。

于 2009-09-06T18:05:56.127 回答
6

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

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

在 Tomcat 上处理 URI 中的字符编码

于 2009-09-06T18:48:18.973 回答
2

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

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

于 2009-09-25T21:29:19.583 回答