我正在一个客户已经翻译成克罗地亚语和斯洛文尼亚语的网站上工作。为了与我们现有的 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 编码的方法，或者我最好的选择是用非变音符号替换这些字符？
谢谢
问问自己你是否真的想要它们非 url 编码。当一个不支持安装这些字符的用户出现时会发生什么？我不知道，但我不想冒险让世界上大部分计算机无法访问我网站的大部分内容......
相反，请关注您为什么需要此功能。是为了让网址看起来不错吗？如果是这样，使用常规 z 而不是 ž 就可以了。您是否使用 url 进行用户输入？如果是这样，在将其解析为链接输出之前对所有内容进行 url 编码，并在使用输入之前对其进行 url 解码。但不要在 url 中使用 ž 和其他本地字母...
附带说明一下，在瑞典，我们有 å、ä 和 ö，但没有人在 url 中使用它们——我们使用 a、a 和 o，因为浏览器不支持这些 url。这并不让用户感到惊讶，并且很少有人仅仅因为 å 中的环在 url 中丢失而无法理解我们的目标是什么。文本仍将正确显示在页面上，对吗？;)
有谁知道强制 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 字符集也不安全！无论如何，这不会给你'š'......
这些字符在 URL 中应该是有效的。我在一个大型旅游网站上做了 URL SEO 的东西，那时我才知道。当您将变音符号强制为 ascii 时，如果您不小心，您可以更改单词的含义。通常没有翻译，因为变音符号只存在于它们的上下文中。