Comments on: Comparing Strings For Equality

By: helle

helle — Thu, 28 Dec 2006 12:45:03 +0000

Marvelous. Thanks, will spread this among my friends!

By: danforth

danforth — Thu, 12 Oct 2006 20:04:36 +0000

Hey!

Why don’t people use the Collator class?!?

http://java.sun.com/j2se/1.4.2/docs/api/java/text/Collator.html

“The Collator class performs locale-sensitive String comparison. You use this class to build searching and sorting routines for natural language text.”

By: prozac for lovers. Jeanette Elamsson

prozac for lovers. Jeanette Elamsson — Sat, 29 Apr 2006 20:58:50 +0000

prozac for lovers

Prozac for lovers. The…

By: John Cowan

John Cowan — Sat, 07 Jan 2006 04:39:07 +0000

edavies, that was thought about when Unicode was set up and repeatedly since. The trouble is that there is just too much legacy data (mostly in 8859-9 encoding) that doesn’t distinguish between Turkish i and non-Turkish i. There is simply no hope of getting people to make such a distinction systematically and correctly, so the problem won’t go away.

Also, hexagonal French is moving back toward preserving accents in uppercase letters. They were basically dropped just to accommodate typewriters, which didn’t have enough keys to provide them.

By: edavies

edavies — Fri, 06 Jan 2006 18:34:09 +0000

Different letters in Unicode

This problem also illustrates the uneasy issue of when two symbols are regarded as the “same” in Unicode. For example, the Cyrillic capital letter es (U+0421) looks like (is a homoglyph of) the Latin capital letter c (U+0043) but the two are, quite reasonably, regarded as different. Given the distinction between the dotted and undotted letter i in Turkish maybe even the dotted lower case form and the undotted upper case form should have been regarded as distinct from their Latin homoglyphs. Of course, it’s difficult to know where to draw the line - an English letter a is presumably the “same” as a French one, isn’t it? However, different case conversion rules seem to me to be enough to trigger a separation. Except then, of course, we need to worry whether accented lower case letters in Canadian French are different from those in European French. Hmm, not easy. Now off to read RFCs 3490, 3491 and 3492 on IDNs to see what all that fuss is about.

By: Tim

Tim — Fri, 06 Jan 2006 18:33:06 +0000

equalsIgnoreCase(String) also suffers the same problem. I’ve always used string1.equalsIgnoreCase(string2) thinking that it would take care of the messiness of case comparison. A quick look at the javadoc and source code suggests that it suffers the same problem. All it does is compare both the uppercase and lowercase version of each character. I wonder why they wouldn’t have added an equalsIgnoreCase(String, Locale) method? Also with regards to the link to Peter Norvig’s toLowerCase() implementation: I don’t think it solves the Turkish problem, but merely ignores it. In fact the javadoc of the given source says:

Warning: Don’t use this method when your default locale is Turkey.

By: jdf

jdf — Fri, 06 Jan 2006 18:31:43 +0000

Don’t create new strings just to compare them! You’d be better served by String.regionMatches().

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Fri, 06 Jan 2006 18:30:21 +0000

Re: Case-insignificant comparison

The JavaDoc for compareToIgnoreCase() says:

This method returns an integer whose sign is that of calling compareTo with normalized versions of the strings where case differences have been eliminated by calling Character.toLowerCase(Character.toUpperCase(character)) on each character.

Assuming the algorithm is implemented as specified, (and a quick peek at the source code shows it is, at least in the version of Sun's JDK I have handy) it would have the same issue.

By: Neil

Neil — Fri, 06 Jan 2006 18:29:38 +0000

Case-insignificant comparison

Does the compareToIgnoreCase() method have the same issues, or does that always work?

By: edavies

edavies — Fri, 06 Jan 2006 17:58:35 +0000

Trivia

Both branches of the if in your code fragment print “The domains are the same.”.