by Michael S. Kaplan, published on 2005/03/23 12:51 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/03/23/401060.aspx
Bob Berger asked, in the suggestion box:
CaseInsensitiveHashCodeProvider and CaseInsensitiveComparer are not synchronized, despite what the documentation claims. The problem is that the CaseInsensitiveHashCodeProvider does not take equivalent character sequences into account, whereas the CaseInsensitiveComparer does.
For example, the character “Á” can be represented by a single code point, 0x00C1, and the character “á” can be represented by two code points, 0x0061 0x0301. Consequently, the expression
CaseInsensitiveComparer.DefaultInvariant.Compare("\u00C1", "\u0061\u0301")
returns zero. However, the expressions
CaseInsensitiveHashCodeProvider.DefaultInvariant.GetHashCode("\u00C1")
CaseInsensitiveHashCodeProvider.DefaultInvariant.GetHashCode("\u0061\u0301")
return 177508 and 5861733, respectively.
(I did some minor edits to make sure the code would work and that it matched the intent of the message)
I think there may be a little confusion on this point, because the hash code as returned by the GetHashCode() method on the CaseInsensitiveHashCodeProvider is not returning a number that is based on trying to create a culturally sesitive number that will meet the guidelines of returning equal values if Compare() would consider them to be equal (that functionality did not even exist until Whidbey, a fact that I know because I wrote it for Whidbey!). The actual hash table that uses the provider (as shown in the help examples) do show the behavior of the two being in lockstep when things work....
This post brought to you by "Х" (U+0425, CYRILLIC CAPITAL LETTER HA)
# AT on 23 Mar 2005 1:10 PM:
# Michael Kaplan on 23 Mar 2005 3:47 PM:
# mihailik on 24 Mar 2005 3:27 AM:
# Michael Kaplan on 24 Mar 2005 6:45 AM:
# Bob Burger on 24 Mar 2005 9:54 AM:
# Michael Kaplan on 24 Mar 2005 10:02 AM:
# Bob Burger on 24 Mar 2005 10:02 AM: