EqualityComparer.Default.Equals() 返回错误结果还是什么？

发布于 2024-12-20 20:22:11 字数 1463 浏览 6 评论 0原文

除了 .NET Framework 中的错误之外，还有其他解释吗？ EqualityComparer.Default.Equals() 方法表示以下 URL 相等！

<一href="http://books.google.com/books?id=B84KAQAAIAAJ&pg=PA29&lpg=PA29&dq=fletcher+sandford+tilton&source=bl&ots=ou8eF5REOG&sig=74fzA11Z8 AENBtyCUcXEsXV06jQ&hl=en&ei=2rHTS9LaN4249gTOh_GrDw&sa=X&oi=book_result&ct=结果&resnum=3&ved=0CA0Q6AEwAg#v=onepage&q=fletcher" rel="nofollow">http://books.google.com/books?id=B84KAQAAIAAJ&pg=PA29&lpg=PA29&dq=fletcher+sandford+tilton&source=bl&ots=ou8eF5REOG&sig=74fzA1 1Z8AENBtyCUcXEsXV06jQ&hl=en&ei=2rHTS9LaN4249gTOh_GrDw&sa=X&oi=book_result&ct=结果&resnum=3&ved=0CA0Q6AEwAg#v=onepage&q=fletcher s

和

http://books.google.com/books?id=B84KAQAAIAAJ&pg=PA29&lpg=PA29&dq=fletcher+sandford+tilton&source=bl&ots=ou8eF5REOG&sig=74fzA1 1Z8AENBtyCUcXEsXV06jQ&hl=en&ei=2rHTS9LaN4249gTOh_GrDw&sa=X&oi=book_result&ct=结果&resnum=3&ved=0CA0Q6AEwAg#v=onepage&q=fletcher

请注意第一个末尾的空格后跟“s”。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

猫九 2024-12-27 20:22:11

好吧，问题（无论正确还是错误）并不在 EqualityComparer.Default 中。它按其应有的方式调用 Uri.Equals() 。

现在，Uri.Equals() 仅忽略片段上的差异。在很多情况下这是合适的。在很多情况下并非如此。就我个人而言，我不会将其作为默认值，但由于我不是编码它的人，也许我不知道一些令人信服的理由让事情保持原样。

请注意，这是有记录的。

其他决定也是有争议的（它忽略了主机组件上的大小写差异，这符合许多有关 URI 的实际问题，但不符合某些规范中如何定义 URI 相等性）。

如果您需要比这更严格的相等性，我建议您定义自己的比较器：

public class UriStictEqualityComparer : IEqualityComparer<Uri>
{
  public bool Equals(Uri x, Uri y)
  {
    return ReferenceEquals(x, y)
      ||
      (
        x != null
        &&
        y != null
        &&
        x.IsAbsoluteUri == y.IsAbsoluteUri
        &&
        x.ToString() == y.ToString()
      );
  }
  public int GetHashCode(Uri obj)
  {
    return obj == null ? 0 : obj.ToString().GetHashCode();
  }
}

不过，您可能会发现您希望上述认为不相等的某些情况也相等。例如，您需要考虑punycode和non-punycode版本是否相同，转义的非特殊字符是否应该不转义，等等。在这种情况下，Uri 的 Compare 方法可能会带来好处。

Well, the concern (whether right or wrong) isn't in EqualityComparer<Uri>.Default. It calls into Uri.Equals() as it should.

Now, Uri.Equals() ignores differences on fragment alone. In a great many cases that is appropriate. In a great many it's not. Personally I wouldn't have had it as the default, but then since I'm not someone who coded it perhaps I don't know of some compelling reasons to have things as they are.

Note that this is documented.

Other decisions are also debatable (that it ignores case-difference on host components matches many practical concerns about URIs, but not how URI equality is defined in some specifications).

If you need a stricter equality than that, I suggest you define your own comparator:

public class UriStictEqualityComparer : IEqualityComparer<Uri>
{
  public bool Equals(Uri x, Uri y)
  {
    return ReferenceEquals(x, y)
      ||
      (
        x != null
        &&
        y != null
        &&
        x.IsAbsoluteUri == y.IsAbsoluteUri
        &&
        x.ToString() == y.ToString()
      );
  }
  public int GetHashCode(Uri obj)
  {
    return obj == null ? 0 : obj.ToString().GetHashCode();
  }
}

Still, you may find that you want some cases the above considers unequal, to be equal too. E.g. you need to consider whether punycode and non-punycode versions are the same, whether escaped non-special characters should be unescaped, and so on. Uri's Compare method can be a benefit in such cases.

回复收藏 0 原文