So close. java's own String.CASE_INSENSITIVE_ORDER uses this tactic, and as far as case insensitive tactics go, this really isn't such a bad one. However, they completely bollocks it up by doing this character-by- character for some completely unfathomable reason. This is dumb, and explains why STRASSE and straße aren't equal. Character.toUpperCase('\u00DF') can't very well return "SS", so it has to return the unicode codepoint for capital eszett.
Nevertheless, as someone else has pointed out to me, both großman and grossman are somewhat common german surnames and shouldn't be considered equal, so, in many ways, yes, 'case insensitive' as a concept doesn't really make sense beyond english. Doing a canonical comparison to answer the question: "Are these strings most likely intended to be equal considering that they are both written in language X", is completely valid though, and that's exactly what java.text.Collator is for. I don't think this is mission impossible. It's just crazy complicated. Many props to A McDowell for teaching us all about the case folding rules of unicode. I learned something new. On Aug 8, 9:34 am, Christian Catchpole <christ...@catchpole.net> wrote: > So, without some kind of case translation dictionary that can be > trusted on the particular strings we want to test, can we assume > that's it's not actually a solvable problem? (because, like divide by > zero, the question isn't valid to start with) > > Could you maybe get better results by (if upperCompare || > lowerCompare)? > > Was I serious for a second there? > > GERBILS! > > That's better. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.