我正在建立一个客户已翻译成克罗地亚语和斯洛文尼亚语的网站。为了与我们现有的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编码的方法，或者我最好用非变音字符替换这些字符？
由于
答案 0 :(得分：4)
问问自己真的是否希望他们进行非网址编码。当一个不支持安装这些角色的用户出现时会发生什么？我不知道，但我不想冒险让我的网站的大部分内容无法用于世界上大部分的计算机......
相反，请关注为什么您需要此功能。这是为了让网址看起来不错吗？如果是这样，使用常规z代替ž就可以了。您是否使用网址进行用户输入？如果是这样，在将其解析为链接输出之前对所有内容进行url-encode，并在使用输入之前对其进行url-decode。但是不要在网址中使用ž和其他本地字母......
作为旁注，在瑞典我们有å，ä和ö，但没有人在网址中使用它们 - 我们使用a，a和o，因为浏览器不会支持网址。这并不会让用户感到惊讶，很少有人无法理解我们瞄准的是什么词只是因为网址中的ring丢失了。文本仍会在页面上正确显示，对吗？ ;）
答案 1 :(得分：2)
有没有人知道强制IIS不进行URL编码的方法
您必须进行网址编码。在HTTP标头中传递原始'š'（\ xC5 \ xA1）无效。浏览器可能会将错误修复为'％C5％A1'，但如果是这样的话，如果您刚刚首先编写'％C5％A1'，则结果不会有任何不同。
在链接中包含原始'š'并没有错，因此浏览器应根据IRI规范将其编码为UTF-8并进行URL编码。但为了确保这实际上有效，您应该确保带有链接的页面作为UTF-8编码。同样，手动URL编码可能是最安全的。
我对UTF-8网址没有任何问题，您是否可以链接到无效的示例？
您是否有指向引用的链接，其中详细说明了包含有效HTTP标头的内容？
通常，RFC 2616。然而，在实践中它有点无益。关键段落是：
* TEXT的字只有在根据RFC 2047的规则编码时才包含ISO-8859-1以外的字符集中的字符。
问题在于，根据RFC 2047的规则，只有'atoms'可以容纳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字符集也不安全！不管怎么说那不会给你'š'......
答案 2 :(得分：0)
这些字符在URL中应该有效。我在一个大型旅游网站上做了URL搜索引擎优化的东西，那是我学到的。当你强制变音符号为ascii时，如果你不小心，你可以改变单词的含义。由于变音符号仅存在于其上下文中，因此通常没有翻译。