There's no "I" in IDN, part 5: Stephen Colbert's job is not in any jeopardy

Prior blogs in this series:

• part 1: If you're not Unicode, you're just wrong!
• part 2: Try not to use the wrong functions!
• part 3: There's no "I" in DIY, either!
• part 4: the 'path' to Hell is paved with IDN bugs

I suspect some of my readers are either fans or at least regular watchers of The Colbert Report.

Perhaps just my smarter readers.

Or maybe just the ones with basic cable....

Today's blog ends up being about a combination "tip of the hat/wag of the finger" question.

In honor of Stephen Colbert....

The question goes something like this:

SUBJECT: String.Compare for double byte characters in .Net

I have following two string characters whose comparisons in SQL are equal, however I couldn’t figure out any comparisons in .net (culture/ordinal/case insensitive) that would return me equality. Any ideas?

Goal is to not change SQL settings, but to find insensitive compare in .net.

String.Compare(
    "0336753496aaa@ae2.dion.ne.jp",
     "0336753496ａａａ@ae2.dion.ne.jp",
    CultureInfo.InvariantCulture,
    CompareOptions.IgnoreCase)

OR (Tried all combinations)

String.Compare(
    "0336753496aaa@ae2.dion.ne.jp",
    "0336753496ａａａ@ae2.dion.ne.jp",
    StringComparison.OrdinalIgnoreCase)

Now I'll consolidate the many different tips and wags:

First of all, a wag of the finger since the question referred to "double byte characters" despite every string involved using Unicode, in a language (C#) that uses Unicode.

Perhaps somewhat forgivable since the example was clearly referencing Japan, so perhaps the questioner was thinking about Japanese at the time. And therefore "double byte" was just old school thinking about CJK. Kind of like how they never migrated all those people off the FAREAST domain, even as everything else started referencing east Asia. Even though domain account migrations are so much easier these days after those thousands of migrations in Windows kind of forced ITG to get better at it....

Second of all, a tip of the hat to the genuine attempt to try to do comparisons that fold out distinctions in an attempt to get parity between SQL Server and the .NET Framework.

Third of all, a wag of the finger for ignoring the most important distinction in this case -- the implicit Width Insensitive nature of all _C*_A* collations in SQL Server, which could have been simulated by adding a StringComparison.IgnoreWidth to the first call, had their names not masked the fundamenta nature of the "hidden width" that makes me wonder if someone in SQL Server isn't worried about their weight too much....

Fourth of all, a wag of the finger for taking a question obviously covering E-mail Address Internationalization (EAI) but doing it without even asking the question in a way or to a distribution list that suggested they were thinking about EAI.

With a bonus fifth of all wag of the finger to SQL Server since it is hiding so much of the problem here that people come out of SQL Server wondering how to make other products act like them, rather than coming out asking the real questions....

Okay, seems like a lot more wags than tips on this one. And that's even ignoring the extra wags i decided to leave for another day.

I've decided I can't do "tip of the hat/wag of the finger" very well. I should leave that sort of thing to the professionals. From now on, I will.

I'll talk more about EAI another day, too....