在 URL 中使用非拉丁字符

Question

我正在开发一个客户已翻译成克罗地亚语和斯洛文尼亚语的网站。为了与我们现有的 URL 模式保持一致，我们生成了模仿应用程序布局的 URL 重写规则，这导致 URL 中包含许多非 ascii 字符。

示例 š ž č

有些链接是使用 getURL 从 Flash 触发的，有些是标准的 HTML 链接。有些是程序化的 Response.Redirects，有些是通过在响应中添加 301 状态代码和位置标头来实现的。我在 IE6、IE7 和 Firefox 3 中进行测试，并且浏览器会显示非拉丁字符 url 编码。

š = %c5%a1
ž = %c5%be
č = %c4%8d

我猜这与 IIS 以及它处理 Response.Redirect 和 AddHeader("Location ...

有没有人知道强制 IIS 不对这些字符进行 URL 编码的方法，或者我最好用非变音字符替换这些字符？

谢谢

Answer 1

问问你自己是否真的想要它们非网址编码。当一个不支持安装这些字符的用户出现时会发生什么？我不知道，但我不想冒险让世界上大部分计算机无法访问我网站的大部分内容...

相反，请关注为什么您需要此功能。是为了让网址看起来不错吗？如果是这样，使用常规 z 而不是 ž 就可以了。您是否使用 url 进行用户输入？如果是这样，在将其解析为链接输出之前对所有内容进行 url 编码，并在使用输入之前对其进行 url 解码。但不要在 url 中使用 ž 和其他本地字母...

附带说明一下，在瑞典，我们有 å、ä 和 ö，但没有人在 url 中使用它们 - 我们使用 a、a 和 o，因为浏览器不支持这些 url。这并不让用户感到惊讶，并且很少有人仅仅因为 å 中的环在 url 中丢失而无法理解我们的目标是什么。文本仍将正确显示在页面上，对吗？ ;)

Answer 2

有谁知道强制 IIS 不进行 URL 编码的方法

您必须进行 URL 编码。在 HTTP 标头中传递原始的 ‘š’ (\xC5\xA1) 是无效的。浏览器可能会为您修复高达“%C5%A1”的错误，但如果是这样，结果与您刚开始编写“%C5%A1”时的结果没有什么不同。

在链接中包含原始“š”并没有错，浏览器应该按照 IRI 规范将其编码为 UTF-8 和 URL 编码。但要确保这确实有效，您应该确保带有链接的页面以 UTF-8 编码提供。同样，手动 URL 编码可能是最安全的。

我对 UTF-8 URL 没有任何问题，你能链接到一个不起作用的示例吗？

您是否有指向参考的链接，其中详细说明了包含有效 HTTP 标头的内容？

规范地，RFC 2616。然而，在实践中它有些无益。关键段落是：

只有在根据 RFC 2047 的规则进行编码时，*TEXT 的单词才可以包含来自 ISO-8859-1 以外的字符集的字符。

问题在于，根据 RFC 2047 的规则，只有“原子”可以容纳 2047 的“编码字”。 TEXT，在大多数情况下，它包含在 HTTP 中，不能被设计成一个原子。无论如何，RFC 2047 是为 RFC 822 系列格式明确设计的，虽然 HTTP 看起来很像 822 格式，但实际上并不兼容；它有自己的基本语法，但有细微但显着的差异。 HTTP 规范中对 RFC 2047 的引用没有提供任何线索来说明如何能够以任何一致的方式解释它，并且据我所知的任何人都可以解决，这是一个错误。

在任何情况下，实际的浏览器都不会尝试在其 HTTP 处理的任何地方找到解释 RFC 2047 编码的方法。虽然 RFC 2616 将非 ASCII 字节定义为 ISO-8859-1，但实际上浏览器在处理 HTTP 时可以在不同的地方使用许多其他编码（例如 UTF-8，或任何系统默认编码）标题。因此，即使依赖 8859-1 字符集也不安全！无论如何，这不会给你'š'......

Answer 3

这些字符在 URL 中应该是有效的。我在一个大型旅游网站上做了 URL SEO 的东西，那时我才知道。当您将变音符号强制为 ascii 时，如果您不小心，您可以更改单词的含义。通常没有翻译，因为变音符号只存在于它们的上下文中。