Fatal编程技术网
  • encoding/
  • Encoding Safari根据请求对已编码的URL进行编码

Encoding Safari根据请求对已编码的URL进行编码

encoding safari character-encoding

Encoding Safari根据请求对已编码的URL进行编码,encoding,safari,character-encoding,Encoding,Safari,Character Encoding,我在Safari中使用以下URL对页面执行HTTP GET请求： mysite.com/page.aspx？param=v%e5r 该页面包含一个表单，可将其发回自身。 当通过asp.net输出时，HTML表单标记如下所示： 当Safari将其发回时，它会以某种方式将此URL转换为： page.aspx？param=v%25u00e5r，即它对已编码的URL字符串进行URL编码，然后对该字符串进行双重编码，并且该参数生成的输出是乱码（vå；r）。在打印参数之前，我可以在一些地方通过UR

我在Safari中使用以下URL对页面执行HTTP GET请求：
mysite.com/page.aspx？param=v%e5r

该页面包含一个表单，可将其发回自身。 当通过asp.net输出时，HTML表单标记如下所示：

当Safari将其发回时，它会以某种方式将此URL转换为：
page.aspx？param=v%25u00e5r
，即它对已编码的URL字符串进行URL编码，然后对该字符串进行双重编码，并且该参数生成的输出是乱码（
vå；r
）。在打印参数之前，我可以在一些地方通过URL解码参数来解决这个问题

Firefox甚至IE8都能很好地处理这个问题。这是WebKit中的错误还是我做错了什么

总结如下：
  • 获取mysite.com/page.aspx？param=v%e5r
    HTML:
  • POST
    mysite.com/page.aspx？param=v%25u00e5r

    HTML:

    • 虽然您可以在URL的查询部分使用UTF-8以外的编码，但这是不可取的，通常会混淆采用UTF-8的各种脚本

    您确实希望在标记为UTF-8的页面中生成表单，然后在应用程序中接受UTF-8，并将字符串
    vår
    （假设这就是您的意思）编码为
    param=v%C3%A5r

    page.aspx?param=v%u00e5r
    哦，天哪！那是大错特错的<代码>%uxxx仅为JavaScript-
    escape（）
    -样式的序列；输入URL是完全无效的。Safari大概是想通过对
    %
    进行编码来纠正这个错误，该编码后面没有一个两位数的十六进制序列，后面是
    %25

    是ASP.NET生成的吗？如果是这样，那就太令人失望了。如何创建
    标记？如果手动编码参数，可能需要
    HttpUtility.UrlEncode
    ？即
    编码.UTF8
    ，或者，如果您确实必须使用
    v%e5r
    ，
    新编码（1252）
    （Windows代码页1252，西欧）.

    一件奇怪的事：如果我回帖多次，你会认为双重编码会变成三重编码，比如
    %u00e5
    ->
    %25u00e5
    ->
    %2525u00e5
    等等。这种情况不会发生……它会发生在其他像Chrome这样的webkit浏览器中吗？实际上它也可以在Chrome中工作。所以这不是WebKit的问题。从fiddler我看到Chrome实际上将重定向URL输出为
    page.aspx？param=v%25u00e5r
    ，但它以正确的编码（
    page.aspx？param=v%25u00e5r
    ）请求该页面。哎呀，正确的编码应该是
    page.aspx？param=v%u00e5r
    ），谢谢你的回答！我应该提到我们的web应用程序使用ISO8859-1编码。据我所知%u00e5是ISO编码的字符串。编码是使用HttpContext.Server.UrlEncode（x）完成的；有关safari以外的其他浏览器如何解决此问题的解释，请参阅。此论坛帖子似乎有点澄清（尽管它是2004年发布的）：。它的要点是1:asp.net有一个全球化层，它主要基于Accept字符集头来解释请求，其次是基于IIS全球化设置。我看到Safari没有发送Accept字符集头。Firefox和Chrome确实如此。2:ASP.Net使用非标准方式编码16位unicode字符。例如，
    %uxxx
    格式。我尝试从Firefox请求中剥离Accept字符集头（使用TamperData）；没有编码错误。我还尝试在IIS中将请求和响应编码设置为ISO-8859-1，如果错误是编码错误，这应该可以解决Safari的问题。然而，问题似乎是Safari不理解非标准的ASP.Net URL编码（
    %uxxx
    ）。因此，它将
    %
    解释为需要编码的内容，我们最终得到
    %25uxxx
    。这不仅是非标准的，在URL中的任何位置都是绝对无效的。该线程中关于
    %uxxx
    格式“由ISO-80646标准化”的说法是彻头彻尾的谎言。Safari尝试修复无效URL是正确的，就像您说的那样，例如
    param=100%
    。ISO-8859-1（或者更可能是Windows代码页1252）唯一正确的序列化是
    %E5
    。从该线程判断，我猜问题在于您正在从
    请求中获取自链接。QueryString
    。在ASP.NET中，此属性不是原始的查询字符串，而是ASP.NET已屏蔽的字符串。由于IIS/ASP.NET与许多工具一样，只需要UTF-8 URL，因此它本身不接受
    %E5
    ，因为这不是有效的UTF-8序列，因此它采用了不正确的
    %u
    编码。如果使用
    rawUrl
    属性，则会得到原始的
    %E5
    编码。最好是自己创建新的查询字符串，例如，
    “page.aspx？param=“+HttpUtility.UrlEncode（param，newencoding（1252））”
    。 
    page.aspx?param=v%u00e5r