System.Uri.ToString行为改变VS2012安装后 [英] System.Uri.ToString behaviour change after VS2012 install

查看:285
本文介绍了System.Uri.ToString行为改变VS2012安装后的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

一个dev的机器单元测试失败上安装VS2012 premium,因此开发人员解决了该问题之后。当变化推到TeamCity的单元测试失败。该项目并没有改变除了升级到与VS2012兼容的解决方案文件。它还是面向.NET框架4.0

After installing VS2012 Premium on a dev machine a unit test failed, so the developer fixed the issue. When the changes were pushed to TeamCity the unit test failed. The project has not changed other than the solution file being upgraded to be compatible with VS2012. It still targets .net framework 4.0

我已经隔离问题一个问题与UNI code字打电话时被转义 Uri.ToString 。下面code复制行为。

I've isolated the problem to an issue with unicode characters being escaped when calling Uri.ToString. The following code replicates the behavior.

Imports NUnit.Framework

<TestFixture()>
Public Class UriTest

   <Test()>
    Public Sub UriToStringUrlDecodes()
       Dim uri = New Uri("http://www.example.org/test?helloworld=foo%B6bar")

       Assert.AreEqual("http://www.example.org/test?helloworld=foo¶bar", uri.ToString())
    End Sub

End Class

一台机器,没有安装VS2012在VS2010运行这个成功,安装一台机器VS2012上运行,这在VS2010失败。无论使用来自的NuGet的最新版本NCrunch和NUnit的。

Running this in VS2010 on a machine that does not have VS2012 installed succeeds, running this in VS2010 on a machine with VS2012 installed fails. Both using the latest version of NCrunch and NUnit from NuGet.

从失败的断言消息

  Expected string length 46 but was 48. Strings differ at index 42.
  Expected: "http://www.example.org/test?helloworld=foo¶bar"
  But was:  "http://www.example.org/test?helloworld=foo%B6bar"
  -----------------------------------------------------^

MSDN 的两个。 NET 4和.NET 4.5显示,的ToString 不应该连接$ C C这个人物$,这意味着旧的行为应该是正确的。

The documentation on MSDN for both .NET 4 and .NET 4.5 shows that ToString should not encode this character, meaning that the old behavior should be the correct one.

A String instance that contains the unescaped canonical representation of the Uri instance. All characters are unescaped except #, ?, and %.

安装VS2012后,即UNI code字符被转义。

After installing VS2012, that unicode character is being escaped.

System.dll中的机器VS2012上的文件版本是4.0.30319.17929

The file version of System.dll on the machine with VS2012 is 4.0.30319.17929

System.dll中的生成服务器上的文件版本是4.0.30319.236

The file version of System.dll on the build server is 4.0.30319.236

忽略的,为什么我们使用 uri.ToString的优点(),我们正在测试和任何潜在的变通。任何人都可以解释为什么这种行为似乎已经改变,或者这是一个错误?

Ignoring the merits of why we are using uri.ToString(), what we are testing and any potential work around. Can anyone explain why this behavior seems to have changed, or is this a bug?

编辑,这里是C#版本

using System;
using NUnit.Framework;

namespace SystemUriCSharp 
{
    [TestFixture]
    public class UriTest
    {

        [Test]
        public void UriToStringDoesNotEscapeUnicodeCharacters()
        {
            var uri = new Uri(@"http://www.example.org/test?helloworld=foo%B6bar");

            Assert.AreEqual(@"http://www.example.org/test?helloworld=foo¶bar", uri.ToString());
        }

    }
}

进一步调查了一下,如果我面向.NET 4.0或.NET 4.5的测试失败,如果切换到.NET 3.5,然后它成功。

A bit of further investigation, if I target .NET 4.0 or .NET 4.5 the tests fail, if I switch it to .NET 3.5 then it succeeds.

推荐答案

的改变有关的问题与早期.NET版本,现在已改变变得更加符合标准。 %B6 是UTF-16,但根据UTF-8,应在开放的我们所使用的标准,这意味着它应该是%C2%B6 。因此,作为%B6 不是UTF-8现在是正确忽略,而不是去codeD。

The change is related to problems with earlier .NET versions, which have now changed to become more compliant to the standards. %B6 is UTF-16, but according to the standards UTF-8 should be used in the Uri, meaning that it should be %C2%B6. So as %B6 is not UTF-8 it is now correctly ignored and not decoded.

在<一个更多细节href="https://connect.microsoft.com/VisualStudio/feedback/details/758479/system-uri-tostring-behaviour-change"相对=nofollow>连接报告引述逐字下面。

.NET 4.5增强和RFC 3987的更多兼容的应用程序   这支持URI的IRI解析规则。 Iris供国际   资源标识符。这允许非ASCII字符是在一个   要解析URI / IRI字符串。

.NET 4.5 has enhanced and more compatible application of RFC 3987 which supports IRI parsing rules for URI's. IRIs are International Resource Identifiers. This allows for non-ASCII characters to be in a URI/IRI string to be parsed.

此前.NET 4.5,我们有虹膜一些不一致的处理。我们有   一个app.config条目的错误,你可以打开一个默认的:           

Prior to .NET 4.5, we had some inconsistent handling of IRIs. We had an app.config entry with a default of false that you could turn on:

其中做了一些IRI处理/分析。然而,它有一些问题。在   特别是它允许不正确%的编码处理。   百分比恩在URI / IRI串codeD项目都应该是   根据RFC 3987%的恩codeD UTF-8个字节他们不   除preTED为百分之恩codeD UTF-16。因此,处理%B6是不正确   根据UTF-8,不会发生解码。正确的UTF-8   对于¶编码实际上是%C2%B6。

which did some IRI handling/parsing. However, it had some problems. In particular it allowed for incorrect percent encoding handling. Percent-encoded items in a URI/IRI string are supposed to be percent-encoded UTF-8 octets according to RFC 3987. They are not interpreted as percent-encoded UTF-16. So, handling "%B6" is incorrect according to UTF-8 and no decoding will occur. The correct UTF-8 encoding for ¶ is actually "%C2%B6".

如果您的字符串是这样:

If your string was this instead:

        string strUri = @"http://www.example.com/test?helloworld=foo%C2%B6bar";

     

然后,它会得到规范化的ToString()方法和   百分号编码德codeD和删除。

Then it will get normalized in the ToString() method and the percent-encoding decoded and removed.

您可以提供有关应用程序的需求和更多信息   使用ToString()方法?通常情况下,我们建议绝对URI   URI对象的大多数标准化的需求属性。

Can you provide more information about your application needs and the use of ToString() method? Usually, we recommend the AbsoluteUri property of the Uri object for most normalization needs.

如果这个问题阻止您的应用程序开发和业务   需要那么请让我们知道通过netfx45compat微软点   COM的电子邮件地址。

If this issue is blocking your application development and business needs then please let us know via the "netfx45compat at Microsoft dot com" email address.

THX,

网络团队

这篇关于System.Uri.ToString行为改变VS2012安装后的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆